windows - What exactly is the scope of Access Violation '0xc0000005'?

Question

I was wondering about exception 0xc0000005 and what it acctually encompasses.

I.e. I take it this occurs if an application tries to access freed memory/memory belonging to another process.
But what about, for example, an address mapped for hardware? Or an address outside the valid range? Do attempted accesses to these fault with the same code or do they have their own? Does this include failed reads to valid addresses owned by the process?

Essentially I want to know when an application fails with this exception, what may have gone wrong; is this a narrow fault that could only have come from the apps. code or am I looking at anything up and including hardware problems?

(I know there must be an MSDN page on this but searching Google or MSDN brings up the expected 100 pages of troubleshooting random applications ;))

Thanks!

Answer 1

You need to read the processor manual to drill this down. It is triggered by a "trap", best described as an exception in the processor. A trap interrupts code execution and lets an operating system "catch" handler deal with the fault. A very common benign one is a page fault, raised when the processor tries to read data from RAM that isn't mapped yet. That's how virtual memory is implemented.

An AccessViolation belongs to a group of traps that are hard faults that the operating system doesn't know how to handle. It is called "General Protection Fault" in the processor manual. It's a bit of a grab-bag, there are lots of ways to trigger a GPF. By far the most common one is trying to read memory that isn't mapped, usually caused by heap memory corruption. Followed by trying to execute a machine code instruction that isn't valid or can only be executed by privileged code, usually caused by stack memory corruption.

These traps are as nasty as they come, the processor simply cannot continue executing the program. The operating system certainly doesn't know how to handle it, it raises an AccessViolation exception to give the program a shot at jerking the processor back to known-good code. Possible by using the __try/__except keywords in your code. Not a great idea btw, other than for custom error reporting, you have no real idea how the state of your program got mutated before it died and thus no way to restore it back.

Without such an SEH handler, this ends up in a backstop that Windows provides. You can provide your own with SetUnhandledExceptionFilter(), useful to customize the crash report. The system-provided one puts an end to it by triggering WER, the Windows Error Reporting component. Which ultimately terminates the process.