| Previous | Next |
| NS_E_INVALID_EDL | NS_E_CODEC_DMO_ERROR |
NS_E_DATA_UNIT_EXTENSION_TOO_LARGE
NS_E_DATA_UNIT_EXTENSION_TOO_LARGE: diagnosis and verification
NS_E_DATA_UNIT_EXTENSION_TOO_LARGE (0xC00D0BD9) means per-sample extension data exceeds the size that can be attached to the sample.
Profile and sample evidence
| Capture | Why it matters |
|---|---|
| Owning call | Record the API method, object identity, thread or callback and timestamp for this condition media-format check. |
| Values to record | Reader or writer object, stream and input numbers, profile identity, sample timestamps, buffer lengths and the first callback or SDK call that returned the code. |
| Comparison case | Use one known-good resource that exercises the same condition media-format check while changing only the rejected precondition. |
Failure anatomy
A per-sample data-unit extension exceeded the size accepted by the Windows Media sample or writer contract. Capture the extension GUID/type, declared length, actual buffer length, sample size and the API that attaches the extension.
Reproduce with the same sample while removing the extension, then add a minimal valid extension of the same type. Increase only the extension payload until the failing boundary is reached.
Nearby results are not interchangeable
Main distinction: the media sample itself can be valid while its attached extension metadata is oversized. This is not a no-more-samples condition and does not imply that the stream format is unsupported.
| Nearby HRESULT | How to compare it |
|---|---|
NS_E_ATTRIBUTE_NOT_ALLOWED | the attribute is valid in the SDK but not legal for the selected media type or object |
NS_E_INVALID_EDL | the edit decision list contains invalid timing, ordering or source-range information |
NS_E_CODEC_DMO_ERROR | A codec hosted through the DMO path returned an operational failure |
A controlled media-format test
- Log
0xC00D0BD9, the exact operation and the first failure time. - Preserve writer/reader object, stream and input number, sample timestamp and size, extension identifier, declared extension length and buffer allocation used by the failing call.
- Perform one isolated test: keep the sample unchanged and vary only the data-unit extension length or remove that extension.
- Repeat through the same writer or sample-extension API. A successful encode after dropping all metadata proves only that the extension path was bypassed.
Misleading actions
- Do not change codec, bitrate or profile to fix this size violation unless they directly alter the extension contract. First reduce or correctly serialize the extension payload.
- Record extension GUID/type, declared and actual byte counts, sample size and the first API returning the HRESULT. Hash sensitive extension data rather than logging its contents.
Discriminating evidence: Record the data-unit extension identifier, declared extension length and sample size at the failing writer or parser call. The failure is an oversized extension payload; it is not an end-of-stream indication and should not be diagnosed from sample availability alone.
Technical references
- Windows Media Format SDK overview
- Input, stream and output formats
- Profiles
- Windows Media SDK objects
- Sample extension types
- Microsoft HRESULT registry
Treat it as resolved when the same sample and extension type are accepted with a payload within the supported bound and the extension can be read back or consumed as expected.
Looking for a different code? Search another status or error code.