0xC0000005 — Access violation

Error 0xC0000005, shown by Windows as an “Access violation”, means that a program or driver tried to read from or write to memory that it does not own. The processor protected that address, the operating system caught the attempt, and the process was stopped to keep the rest of the system stable. In practice 0xC0000005 — Access violation is one of the most common crash codes on Windows, and it nearly always has a hardware or driver cause rather than a fault in the app that reported it.

What it means

Windows gives every process its own virtual address space and marks each page as readable, writable, executable or none of those. When code touches a page it is not allowed to use, the memory manager raises an access violation. If the offender is a user program, Windows closes just that program; if it happens inside the kernel, the result is a blue screen. The status code 0xC0000005 is the same in both cases — it only describes the memory fault, not who caused it.

The tricky part is that the program that crashes is usually not the one at fault. A faulty driver can corrupt memory used by a completely unrelated application, so a browser tab or a game may die while the real culprit is a network, storage or graphics driver. This is why blaming the crashing app rarely fixes anything: the fault lies wherever the bad memory access originated.

Two broad conditions produce the code. In the first, software genuinely has a bug — a stale pointer, a buffer overrun or a use of memory after it was freed. In the second, the hardware underneath is unreliable: RAM that returns wrong bits, or a driver that mishandles a buffer, plants the error in memory for someone else to trip over later. Telling the two apart is the whole point of the diagnostic steps below.

Common causes

• A faulty or outdated device driver, especially graphics, chipset, network and storage drivers.
• Defective RAM or memory running at unstable settings such as an aggressive XMP/EXPO profile or overclock.
• Corrupt or incompatible software, including badly written plugins and shell extensions that load into other processes.
• Data Execution Prevention or security software blocking a legitimate code region, causing a false-positive crash.
• Corrupt system files or a failing disk that damages the code loaded into memory.

How to fix it

1. Note what you were doing, then update your drivers. If the crash repeats in one program, update that program and the drivers it uses. For graphics drivers, use a clean install option so old files are removed.
2. Test the memory. Run the built-in Windows Memory Diagnostic (mdsched.exe) or a longer off-line test such as MemTest86. Test one stick at a time; if errors appear, replace the module.
3. Return to stock settings. If you enabled an XMP/EXPO memory profile or overclocked the CPU or GPU, disable it and retest. Unstable memory timings are a common trigger that only shows under load.

   mdsched.exe
   sfc /scannow
   DISM /Online /Cleanup-Image /RestoreHealth

4. Isolate the failing component. Check Event Viewer › Windows Logs › Application for the faulting module name. If it is a .sys driver, uninstall or roll back that device's driver; if it is a .dll from a vendor, reinstall that product.
5. Repair Windows and scan for malware. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth, then a full malware scan. Corrupt or tampered system files frequently produce this code.

How to prevent it

Stability starts with certified memory and drivers. Use RAM on the motherboard's qualified list, avoid pushing timings beyond what the platform is rated for, and keep the machine clean and cool so components do not degrade. Install drivers from the manufacturer rather than generic bundles, and be cautious with tweaking or monitoring tools that hook deep into the kernel, because those hooks are exactly where bad memory access begins.

Keep Windows and your security software current so known driver bugs are patched, and avoid stacking multiple real-time security products, which can conflict and suppress legitimate code. When you add new hardware, do it one change at a time so that if a crash returns you already know which device introduced it. A short log of recent changes turns a mysterious random crash into a traceable regression.