Turn Error Messages into Verifiable Checks

Tier: Foundation · Workflow area: Troubleshooting & diagnosis · ~20 minutes

This is the foundational prompt pattern for AI-assisted troubleshooting. Master it here on error messages, stop codes and event IDs; every later diagnosis playbook (logs, networks, dumps, cross-system RCA) is this pattern at larger scale.

When to use

• Any unfamiliar error, stop code or event IDthe "never seen this one" moment where you would otherwise search and skim five stale forum threads.
• Familiar errors behaving unfamiliarlya known message in a context where the usual fix did not work; the checks-format forces alternatives you stopped considering years ago.
• Coaching juniorsthe format is the troubleshooting method; a junior who runs this prompt is practicing hypothesis-driven diagnosis whether they know it or not.

When NOT to use

• When the error text is the documentation"disk full" needs df -h, not a language model.
• Active security eventsa ransom note or an EDR detection goes to the security process, not into a chat window; and never paste indicators into public tools where the query itself leaks information.
• When you will not run the checksreading hypotheses and picking the one that "sounds right" is the exact anti-pattern this playbook exists to kill.

The recipe

1. 1.

   Capture the error verbatim. Exact text, exact codes, exact source. "Some DNS error" gets generic hypotheses; the precise string constrains the model. From Windows:

   Copy

   Get-WinEvent -FilterHashtable @{LogName='System'; Id=7000,7001,7031} -MaxEvents 5 |
     Format-List TimeCreated, Id, ProviderName, Message
   

   Screenshots work too — transcribe the code exactly, or let a vision-capable model read it (verify its transcription character-by-character; a misread 0x8007 vs 0x8004 sends you down the wrong tree entirely).

2. 2.

   Prompt for checks, not diagnoses.

   Copy

   I am an IT support engineer troubleshooting a Windows endpoint issue.
   
   Exact error:
   "The trust relationship between this workstation and the primary domain failed."
   Shown at login, one machine only, started this morning.
   
   Context: Windows 11 23H2, AD-joined (hybrid), user was on hotel Wi-Fi
   all last week, no recent password change reported.
   
   Give me up to 5 hypotheses, ordered by likelihood in this context.
   For each, use exactly this format:
   - Hypothesis: <one line>
   - Check: <the exact command or console path that confirms or rules it out>
   - Expected if TRUE: <what the check shows if this is the cause>
   - If confirmed: <next action>
   
   Rules: every check must be runnable by me now, read-only where possible.
   No "reinstall Windows", no "contact Microsoft". If two hypotheses share a
   check, say so.
   

3. 3.

   Demand the discriminating shape. Good output pairs every claim with its test:

   Copy

   - Hypothesis: machine account password out of sync with AD
   - Check: Test-ComputerSecureChannel -Verbose   (run as admin)
   - Expected if TRUE: returns False
   - If confirmed: Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
     — with a domain account, after change approval if this is a server
   
   - Hypothesis: machine object deleted/disabled in AD
   - Check: Get-ADComputer <hostname> -Properties Enabled,PasswordLastSet
   - Expected if TRUE: object missing, or Enabled = False
   - If confirmed: re-enable or rejoin per your AD hygiene runbook
   

   If an answer comes back as prose ("this usually means the secure channel is broken, simply rejoin the domain"), push back with one line: "Reformat: every hypothesis must include a check I can run and what I'd see if it's true."

4. 4.

   Run the checks cheapest-and-least-invasive first, and record results. Read-only checks before state-changing ones, regardless of likelihood order. Paste each result into the ticket as you go — this trail becomes your escalation note (pb-04) for free if the checks all come back negative.

5. 5.

   Cross-check the winning hypothesis against vendor documentation. Before executing the "if confirmed" action, spend two minutes confirming the check's interpretation against the vendor KB — search the exact error string plus the confirmed cause on Microsoft Learn (or the relevant vendor's docs). You are verifying two different things: the check told you which hypothesis is true; the vendor doc tells you the model's proposed fix is the current, supported one and not a 2016 forum ritual.

6. 6.

   Feed the answer back for the fix plan only after confirmation. "Check 1 returned False, checks 2–3 ruled out. Give me the fix steps for hypothesis 1 only, flag anything requiring change approval" — now the model is elaborating a verified diagnosis, which is where it is genuinely strong.

Make it yours

• Linux/macOS estatesidentical pattern; the checks become systemctl status, journalctl -u <svc> --since -1h, log show --last 1h --predicate '...'. Add "checks must not require a reboot" for server contexts.
• SaaS-app errorschecks become admin-console paths and status pages: "Check: M365 Service health > Exchange; Expected if TRUE: advisory EX###### matching the symptom window." Add the tenant's region to the context line.
• Copilot/Gemini in the browserthe same format rules work in any assistant; grounding-enabled ones may cite sources — click them, since a citation to a real page about a different error code is the classic trap.

Quality check

• Never execute an unreviewed suggested commandread every suggested check before running; even "read-only" suggestions can be wrong (Test-ComputerSecureChannel -Repair is not read-only, and models do slip repair flags into "checks").
• Sandbox anything state-changingrepairs, rejoin operations and registry edits get tried on a test VM or at minimum after a checkpoint/backup, never first on a user's only machine.
• Track hypothesis hit-rate honestlyif the top-ranked hypothesis is confirming far less than half the time, your context lines are too thin; the fix is richer context, not longer hypothesis lists.
• Verbatim in, verbatim throughthe error string in your prompt, your ticket, and your escalation must be identical; paraphrase drift between artifacts wrecks later correlation.