分析在Windows崩溃：什么错误消息告诉我们什么？ [英] Analyzing a crash in Windows: what does the error message tell us?
问题描述
我的一个小工具，我个人使用（用C ++编写）昨日作出随机崩溃（我用它大约100个小时迄今没有问题），而我通常不这样做，我是感觉有点冒险，想尝试和了解更多的问题。我决定进入事件查看器，看看有什么了的Windows登录有关崩溃的：
A small utility of mine that I made for personal use (written in C++) crashed randomly yesterday (I've used it roughly 100+ hours with no issues so far) and while I don't normally do this, I was feeling a bit adventurous and wanted to try and learn more about the problem. I decided to go into the Event Viewer and see what Windows had logged about the crash:
Faulting application StraightToM.exe, version 0.0.0.0, time stamp 0x4a873d19
Faulting module name : StraightToM.exe, version 0.0.0.0, time stamp 0x4a873d19
Exception code : 0xc0000005
Fault offset : 0x0002d160,
Faulting process id: 0x17b4
Faulting application start time: time 0x01ca238d9e6b48b9.
我的问题是，是什么做的每一个这些都意味着，我将如何使用这些调试我的计划？这是我目前所知：异常code介绍了误差，0000005是一个内存访问冲突（试图访问内存中它没有自己的）。我知道更多有关下列特别感兴趣：
My question is, what do each of these things mean, and how would I use these to debug my program? Here's what I know so far: exception code describes the error, and 0xc0000005 is a memory access violation (tried to access memory it didn't own). I'm specifically interested in knowing more about the following:
- 什么是错的偏移是什么意思？这是否再present哪里出错，还是意味着组装'行'，其中错误发生在文件中的位置？知道了故障偏移，我怎么会使用一个程序像OllyDbg中找到对应的汇编code导致错误？或者 - 甚至更好 - 也才有可能（容易）确定哪些订单在C ++源代码code造成此错误 ？
- 很明显，时间戳对应于32位UNIX时间在崩溃的时候，但到底是什么64位应用程序启动时间是什么意思？为什么它会是64位，如果时间戳是32？
请注意，我主要是C ++程序员，所以虽然我知道一些关于组装，我对它的了解是非常有限的。此外，这真的不是一个需要修复一个严重的问题（也是不容易复制，因为程序的性质），我只是使用这种更以此为借口进一步了解这些错误信息的意思。大部分关于我在网上找到的通常是针对最终用户的这些崩溃日志中的信息，所以他们并没有帮助我（作为程序员）非常多。
Note that I'm primarily a C++ programmer, so while I know something about assembly, my knowledge of it is very limited. Additionally, this really isn't a serious problem that needs fixing (and is also not easily reproduced, given the nature of the program), I'm just using this more as an excuse to learn more about what these error messages mean. Most of the information about these crash logs that I've found online are usually aimed at the end-user, so they haven't helped me (as the programmer) very much.
在此先感谢
推荐答案
在时间的应用程序的主线程在100纳秒的时间间隔自1601年1月1日（UTC）（这被称为创造的64位的时间戳 FILETIME ）。 32位时间戳确实是在 time_t的格式（它告诉模块创建的时间并存储在模块的标头）。
The 64-bit time stamp is the time application's primary thread was created in 100-nanosecond intervals since January 1, 1601 (UTC) (this is known as FILETIME). The 32-bit timestamp is indeed in time_t format (it tells the time the module was created and is stored in the module's header).
我说0x0002d160是从模块的加载地址偏移量（这似乎太低了绝对地址）。火了Visual Studio中，启动调试器，看看模块调试窗口。你的exe文件应该被列出。寻找到模块被加载的地址，0x0002d160添加到地址，并看看在结果地址拆卸。 Visual Studio中显示源$ C $ C与装配混合，你应该没有问题搞清楚什么电源线造成的问题。
I'd say 0x0002d160 is an offset from the module's load address (it seems too low for an absolute address). Fire up Visual Studio, start the debugger, take a look at the "modules" debug window. Your exe file should be listed there. Find the address where the module is loaded, add 0x0002d160 to that address and take a look at the disassembly at the resulting address. Visual Studio shows source code intermixed with the assembly, you should have no problem figuring out what source line caused the problem.
这篇关于分析在Windows崩溃：什么错误消息告诉我们什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
