What causes "Image_CantDealWithStream" in dotnet/wpf?

Use BitmapDecoder.Create(stream, createOptions, cacheOption) for automatic format detection.

dotnet/wpf · error · FileFormatException

Image_CantDealWithStream

Error message

Image_CantDealWithStream

What it means

The stream-based BitmapDecoder constructor validates that the stream's decoded CLSID matches the decoder type being constructed. When the stream contains a different image format than the specific decoder expects, a FileFormatException with Image_CantDealWithStream is thrown.

Solutions

Use BitmapDecoder.Create(stream, createOptions, cacheOption) for automatic format detection.
Probe the stream's magic bytes (first 8-16 bytes) before choosing a format-specific decoder.
Ensure the stream is positioned at 0 and contains a complete image payload.
Catch FileFormatException and retry with the generic factory.

Example fix

// before
var dec = new JpegBitmapDecoder(ms, BitmapCreateOptions.None, BitmapCacheOption.OnLoad); // ms holds PNG
// after
var dec = BitmapDecoder.Create(ms, BitmapCreateOptions.None, BitmapCacheOption.OnLoad);

Defensive patterns

Strategy: validation

Validate before calling

static bool IsPng(Stream s) { s.Position = 0; Span<byte> b = stackalloc byte[8]; s.Read(b); s.Position = 0; return b[0] == 0x89 && b[1] == (byte)'P'; }

Type guard

bool CanDecode(Stream s) => s != null && s.CanRead && s.Length > 0;

Try / catch

try { decoder = new JpegBitmapDecoder(stream, opts, cache); }
catch (FileFormatException) { stream.Position = 0; decoder = BitmapDecoder.Create(stream, opts, cache); }

Prevention

Use BitmapDecoder.Create (auto-detect) instead of format-specific constructors on untrusted streams
Probe magic bytes before constructing a typed decoder
Reset stream Position to 0 before decoding
Sanitize uploads by re-encoding rather than trusting stored formats

When it happens

Trigger: Constructing e.g. new JpegBitmapDecoder(stream, ...) with a stream holding PNG/GIF data; feeding a stream whose embedded clsId is non-empty but not equal to the expected decoder CLSID.

Common situations: Downloading images where Content-Type lies about the format; database BLOBs stored with the wrong format label; user-uploaded files that bypassed extension checks.

Understand the failure class

Background: "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires — this error's family across 65 libraries.

Related errors

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

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/Imaging/BitmapDecoder.cs:137

            _decoderHandle = SetupDecoderFromUriOrStream(
                null,
                bitmapStream,
                cacheOption,
                out clsId,
                out isOriginalWritable,
                out _uriStream,
                out _unmanagedMemoryStream,
                out _safeFilehandle
                );

            if (_uriStream == null)
            {
                GC.SuppressFinalize(this);
            }

            if (clsId != Guid.Empty && clsId != expectedClsId)
            {
                throw new FileFormatException(null, SR.Image_CantDealWithStream);
            }

            _stream = bitmapStream;
            _createOptions = createOptions;
            _cacheOption = cacheOption;
            _syncObject = _decoderHandle;
            _isOriginalWritable = isOriginalWritable;
            Initialize(null);
        }

        /// <summary>
        /// Constructor
        /// </summary>
        internal BitmapDecoder(
            SafeMILHandle decoderHandle,
            BitmapDecoder decoder,
            Uri baseUri,
            Uri uri,

View on GitHub (pinned to 81131a70a4)