| Previous | Next |
| ERROR_QUERY_STORAGE_ERROR | SDIAG_E_SCRIPT |
SDIAG_E_CANCELLED
Treat this HRESULT as a marker for troubleshooting-pack cancellation, not as a request for a generic restart or reinstall. It is returned when the Windows Troubleshooting Platform run ended by cancellation before detect, resolve, or verify processing completed.
Operational meaning
A troubleshooting pack has distinct initialization, detection, resolution, and verification phases when diagnosing troubleshooting-pack cancellation. 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 for an incident involving troubleshooting-pack cancellation.
Do not collapse this result into a nearby status. Cancellation is not evidence that the underlying root cause was fixed or not found; the diagnostic run is incomplete. For troubleshooting-pack cancellation, compare the lifecycle stage, object identity, caller context, and first returning API—not only the English wording or the final dialog shown to the user.
Build the incident record
| Capture | Why it matters |
|---|---|
| Who initiated cancellation, UI/host event, phase, root cause, and script currently running | Shows whether the proposed correction changes the first failing boundary during verification of troubleshooting-pack cancellation. |
| Result/debug report, timestamps, and partial resolver actions already applied | Locates the exact attempt and prevents evidence from a later retry from being mixed into it when diagnosing troubleshooting-pack cancellation. |
| Interactive versus unattended invocation and owner window/process lifetime | Separates a contract or configuration defect from a transient environmental failure in an incident involving troubleshooting-pack cancellation. |
| Cleanup or rollback completed by the pack after cancellation | Provides a stable comparison point for a controlled reproduction before changing the state involved in troubleshooting-pack cancellation. |
Collect the smallest evidence set that identifies the attempt and object when diagnosing troubleshooting-pack cancellation. Redact secrets and message contents; preserve hashes, IDs, policy values, versions, and state transitions instead for an incident involving troubleshooting-pack cancellation.
Tests that separate the causes
- Run unattended with a complete answer file to remove UI cancellation; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Cancel deliberately in each phase and verify idempotent cleanup; keep every other input fixed and record the first event that differs from the failing run.
- Repeat without the launching application exiting; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
For troubleshooting-pack cancellation, do not use repeated retries as the primary test. In the troubleshooting-pack cancellation 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
The following decision points keep the investigation tied to the returning operation for troubleshooting-pack cancellation:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | For troubleshooting-pack cancellation, the platform path is available; concentrate on the production object, arguments, identity, policy, or lifecycle state described above. |
| The control fails at the same first operation | For troubleshooting-pack cancellation, failure of the control points below application-specific data; preserve service, provider, operating-system, or host evidence before changing the environment. |
| A different HRESULT appears after one controlled change | The troubleshooting-pack cancellation 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: Make long steps cancellable and transactional, preserve partial-action records, and rerun from a known state. For troubleshooting-pack cancellation, preserve the pre-change export or trace and document the exact configuration, build, identity, object, or policy that changed.
Close the incident only when deliberate cancellation leaves the machine consistent and a subsequent full run reaches a definitive root-cause result. For troubleshooting-pack cancellation, repeat the original supported operation under the original identity and object state, then retain one deliberate boundary or negative test. A result from a different account, simplified input, replacement object, or unrelated machine is useful comparison data for troubleshooting-pack cancellation, but it is not regression proof.
Technical references
Use these sources for the formal contract, then combine them with evidence from the returning application or service for troubleshooting-pack cancellation:
- 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.