windows3-7  Exercise 3: A Plan for Opening a Dump
=================================================================

Verification: Level 3 (planning only: nothing here was run beyond the event-log decode).

Prediction (work this out before running the script):

  Before reading the solution: write the order of steps you would take and what you would do if the first
  command's bugcheck code did not match the event log.

This is a planning exercise: the commands are NOT run here (WinDbg is not installed, and the dumps need administrator rights).

Plan:

  1. Copy the dumps (administrator PowerShell, save_evidence.ps1) and check the SHA-256 manifest lists both .dmp files.
  2. Install WinDbg from Microsoft (winget id Microsoft.WinDbg, or the Store listing); check the publisher is Microsoft.
  3. Start with Microsoft's symbol path and a COPY of the dump:
       windbg -y "srv*C:\Symbols*https://msdl.microsoft.com/download/symbols" -z C:\crash-evidence\102426-15109-01.dmp
  4. .bugcheck            expect: BugCheck 13A, {11, ffffb00ee3100140, ffffb00f1e44e350, 0}
     If it does not match the event log you decoded, STOP: you have the wrong file (or wrong dump); do not continue.
  5. !analyze -v          record: the stop code and parameters, the "Probably caused by" line / faulting module,
                          the failure bucket, and the top of the stack.
  6. lm                   record the loaded drivers and their dates (especially third-party ones).
  7. Repeat for the second dump. Do the two name the same module?
  8. Write a ranked suspect list in the crash log, each with "what this does not prove".
  9. Send to a vendor: text first (bugcheck line, !analyze -v output, module list). The dump only if asked, privately.

Output:

  Not run here: no output exists for steps 3 to 7 on this machine. What can be stated now is the expected first line of step 4, taken from the event log decode in this chapter.

WHY THIS WORKS AS AN ANSWER
---------------------------
  Why this order works: copying first protects the original (chapter 6); checking the publisher protects the PC;
  .bugcheck before !analyze is a cheap check that the right dump is open (the numbers must equal the event log's);
  comparing two dumps follows the rule that the same module in several dumps is far stronger evidence than one;
  and the "does not prove" column keeps a suspect from turning into a verdict.
  What I would be prepared to see: for a 0x13A heap-corruption bugcheck the named module may be only the code that
  noticed a corruption made earlier, so a surprising module is a reason to look at the list in step 6, not to uninstall it.
  Common mistakes: opening the original dump instead of a copy; skipping the .bugcheck match check; sending the
  whole dump to a forum first; and acting on a single "Probably caused by" line.