| Previous | Next |
| EVT_WDSMCS_W_CP_DLL_LOAD_FAILED_NOT_CRITICAL | WEB_E_INVALID_XML |
WEB_E_UNSUPPORTED_FORMAT
WEB_E_UNSUPPORTED_FORMAT (0x83750001) identifies unsupported representation selected by a web-data operation. The caller or payload requests a representation that the component does not implement. The failure occurs before content can be interpreted under that format. Record network reachability, HTTP status, and parser acceptance as separate layers.
Identify who selected the format
| Evidence | Why it matters |
|---|---|
| Content-Type or explicit format argument | Check the exact token after removing unrelated parameters, but do not silently reinterpret it. |
| Response body and declared media type | A JSON body labeled as XML, or the reverse, is a negotiation defect rather than malformed syntax. |
| API capability set | Document whether the operation accepts XML, JSON, text, binary, or only one concrete profile. |
Useful comparison
- Repeat with one documented format while keeping the resource and credentials unchanged
- Capture request and response headers before framework normalization
- Reject unsupported media types explicitly rather than guessing from the first byte
Do not relabel bad data
If the selected format is supported but its bytes are malformed, a parser-specific result such as WEB_E_INVALID_XML or WEB_E_INVALID_JSON_STRING is more precise. Changing a header until parsing begins can hide a producer contract bug.
Verification
The same resource succeeds with every format the contract advertises and fails deterministically for an unsupported token. Include charset and parameter variants in the regression set.
Negotiation evidence
For HTTP traffic, keep both the request Accept values and the response Content-Type. A charset parameter does not turn JSON into another format, and a vendor media type should be accepted only when the contract explicitly maps it to a supported representation. Record the component that made the final selection.
Before changing configuration
- Confirm this is the first failure rather than a cleanup result
- Preserve the exact input or object state selected at the failure
- Identify limits, negotiation choices, or lifecycle transitions immediately before it
- Design a one-variable experiment instead of enabling broad retry or compatibility behavior
Acceptance evidence
Close the result investigation only when the original supported operation succeeds repeatedly, an invalid control still fails, and resource ownership remains correct; success on different data or another endpoint is not equivalent evidence.
Representation pipeline
| Stage | Evidence to retain |
|---|---|
| Producer model | Serializer, contract revision, omission, ordering, escaping, and numeric options |
| Transport bytes | Content type, charset, content encoding, declared length, and parser-visible bytes |
| Parser state | Offset, line or token path, expected construct, and actual construct |
| Projection layer | Schema, object mapper, or lookup converting XML or JSON into fields |
Normalization risks
Pretty-printing, reserialization, charset conversion, or browser copying can erase the condition producing this result; hash the original body, apply deterministic redaction, and retain both received and decompressed forms when content encoding is involved.
Focused regression corpus
- A minimal document containing no unrelated members
- A valid document at the nearest relevant boundary
- A contract-version variant showing strict or forward-compatible behavior
- A transport variant proving framing and character decoding are not hidden causes
Fix ownership
| Layer | When it owns the correction |
|---|---|
| Transport | Change framing, decompression, or character decoding only when captured bytes prove this layer altered the representation |
| Parser | Change syntax handling only when the raw token or markup violates the selected format |
| Projection | Change requiredness, path, ordering, or value conversion only after parsing succeeds |
| Producer | Correct serialization when the emitted representation contradicts the published contract |
Technical references
- Microsoft Open Specifications: HRESULT values
- Windows Web Services overview
- W3C XML 1.0 specification
- RFC 8259: The JavaScript Object Notation data interchange format
Looking for a different code? Search another status or error code.