To put it simply, an access violation occurs any time an area of memory is accessed that the program doesn't have access to. This can be due to bad code, faulty RAM or even a bad device driver. It really doesn't matter who the culprit is, the root issue is basically the same. For instance, memory location zero is reserved for the operating system, so any application that tries to access this address will crash with an access violation. The problem with this is that it is very easy to end up with a value of zero. If you set a pointer and initialize the value to NULL (which is 0), then try to access it, you will crash in this fashion. We call this a NULL Pointer and it is very common. The error you will receive should be similar to the following:
Unhandled exception at 0x00032b15 in Application.exe: 0xC0000005: Access violation reading location 0x00000000
This states that the program Application.exe, which was loading at the arbitrary address 0x00032b15, attempted to read address 0x00000000. The code 0xC0000005 is the code for access violation, so expect to see this quite a bit. In a memory or user dump, you may see if referred to as STATUS_ACCESS_VIOLATION. This type of error can occur when either reading or writing, so it is pretty common. Below is an example of how this may look in a bugcheck dump, by simply doing a "!analyze -v". In this case, it was due to a driver fault causing an access violation.
You will also get an access violation if a program triggers Data Execution Prevention (DEP). This is a feature that uses both hardware and software to minimize the threat of malicious code like viruses. How this works is that memory locations can be marked as being used either for executable code or for data. Viruses commonly dump their payload into a data location and then execute it from there (like in a buffer overflow scenario). This is exactly what DEP is designed to prevent. If something tries to execute code from a data location, DEP will trigger an access violation to protect the system. The reason this is important to us is that some applications do the same thing simply due to the application's programmer not quite following the rules. For instance, if an application dynamically generates code, such as in a Just-In-Time scenario, and do not explicitly mark the code as executable, they will run into the Wall of DEP (OK, I couldn't resist the pun).
I hope this helps explain some of the common causes of access violations. See you next time.
| Share this post : |
|
|
|
|
|