First-Pass Crash Dumps and Error Screenshots with AI

Tier: Advanced · Workflow area: Troubleshooting & diagnosis · ~40 minutes

Two related recipes share this playbook because they share a discipline: extract structured text from an opaque artifact (memory dump, screenshot), let AI interpret it, then cross-check every load-bearing claim against vendor documentation before acting.

When to use

• Recurring BSODs or app crashesa machine that has crashed twice will crash a third time; a first-pass read tells you whether to chase a driver, storage, or memory before you rebuild.
• Screenshot-only evidenceremote user, error long gone, one photo of the screen taken on a phone. Often that photo is all the evidence you will ever get.
• Deciding whether to escalatethe first-pass read is exactly what a vendor case or L3 escalation needs attached; it also tells you when escalation is not needed.

When NOT to use

• One-off crash, no recurrencenote it, keep the dump, move on. Dump analysis earns its time on patterns.
• Suspected exploitationa crash in a security product, or crashes coinciding with intrusion indicators, goes to security with the dump handled as evidence — not into any external AI tool.
• Kernel debugging beyond first-passif the answer requires walking raw memory structures, that is a specialist or vendor task; know where this recipe's floor is.

The recipe

1. 1.

   Get the tooling and the dump.

   Copy

   winget install Microsoft.WinDbg
   
   # Where dumps live
   Get-ChildItem C:\Windows\Minidump\ | Sort-Object LastWriteTime -Descending
   Test-Path C:\Windows\MEMORY.DMP
   
   # Confirm dumps are enabled for next time (0=none, 3=small, 7=automatic)
   Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\CrashControl" |
     Select-Object CrashDumpEnabled, MinidumpDir
   

2. 2.

   Run the standard analysis and capture the text. Open the dump in WinDbg (File → Open dump file), let symbols load, then in the command window:

   Copy

   !analyze -v
   lm kv
   

   Copy the full !analyze -v output — bugcheck code and arguments, the IMAGE_NAME, the stack — plus the loaded-module list with versions. That text, not the binary dump, is what the LLM works from.

3. 3.

   Prompt for a first-pass read with confidence labeling.

   Copy

   Interpret this WinDbg !analyze -v output for an IT engineer. The machine
   is a Dell Latitude 5540, Win 11 23H2, third BSOD in two weeks, typically
   during video calls.
   
   Give me:
   1. MECHANISM: what the bugcheck code + arguments say happened, in plain
      terms. Distinguish what the output PROVES from what it merely suggests.
   2. SUSPECT: the implicated module/driver, its role, and how confident the
      blame is (a driver on the stack is not always the culprit — say if the
      evidence is circumstantial).
   3. CHECKS: 3–5 verifiable next steps (driver version vs vendor latest,
      known issues, memory test, storage health) — each phrased as a check
      with the exact command or path.
   4. SEARCH TERMS: the exact strings to search on the vendor KB and
      Microsoft Learn for this signature.
   
   Do not invent bugcheck meanings or driver names not present in the output.
   
   Output:
   [paste !analyze -v and lm kv]
   

4. 4.

   Cross-check before you act — this is the step that separates first-pass from folklore. Take the model's SEARCH TERMS to the primary sources: the bugcheck code on Microsoft Learn's bug check reference, the driver on the vendor's release notes, the machine model on the OEM's known-issues page. You are validating three things: the stated meaning of the bugcheck code, whether the suspect driver has a newer version with a matching fix, and whether this is a known signature. A confirmed first-pass looks like:

   Copy

   MECHANISM: 0x000000D1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) — a driver touched
   pageable memory at raised IRQL. Proven: fault in network stack context.
   SUSPECT: rtwlane.sys (Realtek Wi-Fi) v6001.0.10.323 on stack directly. ✔
   Vendor KB check: v6001.15.x release notes list "fixes rare bluescreen
   during heavy media streaming" — matches the video-call trigger. ✔
   ACTION: update driver via Dell Command Update in pilot; keep dump in case.
   

   If the KB cross-check contradicts the model's read, the KB wins, and note the miss — it recalibrates how much you trust the next first-pass.

5. 5.

   Screenshot variant: extract first, interpret second. Feed the user's photo to a vision-capable model with an extraction-first prompt:

   Copy

   Step 1 — TRANSCRIBE: extract all text visible in this screenshot exactly:
   error title, message body, error code, file paths, URL/window title,
   anything in the background that identifies the app or OS version. Mark
   unreadable parts as [unreadable] — do not guess characters.
   Step 2 — INTERPRET: only after transcription, tell me what application
   and error this is, and the 3 most useful checks to run next.
   

   Then verify the transcription yourself against the image — one misread character in an 0x8xxxxxxx code aims the whole investigation at the wrong subsystem. The transcribed, verified text goes into the ticket (searchable, quotable) and can then feed the pb-08 checks recipe like any other error message.

6. 6.

   File the artifact and the dump. First-pass read plus KB confirmations go in the ticket; the dump file gets retained per your policy (dumps contain memory contents — treat as sensitive, see the warning below). If escalating to the vendor, attach the dump, your !analyze -v text, and the checks already ruled out — that package typically skips a full support tier.

Make it yours

• App crashes rather than BSODssame recipe with WER data: Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000,1001} -MaxEvents 10 for the faulting module, plus ProcDump (procdump -ma -e <pid>) when you need a dump on demand.
• macOS/Linux estatesfeed .ips crash reports from Console.app, or coredumpctl info / journalctl -k -b -1 output, through the same prompt shape; the mechanism/suspect/checks/search-terms structure is universal.
• No local WinDbga minidump plus the crash-time System log excerpt still supports a useful first pass from event text alone; label the result lower-confidence and lean harder on the vendor-KB step.

Quality check

• The KB cross-check is mandatory, not decorativeno driver update, no rollback, no reimage on the model's say-so alone; act when the vendor documentation corroborates the read.
• Pilot before fleeta driver update prompted by dump analysis rolls to the affected machine and a pilot ring first, through your normal patch process, even when the fix looks obviously right.
• Transcriptions verified character-by-characterfor codes and paths from screenshots, your eyes check every glyph; 0/O and 8/B misreads are routine.
• Track first-pass accuracykeep a simple tally of first-pass suspect vs confirmed cause; it calibrates how much weight your team should give the next one.