| Previous | Next |
| SDIAG_E_TRUST | SDIAG_E_VERSION |
SDIAG_E_CANNOTRUN
SDIAG_E_CANNOTRUN — 0x803C0108
The short system message identifies the immediate outcome, but the useful interpretation is narrower: platform eligibility for a troubleshooting pack. In this case, the pack cannot execute on this system because its manifest requirements, context, dependencies, or platform applicability are not satisfied.
Meaning in the subsystem
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. Version mismatch has a dedicated code; CANNOTRUN is the broader eligibility/execution gate. Compare lifecycle, identity, caller, and first API.
Minimum useful evidence
| Incident evidence | Question it answers |
|---|---|
| Pack manifest applicability rules, OS/build/architecture/SKU, and elevation requirement | Tests whether the first boundary moves. |
| Required resources, services, features, and user interaction mode | Pins evidence to one attempt. |
| Get-TroubleshootingPack metadata and WTP debug report | Separates contract failure from environment. |
| Interactive versus remote/unattended launch conditions | Creates a stable before/after control. |
Collect the smallest evidence set that identifies the attempt and object. Redact secrets and message contents; preserve hashes, IDs, policy values, versions, and state transitions instead.
Isolate the responsible condition
- Query pack metadata before invocation; keep every other input fixed and record the first event that differs from the failing run.
- Run on a documented supported image with the same pack binary; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Remove one optional dependency in a test pack to verify requirement reporting; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
If the failure disappears after a broad restart, treat that as a clue about lifetime or state, not as proof of repair. Reproduce the original operation with targeted instrumentation before closing the incident.
Avoid the common misdiagnosis
Read the comparison results in this order:
| 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. |
Regression proof
Apply the smallest change that addresses the first rejected condition: Correct the pack applicability manifest or run it only on supported configurations with required dependencies and context. Preserve the pre-change configuration or trace.
Close the incident only when preflight checks predict run eligibility accurately and unsupported systems receive a specific non-destructive explanation. 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.