地址0000000C是一个特殊地址吗？

编程时有时会中断。您犯了一个错误，程序尝试从错误的地址读取。

在我眼前一亮的是，这些例外通常是：

Access violation at address 012D37BC in module 'myprog.exe'. Read of address 0000000C.

现在，我看到了很多错误日志，而对我而言突出的是：0000000C。这是“特殊”地址吗？我看到了其他读取错误的访问冲突，但地址似乎是随机的，但是这种情况在完全不同的情况下会不断出现。

00000000是一个特殊地址（空指针）。0000000C就是在向空指针添加偏移量12时得到的结果，最可能的原因是有人试图z通过实际上为空的指针来获取以下结构的成员。

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;
}

在Windows中它是非法的解引用所述整个第一页和最后一页，换句话说，第一个或最后64 KIB进程内存的（范围0x00000000，以0x0000ffff及0xffff0000到0xffffffff在32位应用程序）。

这是为了捕获将空指针或索引解引用为空数组的不确定行为。而且页面大小为64 KiB，因此Windows仅需防止将第一页或最后一页分配给有效范围。

这不能防止可能具有任何值（包括有效地址）的未初始化指针。

至于为什么0x0C看起来比0x08（真的吗？我不知道；在哪种应用程序中？）更常见，所以这可能与虚方法表指针有关。这实际上是一个注释（大量猜测：），但是它更大一些，所以这里...如果您有一个带有虚方法的类，则其自身的字段将被移位0x04。例如，从另一个虚拟类继承的类可能具有这样的内存布局：

0x00 - VMT pointer for parent
0x04 - Field 1 in parent
0x08 - VMT pointer for child
0x0C - Field 1 in child

这是常见的情况，还是接近？我不确定。但是，请注意，在64位应用程序中，这可能更有趣地转向该0x0C值：

0x00 - VMT parent
0x08 - Field 1 parent
0x0C - VMT child
0x14 - Field 2 child

因此，实际上在很多情况下，应用程序在空指针偏移量上可能存在大量重叠。它可能是子类中的第一个字段，或者是其虚拟方法表指针-每当您在实例上调用任何虚拟方法时都需要它，因此，如果您在null指针上调用虚拟方法，则会在其实例上遇到访问冲突VMT偏移量。然后，此特定值的普遍性可能与某些通用API有关，该API提供具有相似继承模式或更可能是特定接口的类（对于某些类的应用程序，例如DirectX游戏，完全可能）。可能可能会跟踪到这样的一些简单的常见原因，但是我倾向于摆脱一些应用程序，这些应用程序会非常快地执行空取消引用，因此...