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.