Stop code (bug check)

Windows just fainted and left a note. Read the note before you blame your RAM.

The short answer

A stop code, also called a bug check code, is what Windows shows when it halts because carrying on could corrupt the operating system or your data [1][5]. Four parameters come with it [2]. The code tells you the kind of failure, such as 0xD1 for DRIVER_IRQL_NOT_LESS_OR_EQUAL, and not who caused it [3][4]. Our assessment: write down the code, the module name and the parameters, and treat them as the start of the search, not the verdict.

How it works

1. Why Windows stops. When it meets a condition that compromises safe operation, the system halts. Microsoft calls this a bug check, and also a system crash, kernel error or stop error [1][5].
2. What the screen shows. The stop code error and, when available, the module name of the code that was running, for example a .sys driver file [1]. Each code has a hex value and a symbolic name. 0x0000000A is IRQL_NOT_LESS_OR_EQUAL and 0x0000009F is DRIVER_POWER_STATE_FAILURE [3].
3. Four parameters. Their meaning differs per code and is listed in the reference. You can read them in the Event Viewer system log, with !analyze on a dump file, or from an attached kernel debugger [2]. For 0xD1 they are the memory referenced, the IRQL at that moment, whether it was a read (0), write (1) or execute (2 or 8), and the address of the code that touched the memory [4].
4. Likely causes. Microsoft's analysis of crashes: 70% third-party driver code, 10% hardware, 5% Microsoft code and 15% unknown because memory was too corrupted to analyse. A user program such as Notepad rarely is the root cause [5]. For 0xD1, the page says finding the cause takes the debugger and source code, and that a driver using improper memory addresses is the usual reason [4].
5. Dump files. Under Startup and Recovery, "Write debugging information" decides what is saved. A small memory dump lands in %SystemRoot%\Minidump, the larger types in %SystemRoot%\MEMORY.DMP [5]. If a debugger names a driver, dx KiBugCheckDriver shows it [4].

A practical example

Microsoft's documentation shows this sample output for 0xD1 [4]. The values are the docs' sample, not a crash of ours:

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
Arg1: fffff808add27150, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff808adc386a6, address which referenced memory

Read it like this: a driver read pageable memory while the IRQL was 2 (DISPATCH_LEVEL), which is too high for that. The page adds that in most such cases the memory is the problem and not the IRQL [4]. Your next steps do not need a debugger: install Windows and BIOS updates, update or roll back the driver that is named, and run hardware and memory tests [5][1].

Checklist

• Note the stop code, the module name and, from Event Viewer, the four parameters [1][2].
• Search for the exact code and compare the parameters with the reference [3][4].
• Check that dumps exist: set "Automatic memory dump" and look in %SystemRoot%\Minidump [5].
• Install the latest Windows updates and update the BIOS and firmware [5].
• Update or roll back the driver the screen names, and undo recent hardware or driver changes [1][5].
• Run Windows Memory Diagnostics and read its result in Event Viewer [1]. Check your drive too; see our entry on S.M.A.R.T.
• Keep 10 to 15 percent of the disk free, as Microsoft recommends [5].
• Change one thing at a time and write down the date and the result.