如何使用WinDbg来分析崩溃转储为VC ++应用程序？ [英] How to use WinDbg to analyze the crash dump for VC++ application?

问题描述

如何使用 WinDbg 分析转储文件？

首先，你必须改变你的编译器的设置。它创建PDB文件，即使是发布版本。默认情况下， Visual C ++ 编译器的后续版本会执行此操作，但在许多Visual C ++版本中，您必须自己执行此操作。创建程序数据库文件，然后保存这些文件的归档以及每个应用程序的构建。至关重要的是，您的应用程序的每个构建都有自己的一组PDB。例如，你不能仅仅使用你用build 10创建的那些来检查由build 15生成的转储。在您的项目的整个生命周期中，您将最终获得大量的PDB，所以请做好准备。

接下来，您需要能够识别确切的版本的生成转储文件的应用程序。如果您正在创建自己的MiniDumps（通过调用 MiniDumpWriteDump（）），可能是最简单的方式做到这一点是简单地使MiniDump的文件名的一部分您的应用程序的完整版本号。您需要有一个合理的版本编号方案，以使其工作。在我的商店中，我们会在每次自动建立程序创建一个构建时，将所有分支上的构建号增加一。

现在您已经收到客户的转储文件知道创建转储的应用程序的精确版本，并且您已找到此生成的PDB文件。

现在，您需要查看源代码控制的历史记录，并找到该软件的精确版本的源代码。最好的方法是每次你构建一个应用标签到您的分支。

您几乎准备好启动WinDbg / Visual C ++：

1. 获取该版本应用程序的完整源代码树。将它放在硬盘驱动器上的单独位置，对于应用程序版本1.0 build＃100， c：\app_build_1.0.100 。


2. 获取应用程序的精确版本的二进制文件，并将它们放在您的硬盘驱动器上的某个位置。


3. 将PDB文件放在与步骤2中的二进制文件相同的位置。

现在，您有两个选项可以查看转储文件。您可以使用 Visual Studio 或WinDbg。使用Visual Studio更容易，但WinDbg更强大。大多数情况下，Visual Studio中的功能就足够了。

要使用Visual Studio，您只需打开转储文件就像是一个项目。一旦打开，运行转储文件（默认情况下为 F5 ），如果所有的路径都设置正确，你可以直接找到崩溃的代码，给你一个调用堆栈等。 p>

要使用WinDbg，您必须跳过几个圈子：

1. WinDbg


2. 打开转储文件。 （默认情况下为 Ctrl + D ）


3. 告诉WinDbg去获取正确的MicroSoft符号文件。键入 .symfix 。这可能需要一些时间，因为它会从互联网上拉出一大堆资料。


4. 告诉WinDbg符号（PDB文件）在哪里。键入 .sympath + c：\pdblocation ，替换为放置PDB文件的路径名。确保你在那里加号，在 .sympath 和 + 符号之间没有空格，否则你会拧紧步骤3.


5. 告诉WinDbg源代码在哪里。键入 .srcpath c：\app_build_1.0.100 替换您从此版本软件的源代码控制中获取代码的路径。


6. 告诉WinDbg来分析转储文件。键入！analyze -v

正确地，WinDbg会带你到你的崩溃的位置。在这一点上，你有一百万个选项深入挖掘你的应用程序的内存空间，关键部分，窗口等的状态。但这是超出了这篇文章的范围。

祝你好运！

How do I use WinDbg for analyzing a dump file?

解决方案

Here are some general steps that will get you on your way:

First, you must change your compiler's settings so that it creates PDB files, even for release builds. Later versions of the Visual C++ compiler do this by default, but in many versions of Visual C++ you must do this yourself. Create program database files, and then keep an archive of those files along with each build of your application. It is critical that every build of your applications has its own set of PDBs. You can't just reuse the same ones you made with build 10 to examining the dumps generated by build 15, for example. Over the life of your project, you will end up with a ton of PDBs, so be prepared for that.

Next, you need to be able to identify the exact version of your application which generated the dump file. If you are creating your own MiniDumps (by calling MiniDumpWriteDump() for example), probably the easiest way to do this is to simply make part of the filename of the MiniDump the complete version number of your application. You'll need to have a reasonable version numbering scheme in place for this to work. In my shop, we increment the build number across all branches by one every time the autobuilder creates a build.

Now that you have received the dump file from the customer, you know the precise version of the application that created the dump, and you have found the PDB files for this build.

Now you need to go through your source control's history and find the source code for this exact version of the software. The best way to do this is to apply 'labels' to your branches every time you make a build. Set the value of the label to the exact version number, and it becomes easy to find in the history.

You're almost ready to fire up WinDbg/Visual C++:

1. Get the complete source tree for that version of your application. Put it in a separate place on your hard drive, say c:\app_build_1.0.100 for application version 1.0 build #100.
2. Get the binaries for that exact version of your application and put them somewhere on your hard drive. It might be easiest simply to install that version of your application to get the binaries.
3. Put the PDB files in the same location as the binaries in step 2.

Now you have two options for viewing the dump file. You can use Visual Studio or WinDbg. Using Visual Studio is easier, but WinDbg is much more powerful. Most of the time the functionality in Visual Studio will suffice.

To use Visual Studio, all you have to do is open the dump file like it is a project. Once opened, "run" the dump file (F5 by default) and if all the paths are set correctly it will take you right to the code that crashed, give you a call stack, etc.

To use WinDbg, you have to jump through a couple of hoops:

1. Start WinDbg
2. Open the dump file. (Ctrl + D by default)
3. Tell WinDbg to go get the correct MicroSoft symbol files. Type .symfix. This may take a few moments as it will pull a ton of stuff down from the Internet.
4. Tell WinDbg where the symbols (PDB files) are. Type .sympath+ c:\pdblocation, substituting wherever you put the PDB files for the pathname. Make sure you get the plus sign in there with no whitespace between .sympath and the + sign or else you'll screw up step 3.
5. Tell WinDbg where the source code is. Type .srcpath c:\app_build_1.0.100 substituting the path where you got code from source control for this version of the software.
6. Tell WinDbg to analyze the dump file. Type !analyze -v

After a few moments, if everything is configured correctly, WinDbg will take you right to the location of your crash. At this point you have a million options for digging deep into your application's memory space, the state of critical sections, windows, etc. But that is way beyond the scope of this post.

Good luck!

这篇关于如何使用WinDbg来分析崩溃转储为VC ++应用程序？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！