偶尔（唉...）我的代码在某个系统上崩溃了;很多时候，我的用户会发送Windows崩溃对话框的截图。例如，我最近收到了这个：
Unhandled win32 exception @ 0x3a009598 in launcher2g.exe: 0xC00000005: Access violation writing location 0x00000000.
我很清楚（由于0xc0000005代码以及写出的错误消息）我在launcher2g.exe进程中的某个地方跟随空指针。我不清楚的是'0x3a009598'数字的重要性。这是存储汇编指令的进程'地址空间中的代码偏移量，它触发了问题吗？
假设0x3a000000是launcher2g.exe模块加载到进程中的位置，我使用Visual Studio调试器检查汇编代码为0x3a009598但不幸的是，这只是很多'int 3'指令（这个是一个调试版本，因此有很多int 3填充。）
我一直想知道如何充分利用这些@ 0x12345678数字 - 如果有人能够对此有所了解，或者分享一些指示以进一步解释，那将会很棒。
更新：如果将来有人发现这个问题，我发现这是一篇非常有趣的读物，它解释了如何理解错误信息，如上所述：Finding crash information using the MAP file
答案 0 :(得分：2)
0x3a009598将是导致崩溃的x86指令的地址。
EXE通常以其首选加载地址加载 - 通常为0x04000000 iirc。所以它可能血腥远离0x3a009598。该进程加载的某些DLL可能位于此地址。
如果您可以让用户生成并发送崩溃转储，那么崩溃转储通常是调试此类事情的最有用方法。您可以使用Visual Studio 2005及更高版本加载它们，并获得系统dll的自动符号解析。
接下来，构建过程生成的.map文件应该可以帮助您确定有问题的函数 - 假设您确实设法找出崩溃所在的exe / dll模块，以及它的实际加载地址是什么。
在XP上，用户可以使用DrWatsn32生成并向您发送崩溃转储。在Vista及更高版本中，Windows错误报告将故障转储写入c：\ users \\ AppData \ Local \ Temp * .mdmp