When programming sometimes things break. You made a mistake and your program tries to read from a wrong address.
One thing that stands out to me that often those exceptions are like :
Access violation at address 012D37BC in module 'myprog.exe'. Read of address 0000000C.
Now I see a lot of error logs and what stands out to me is the : 0000000C. Is this a “special” address? I see other access violations with bad reads but the addresses just seem random, but this one keeps coming back in totally different situations.
3
00000000 is a special address (the null pointer). 0000000C is just what you get when you add an offset of 12 to the null pointer, most likely because someone tried to get the z member of a structure like the one below through a pointer that was actually null.
struct Foo {
int w, x, y; // or anything else that takes 12 bytes including padding
// such as: uint64_t w; char x;
// or: void *w; char padding[8];
// all assuming an ordinary 32 bit x86 system
int z;
}
17
In Windows it is illegal to dereference the entire first and last page, in other words the first or last 64 KiB of the process memory (the ranges 0x00000000 to 0x0000ffff and 0xffff0000 to 0xffffffff in a 32-bit application).
This is to trap the undefined behavior of dereferencing a null pointer or index into a null array. And the page size is 64 KiB so Windows just has to prevent the first or last page being assigned a valid range.
This won’t guard against uninitialized pointers that could have any value (including valid addresses).
12
As for why 0x0C seems more common than 0x08 (is it really? I don’t know; and in what kinds of applications?), this might have to do with virtual method table pointers. This is really more of a comment (wild mass guessing :), but it’s somewhat larger, so here goes… If you’ve got a class with virtual methods, its own fields are going to be shifted by 0x04. For example, a class that inherits from another virtual class might have a memory layout like this:
0x00 - VMT pointer for parent
0x04 - Field 1 in parent
0x08 - VMT pointer for child
0x0C - Field 1 in child
Is this a common scenario, or even close? I’m not sure. However, note that in a 64-bit application, this could get even more interestingly shifted towards the 0x0C value:
0x00 - VMT parent
0x08 - Field 1 parent
0x0C - VMT child
0x14 - Field 2 child
So there’s actually a lot of cases where applications might have significant overlap in null-pointer offsets. It might be the first field in a child class, or its virtual method table pointer – needed whenever you call any virtual method on an instance, so if you’re calling a virtual method on a null pointer, you’ll get access violation on its VMT offset. The prevalence of this particular value might then have something to do with some common API that provides a class which has a similar inheritance pattern, or more likely, a particular interface (quite possible for some classes of applications, like DirectX games). It might be possible to track some simple common cause like this, but I tend to get rid of applications that do null dereferencing pretty quickly, so…
2