| Previous | Next |
| SDIAG_E_CANNOTRUN | SDIAG_E_RESOURCE |
SDIAG_E_VERSION
SDIAG_E_VERSION — 0x803C0109
This code places the first failure in troubleshooting-pack version compatibility. Operationally, the installed WTP runtime does not support the pack version or schema/features declared by the diagnostic package.
Operational meaning
A troubleshooting pack has distinct initialization, detection, resolution, and verification phases. Keep the ordinary result report together with the debug report, and identify whether the pack script, PowerShell host, managed host, resource loader, trust check, or verifier produced the first failure.
Do not collapse this result into a nearby status. A missing resource or unsupported platform condition may coexist, but this code specifically identifies version compatibility. Compare lifecycle, identity, caller, and first API.
Build the incident record
| Capture | Why it matters |
|---|---|
| Pack manifest/schema version, tools used to build it, and target Windows build | Tests whether the first boundary moves. |
| Runtime/WTP component version and architecture | Pins evidence to one attempt. |
| Backward-compatible features versus newly introduced elements | Separates contract failure from environment. |
| Pack signing/catalog state after any down-level rebuild | Creates a stable before/after control. |
Identifiers, timestamps, versions, counts, state flags, hashes, and redacted paths normally provide enough correlation. Keep credentials, private keys, message bodies, recovery material, and personal data out of routine incident logs.
Tests that separate the causes
- Build the smallest pack using the same schema version; keep every other input fixed and record the first event that differs from the failing run.
- Run the package on its documented target build; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Rebuild with the oldest required toolchain and compare manifest differences; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
Do not use repeated retries as the primary test. In this case, a successful later attempt may reflect a new object, refreshed policy, restarted service, different token, or completed background transition, so record exactly what changed between attempts.
Interpretation boundaries
Use the outcomes to narrow the failing layer rather than to accumulate unrelated fixes:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Repair without losing evidence
The corrective action should be narrow: Align the pack schema/toolchain with the supported Windows range or ship versioned packages selected by preflight logic. Preserve the pre-change configuration or trace.
Close the incident only when each supported OS selects and runs the correct package version, while down-level controls reject newer schemas cleanly. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
The diagnostic boundaries above are grounded in the following Microsoft specifications and API documentation:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: Windows Troubleshooting Platform.
- Microsoft: About WTP.
- Microsoft: debugging troubleshooting packs.
Looking for a different code? Search another status or error code.