32

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.

  • 1
    I've also noticed that 0000000C is way more common than 00000008, but none of the answers seem to address that at all :/ – Mooing Duck Jan 21 '15 at 0:41
  • 2
    Perhaps that System.Runtime.CompilerServices.RuntimeHelpers.OffsetToStringData is 12=0x0C is a reason why this offset is more common. – Mark Hurd Jan 21 '15 at 9:47
  • 1
    @MarkHurd That's scary. Do you really think that there's so many unmanaged applications that on purpose read / write .NET strings that this would be a major source of access violations? – Luaan Jan 21 '15 at 13:28
58

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;
}
  • 29
    Or maybe because some small integral value was mistakenly dereferenced as if it were a pointer. Small values are much more common than huge values, so this tends to produce illegal adresses like 0X0000000C rather than, e.g., 0x43FCC893. – Kilian Foth Jan 20 '15 at 8:58
  • 3
    The reason I asked this question is because 0000000C comes back so often compared to other adresses. Why is offset 12 a magnitude more common then offset 4, 8 or 16 ? – Pieter B Jan 20 '15 at 10:32
  • 5
    After further investigation this answer is totally correct. In my source the "tag" property of classes is used extensively (either good or bad I have to deal with it.) The tag property in my case is part of a low level base class and it got always created at that offset. – Pieter B Jan 20 '15 at 10:58
  • 1
    Excellent point. Perhaps null pointer case was covered, but null pointer ++ is just a normal (and in this case invalid) address, thus it fails only upon accessing it. – Neil Jan 20 '15 at 11:47
  • 8
    @Leushenko Yes, memory protection usually works on whole pages, and even if it was possible to only catch 0, it's preferable to also protect the following addresses because they're likely to be accessed if pointer arithmetic with a null pointer happens (as in OP's case). – user7043 Jan 20 '15 at 14:39
11

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).

  • 7
    Windows can't really do that. Page table is a structure defined and required by x86, and small pages are fixed at 4KB. It's set in stone (more precisely, in silicon). The 64KB is probably for convenience. – ElderBug Jan 20 '15 at 12:01
  • 12
    I'd rather write 64 KiB instead of 65 kB in this case, since the power-of-two size is relevant. – CodesInChaos Jan 20 '15 at 12:11
  • 4
    The 64KB range is a left over from the Aplha version of NT. And it's not the page size, but the allocation granularity. blogs.msdn.com/b/oldnewthing/archive/2003/10/08/55239.aspx – shf301 Jan 20 '15 at 17:25
  • 3
    @CodesInChaos: While uppercase "M", "G", and "T" are ambiguous, I see no reason to deprecate the use of "k" for 10^3 and "K" for 2^10. – supercat Jan 20 '15 at 19:07
  • 2
    @MooingDuck Yes indeed, that's why I precised small pages. Most x64 CPU also support the 1GiB pages. As far as I know, Windows always pages with 4KB pages, unless allocated with special APIs. – ElderBug Jan 20 '15 at 21:00
2

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...

  • 1
    If you look through the comments, you can reduce the guessing considerably. – Deduplicator Jan 21 '15 at 13:23
  • @Deduplicator Well, I find the idea that managed .NET strings are used in unsafe code with manual pointer operations scary, and the thought that this would be the major cause for access violations even more so. "Yeah, this is totally memory safe, don't worry, we used C#. We just manually modify the memory from C++, but it's safe in C#." – Luaan Jan 21 '15 at 13:26

protected by gnat Jan 21 '15 at 9:50

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.