Capture a BSOD stop code

Understand what a stop code can and cannot tell you

Microsoft describes blue-screen errors as bug checks or stop-code errors that occur when a serious problem forces Windows to shut down or restart to protect the system. The screen may show a code such as PAGE_FAULT_IN_NONPAGED_AREA and sometimes a 'What failed' module name.

The code identifies the failure category recorded by Windows. It does not prove that the named file is defective; a driver can appear because it was active when corrupted data reached it, and memory or storage faults can produce changing codes. One crash is a clue. Repeated crashes under the same condition create a pattern.

Capture the screen and the conditions around it

Use a phone photo if Windows restarts too quickly. Capture the full stop code, any hexadecimal value, QR code area and 'What failed' text. Record local time, what the user was doing, whether the PC had just resumed from sleep, and whether new hardware, drivers, firmware or Windows updates were installed recently.

After restart, do not immediately run several repair tools. First confirm whether files are intact, save the evidence and check update history. If the device crashes repeatedly during normal use, back up important data before stress testing.

1. 1

   Photograph or write the exact stop code without correcting spelling.

2. 2

   Record any 'What failed' module name exactly.

3. 3

   Write the local time and workload immediately before the crash.

4. 4

   Note whether the crash occurred at startup, idle, sleep/resume or under load.

5. 5

   List recent drivers, updates, applications and hardware changes.

6. 6

   Record whether the code repeats or changes across crashes.

Check for crash evidence after Windows restarts

Windows can write a memory dump when a stop error occurs. Microsoft documents several dump types and notes that dump analysis is primarily an advanced troubleshooting task. Dump files can contain portions of memory and therefore may include sensitive information.

Look for C:\Windows\Minidump and the system event at the recorded time. Do not upload a dump to an unknown public site. If support requests it, confirm the destination and privacy policy. A missing dump can result from configuration, insufficient page-file support, storage problems or an interruption during writing; it does not mean the crash did not occur.

1. 1

   Open Event Viewer and check Windows Logs > System around the recorded timestamp.

2. 2

   Look for an unexpected shutdown, bug-check or related critical event.

3. 3

   Check whether C:\Windows\Minidump exists and contains a file from the same date.

4. 4

   Record the file name and size without opening it in a text editor.

5. 5

   Keep the original dump unchanged if professional analysis is planned.

6. 6

   Redact account and file information from screenshots before public sharing.

Use repetition to narrow the next test

A code that began immediately after one driver update supports reviewing that driver. Crashes only under memory-heavy work support a memory-stability test. Crashes during file access plus storage warnings support data backup and drive assessment. Different codes at random times can indicate broader instability but still require controlled testing.

Start with supported updates, known recent changes, hardware seating only if qualified, and built-in diagnostics. Do not download a DLL or driver simply because its name resembles the failed module.

Escalate recurring crashes with a concise evidence package

Frequent stop errors, crashes during backup, changing storage visibility, memory-test errors or overheating symptoms require prompt escalation. Provide the stop-code history, timestamps, Windows build, hardware model, recent changes and dump availability.

Advanced dump configuration, kernel debugging and manually forcing a crash are outside a beginner workflow. Those actions can interrupt work and expose memory contents.

Common mistakes to avoid

• Searching only the code and applying the first registry fix found online.
• Assuming the failed-module name proves that file is the root cause.
• Uploading a memory dump to an unknown service.
• Running repeated stress tests before backing up unstable storage.