dotnet/wpf · error · ArgumentException

SR.FileShareUnsupported

Error message

SR.FileShareUnsupported

What it means

StorageRoot.Open rejects FileShare.Inheritable because the underlying STGM share flags cannot express handle inheritance. Passing a share value containing the Inheritable bit throws ArgumentException.

Solutions

1. Remove FileShare.Inheritable from the share value (mask it out: share & ~FileShare.Inheritable).
2. Use FileShare.Read, ReadWrite, or None as appropriate for the package.
3. Avoid forwarding raw share flags from unrelated file APIs to Package.Open.

Example fix

// before
Package.Open(path, FileMode.Open, FileAccess.Read, FileShare.Read | FileShare.Inheritable);
// after
var share = FileShare.Read | FileShare.Inheritable;
Package.Open(path, FileMode.Open, FileAccess.Read, share & ~FileShare.Inheritable);

if ((share & FileShare.Inheritable) != 0)
    share &= ~FileShare.Inheritable;

bool IsSupportedFileShare(FileShare s) => (s & FileShare.Inheritable) == 0;

When it happens

Trigger: Calling StorageRoot.Open / Package.Open with share = FileShare.Inheritable or any combination that includes the Inheritable flag (e.g. FileShare.Read | FileShare.Inheritable).

Common situations: Copying share flags intended for FileStream onto package opens; code that passes the share mode of an inherited handle.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• SR.FileShareInvalid
• InvalidEnumArgumentException: invalid SeekOrigin value…
• SR.FileModeInvalid
• SR.FileModeUnsupported
• " }} " element found. Expected fixed page element ( }} ).

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/a8d4272ac4a4a22c. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/WindowsBase/System/IO/Packaging/CompoundFile/StorageRoot.cs:294

            case FileMode.Truncate:
                throw new ArgumentException(
                    SR.FileModeUnsupported);
            default:
                throw new ArgumentException(
                    SR.FileModeInvalid);
        }

        // Generate the access flags from the access parameter
        SafeNativeCompoundFileMethods.UpdateModeFlagFromFileAccess( access, ref grfMode );

        // Generate STGM from FileShare

        // Note: the .NET SDK does not specify the proper behavior in reaction to
        //  incompatible flags being sent in together.  Should ArgumentException be
        //  thrown?  Or do some values "trump" others?
        if( 0 != (share & FileShare.Inheritable) )
        {
            throw new ArgumentException(
                SR.FileShareUnsupported);
        }
        else if( share == FileShare.None ) // FileShare.None is zero, using "&" to check causes unreachable code error
        {
            grfMode |= SafeNativeCompoundFileConstants.STGM_SHARE_EXCLUSIVE;
        }
        else if( share == FileShare.Read )
        {
            grfMode |= SafeNativeCompoundFileConstants.STGM_SHARE_DENY_WRITE;
        }
        else if( share == FileShare.Write )
        {
            grfMode |= SafeNativeCompoundFileConstants.STGM_SHARE_DENY_READ; // Note that this makes little sense when we don't support combination of flags
        }
        else if( share == FileShare.ReadWrite )
        {
            grfMode |= SafeNativeCompoundFileConstants.STGM_SHARE_DENY_NONE;
        }

View on GitHub (pinned to 81131a70a4)