Log Dejargonizer

Windows System Log · Event 1001

Event 1001 BugCheck: Windows recorded a blue screen

The machine blue-screened and Windows wrote down the stop code afterwards. The bugcheck code in this event is the single most useful piece of information about a crash, because it names the class of fault — and it points at a dump file that names the culprit.

Also written as 1001Event ID 1001BugCheckBugCheck 1001blue screen event id

What it means for you

On a personal computer

This is the record of a blue screen. The long code in the middle is the important part — search for that exact code rather than for the event number. One crash after a driver update is common; crashes every few days mean something needs fixing, usually a driver or failing memory.

For an analyst

Note the provider: this is WER-SystemErrorReporting in the System log, distinct from Application Error 1000 and from Windows Error Reporting's own 1001 in the Application log. Confirm the provider before writing a rule. The dump path in the message is what actually resolves the crash — analyse it rather than guessing from the stop code alone.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
The computer has rebooted from a bugcheck.  The bugcheck was: 0x00000133 (0x0000000000000001, 0x0000000000001e00, 0xfffff80000000000, 0x0000000000000000). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 0a1b2c3d-0000-0000-0000-00000000abcd.

The fields that decide it

Everything else in the log line is context.

Bugcheck code
The stop code, written in hexadecimal. This names the class of fault and is the first thing to read.
  • 0x0000000aIRQL_NOT_LESS_OR_EQUAL — a driver accessed memory it should not have. Almost always a driver fault.
  • 0x0000001eKMODE_EXCEPTION_NOT_HANDLED — a kernel-mode component threw an error nothing caught.
  • 0x00000050PAGE_FAULT_IN_NONPAGED_AREA — commonly failing memory, sometimes a driver.
  • 0x0000007eSYSTEM_THREAD_EXCEPTION_NOT_HANDLED — usually a driver, and the message often names the file.
  • 0x00000133DPC_WATCHDOG_VIOLATION — a driver held the processor too long. Storage drivers are a frequent cause.
  • 0x00000124WHEA_UNCORRECTABLE_ERROR — the hardware itself reported an unrecoverable fault. This one genuinely means hardware.
  • 0x000000efCRITICAL_PROCESS_DIED — a process Windows cannot run without stopped.
  • 0x0000009fDRIVER_POWER_STATE_FAILURE — a driver failed to handle sleep or wake correctly.
Bugcheck parameters
Four values whose meaning depends entirely on the stop code. Only useful once you know which code you are dealing with.
Dump file path
Where the crash dump was written, normally C:\Windows\MEMORY.DMP or a minidump. This file is what actually identifies the faulting driver.

Ordinary reasons this happens

Most of the time it is one of these.

  • A one-off crash after a driver or Windows update, which does not recur.
  • Overclocked or incorrectly configured memory settings.
  • A hardware change that has not settled — new memory, a new graphics card, a new drive.
  • Third-party security software conflicting with a driver after an update.

When it is not ordinary

An unstable or malicious kernel driver.

What gives it awayRepeated crashes with the same stop code shortly after unfamiliar software was installed, particularly where the dump names a driver you do not recognise.

ATT&CK T1547.006

Security tooling being deliberately destabilised.

What gives it awayCrashes clustered around attempts to load or unload drivers, or coinciding with security software failing to start.

ATT&CK T1562.001

What to do next

  1. Read the bugcheck code and search for that specific code rather than for the event number.
  2. Note whether the same code recurs. A consistent code narrows the cause dramatically; varying codes point at memory or power.
  3. Open the dump file with a debugger or a dump reader — this is the step that names the driver, and skipping it turns the whole exercise into guesswork.
  4. For 0x124, test the hardware. That code means the processor or chipset reported the fault itself.
  5. For 0x50 and varying codes, run a memory test before anything else.
  6. Check what was installed or updated in the days before the first crash, and roll that back first.

Queries to run

powershell Filter by provider as well as ID — several components write an Event 1001 and they are unrelated.
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WER-SystemErrorReporting'; Id=1001} -MaxEvents 20 | Select-Object TimeCreated, Message | Format-List
powershell Lists the crash dumps. An empty folder usually means dump creation is disabled, which is worth fixing before the next crash.
Get-ChildItem C:\Windows\Minidump -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object Name, LastWriteTime, Length
wevtutil
wevtutil qe System /q:"*[System[(EventID=1001)]]" /f:text /c:10 /rd:true

Common questions

How do I find out which driver caused a blue screen?

Open the dump file named in the event — normally C:\Windows\MEMORY.DMP or a file in C:\Windows\Minidump. A dump reader or the Windows debugger will name the faulting module, which is the answer. The stop code alone narrows the class of problem but rarely identifies the specific driver.

What does bugcheck 0x00000133 mean?

DPC_WATCHDOG_VIOLATION. A driver held the processor for longer than Windows permits, so Windows stopped the machine rather than letting it hang. Storage and chipset drivers are the usual cause, and an outdated solid-state drive firmware is a classic source of this particular code.

Why is there no dump file after a blue screen?

Usually because dump creation is turned off, the paging file is too small or on the wrong drive, or free disk space ran out. Check System Properties, Advanced, Startup and Recovery and set it to write at least a small memory dump — otherwise the next crash will be just as opaque as this one.

Is Event 1001 always a blue screen?

Only when the provider is Microsoft-Windows-WER-SystemErrorReporting in the System log. Windows Error Reporting writes an unrelated Event 1001 into the Application log for ordinary application faults. Always check the provider before assuming which one you are looking at.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026