The short version
- 01Identify the application and record the exact action that triggers 0xc0000005.
- 02Compare whether one application fails or unrelated applications also crash.
- 03Use the affected application's available Windows Repair option.
- 04Preserve the full error, application version and repeatable trigger for the publisher.
- 05As the developer, inspect the exception parameters, context and call stack with the documented debugger workflow.
- 06Escalate a persistent crash with that evidence before treating the code as a confirmed memory-hardware fault.
Raw message
0xc0000005 — access violation
Likely causes
- An application reads, writes or executes an invalid address.
- Invalid pointers, memory corruption or use-after-free can cause the exception.
- Microsoft also lists a hardware bit flip as a rare possibility, not the default diagnosis.
The exception is about an invalid address
Microsoft defines this exception as a read, write or execute at an invalid memory address. It lists invalid pointers, memory corruption and use-after-free among possible causes; a hardware bit flip is rare. Our first comparison records the failing app and action, then asks whether unrelated apps also fail.
Keep the application's repair separate from the diagnosis
Windows' generic app-repair procedure is available for some installations. Use Repair where offered and retain the result. This is an application-maintenance step, not a claim that every access violation comes from corrupted installation files. Our recommendation is to give a repeatable trigger and app version to the software publisher.
Developers: read the operation and address from the exception
Microsoft's debugger workflow uses .exr -1 for the exception, .ecxr for the context and k for the call stack. The first exception parameter identifies read (0), write (1) or execute (8); the second identifies the address. Those details let the developer investigate the failing instruction instead of guessing from the hexadecimal code.
Sources and review notes
Checked on . Based on Microsoft's access-violation explanation and generic app-repair procedure. Comparing application scope and recording the trigger are editorial guidance. Debugger steps are for a developer investigating the crash; this page does not equate an invalid address with insufficient RAM. Glitchary is independent of Microsoft.