BSOD diagnostic structure
Every stop-code report will preserve these distinct evidence layers.
Bug-check code and name
Start with Microsoft’s definition and the meaning of each parameter.
Dump contextCrash time and system state
Capture dump type, operating context, uptime, and repeatable trigger.
Module evidenceStack and loaded modules
Treat a named driver as a lead to verify, not automatic proof of blame.
HardwareMemory, storage, and thermals
Correlate hardware evidence only when the stop pattern and tests support it.
SoftwareDrivers, filters, and updates
Match recent changes to the exact crash timeline and controlled retest.
RecoverySafe rollback sequence
Prefer reversible changes and preserve new dump evidence after every test.
How WinLab approaches this category
A consistent evidence path keeps future report batches useful and navigable.
Preserve the exact name, code, event, device, command, or Windows component involved.
Match official definitions with version, timestamp, system context, and reproducible symptoms.
Use the owning publisher or supported Windows path, then retest the same operation.
Source and safety boundary: Bug-check interpretation must follow Microsoft definitions and actual dump evidence. A crash screen or module name alone does not establish one universal cause.