| Previous | Next |
| SDIAG_E_CANCELLED | SDIAG_E_POWERSHELL |
SDIAG_E_SCRIPT
Treat this HRESULT as a marker, not as a request for a generic restart or reinstall. It is returned when a detection, resolution, or verification PowerShell script failed while WTP was executing the pack.
The contract behind the HRESULT
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. SDIAG_E_POWERSHELL points to the PowerShell runtime interaction; SDIAG_E_SCRIPT points to the pack script’s execution path. Compare lifecycle, identity, caller, and first API.
Diagnostic worksheet
| Record | How it narrows the cause |
|---|---|
| Pack ID/version/publisher, script name, phase, exception, line, and invocation parameters | Tests whether the first boundary moves. |
| WTP debug report and hosted PowerShell output | Pins evidence to one attempt. |
| Execution identity/elevation, working directory, culture, and resource paths | Separates contract failure from environment. |
| State changes completed before the exception | 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.
Reproduce the boundary safely
- Run the script logic with the same inputs in an isolated signed test pack; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Add terminating error handling around the smallest failing command; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Compare interactive and unattended execution with identical answer data; keep every other input fixed and record the first event that differs from the failing run.
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.
Nearby states and false leads
Read the comparison results in this order for troubleshooting-pack script failure:
| 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 | The failure moved to another boundary; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Closing the incident
A defensible correction is specific to the evidence: Correct the script, make resolver actions idempotent, validate inputs/resources, and sign/rebuild the pack after changes. Preserve the pre-change configuration or trace.
Close the incident only when detect, resolve, and verify phases complete for positive and negative cases, and injected command failures produce a controlled report. 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.