0xC0000005 on Windows: how to find which module crashed

Some app on your Windows box crashes. You search the crash code and get a wall of confident answers: update your graphics driver, run sfc /scannow, turn off XMP, reinstall Windows.

Most of that is a guess wearing a lab coat.

0xC0000005 is STATUS_ACCESS_VIOLATION. Windows defines it as the thread trying to read from or write to a virtual address for which it does not have the appropriate access. If your tool reports decimals instead of hex, the same code shows up as 3221225477. It's the most common crash code on Windows and the least useful one on its own, because almost anything can produce it.

Windows already wrote down what faulted. You just have to read the evidence in the right order.

Event 1000 names the module

Event Viewer, Windows Logs, Application, source Application Error, event ID 1000. I'd start there every time. If you'd rather not click through the UI:

Get-WinEvent -FilterHashtable @{LogName='Application';ProviderName='Application Error';Id=1000} -MaxEvents 20 |
  Select-Object TimeCreated,
    @{N='Exception';E={$_.Properties[6].Value}},
    @{N='Module';E={$_.Properties[3].Value}},
    @{N='PID';E={$_.Properties[8].Value}},
    @{N='ModulePath';E={$_.Properties[11].Value}},
    @{N='ReportId';E={$_.Properties[12].Value}}

The Module column is the whole point. 0xc0000005 in the Exception column confirms you're looking at an access violation and not something else wearing the same exit code.

One gotcha: when the faulting module is ntdll.dll or kernelbase.dll, you're usually looking at the messenger, not the culprit. Those are the most common places for a crash to surface because they do the memory work for everything else. The module you want is the last non-Microsoft one in the dump's stack.

Property order has been stable for years, but if your columns look shifted, open a single event's Details tab and read the field names instead of trusting the index numbers.

If there is no event 1000, turn dumps on

No Application Error entry means Windows Error Reporting never got a chance. Some apps die below the crash handler, usually very early in startup, and that absence is a clue in itself: it points at the GPU process or a native module load rather than application logic.

You can force dumps to be kept. From an admin shell:

$k = 'HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps'
New-Item -Path $k -Force
New-ItemProperty -Path $k -Name DumpFolder -PropertyType ExpandString -Value '%LOCALAPPDATA%\CrashDumps' -Force
New-ItemProperty -Path $k -Name DumpType -PropertyType DWord -Value 2 -Force
New-ItemProperty -Path $k -Name DumpCount -PropertyType DWord -Value 10 -Force

DumpType 2 is a full dump, which is what you want while the cause is still unknown. Dumps land in %LOCALAPPDATA%\CrashDumps; WER's own archives live under C:\ProgramData\Microsoft\Windows\WER\ReportArchive and ReportQueue. Then reproduce the crash.

Read the dump without installing Visual Studio

You don't need the IDE. Install just the "Debugging Tools for Windows" component from the Windows SDK, then point cdb at the dump:

cdb.exe -z "%LOCALAPPDATA%\CrashDumps\app.exe.1234.dmp" -c "!analyze -v; q"

Three things in that output matter. FAULTING_IP is the instruction that faulted. The EXCEPTION_RECORD gives you the ExceptionAddress and the code. STACK_TEXT is the call stack, and it names the module whose code was actually running. DEFAULT_BUCKET_ID is a loose classification you can search on to see if other people hit the same shape of crash.

The exception parameters also carry direction. ExceptionInformation[0] is 0 for a read, 1 for a write, 8 for an execute. A read violation means the thread dereferenced a pointer it couldn't read: garbage, or memory that was already freed. A write violation means something wrote where it had no business writing. Both are useful, but neither names a culprit without the stack.

Rule out hardware and drivers first

The System log tells you whether you're chasing software at all:

• WHEA-Logger events 17 and 18 are corrected hardware errors; 19 is uncorrected. If those show up next to your crashes, stop and test the RAM with mdsched.exe (MemTest86 if you want a real answer). Memory and PCIe are the usual sources.
• "Display driver amdwddmg stopped responding and has recovered" is a TDR, event 4101. That's the GPU and driver path, and it explains a lot of access violations in GPU-accelerated apps.
• Kernel-Power 41 shows up after any unclean shutdown. Everyone reads it as a diagnosis. It isn't one. It's a marker that the machine went down hard, and on its own it names no cause.

Be suspicious of the confident answers

Two claims I'd flag, partly because I've repeated them myself:

The first: "the fault offset is always the same but the bad address changes, so it's bad RAM." That pattern does look more like corruption than a logic bug, and testing memory is a fair response to it. But it isn't documented as proof of anything. It can be bad RAM, a freed object, or a native module built against the wrong SDK, and only the dump separates those.

The second: "update the GPU driver, or switch the inference engine, and it goes away." Sometimes it does. While reading threads for this piece I found one where the suggested engine switch was tried by a second person and crashed for them too. Gone was the fix; the experiment stayed. Treat driver updates and engine switches as cheap things to try, not as advice you can hand someone else as an answer.

Same story with the launch-flag soup you'll find in older threads. --disable-gpu is a legitimate diagnostic because it moves rendering out of the GPU process. --no-sandbox is not a fix. It disables the sandbox. Chromium's own documentation says it's for testing, so don't leave it sitting in your daily configuration.

If the crash disappears after a clean boot, that's your answer: antivirus, overlays like RTSS or MSI Afterburner, and shell extensions all inject code into live processes, and all of them cause access violations.

The short version

0xC0000005 means "bad memory access". It does not mean bad RAM, and it doesn't mean the module named in the log is buggy. Event 1000 gets you the module, the dump gets you the function, and WHEA plus TDR tell you whether you're in hardware territory at all. Ten minutes of reading, most of it spent waiting for a dump to load.

I could be wrong about your specific crash. But if you're staring at this code with nowhere to start, the Event 1000 module name is the best first click you can make.