minidump详细介绍

一、什么是minidump?

Minidump,也被称为小转储,是Windows操作系统在应用程序或系统发生异常或崩溃时生成的一种文件。 minidump文件通常包含导致应用程序或系统崩溃的堆栈跟踪、寄存器、内存分配和其他有用的信息。使用适当的工具和符号,可以对Minidump文件进行分析,以找出造成崩溃的代码行。

二、生成minidump文件的原因:

Minidump文件通常在以下情况下生成:

1.应用程序崩溃: 当应用程序意外终止时,Windows会生成minidump文件,其中包含有关崩溃的有用信息,如对话框、可读的字符串、内存内容等。

2.系统崩溃:Windows操作系统也会像应用程序一样生成minidump文件,记录有关系统崩溃的详细信息。通常,在这种情况下,Windows会在重新启动后提示您,指导您将minidump文件发送给适当的技术支持团队。

三,如何利用minidump文件来调试应用程序和系统崩溃:

要分析minidump文件,需要使用适用于Windows的调试工具和符号。下面介绍一些常用的调试工具和符号:

1.WinDbg调试器:Windows提供了一款功能强大的调试器WinDbg,使用WinDbg可以分析minidump文件并定位崩溃来源的代码。

2.Symbols:符号是程序代码与编译器产生的二进制文件之间的桥梁。符号表包含了有用的信息,如函数和变量的名称,以及编译器生成的行号和调试信息。要分析minidump文件,需要将符号文件加载到WinDbg中,以便我们可以查看应用程序代码。

3.SymChk工具:SymChk工具可以帮助您确定Minidump所需的符号文件。

四、如何手动生成minidump文件:

如果您需要在应用程序发生崩溃时手动生成minidump文件,则可以使用以下方法:

1.使用Visual Studio调试器: 在Visual Studio调试器中,在应用程序崩溃时,您可以选择生成Dump文件。将光标放在相应的行上,选择 调试->生成Dump文件。

2.使用ProcDump命令行实用程序: ProcDump是一个命令行实用程序,可以在应用程序崩溃时生成minidump文件。用法如下:

procdump -ma -e

其中,-ma用于生成完整的内存转储,-e用于在应用程序崩溃时自动生成minidump文件。

五、minidump案例介绍:

1.分析应用程序崩溃的原因:

假设我们有一个简单的C#控制台应用程序,它的作用是将指定的数字除以0.我们可以选择让该应用程序正常运行并退出,或者让该应用程序引发未处理的异常。以下是代码:

```csharp

using System;

namespace ConsoleApp

{

class Program

{

static void Main(string[] args)

{

int numerator = 10;

int denominator = 0;

int result = numerator / denominator; // Dividing by zero

}

}

}

```

在Visual Studio中,我们可以选择让该应用程序引发未处理的异常,这样就会生成Minidump文件。下面是步骤:

1.打开Visual Studio和ConsoleApp项目。

2.选择调试 -> Windows -> 异常设置,在“常规”选项卡上,选中 “开启异常捕获 (全局)” 复选框。

3.在“常规”选项卡上,选中 “开启不能处理的异常” 复选框。

4.单击“OK”保存更改并重新开始调试。

5.现在重新运行该应用程序,将窗口关闭,然后在Visual Studio中单击“继续”,这样应用程序就会引发未处理的异常,从而生成Minidump文件。

6.可以通过Visual Studio打开Minidump文件,单击“调试”,然后选择“用调试器打开捕获的快照(DLL)”,就可以看到像下面这样的结果:

```

(7008.163c): Unknown exception - code c0000094 (first chance)

(7008.163c): Unknown exception - code c0000094 (first chance)

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -

```

此文件首先引发了未知异常,并指出无法找到符号文件。随着进程返回到 Windows 下,Minidump 文件被创建。以下是该文件的简要内容:

```

Microsoft (R) Windows Debugger Version 10.0.19041.1 AMD64

Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [D:\dumps\ConsoleApp-210624-235653.dmp]

User Mini Dump File with Full Memory: Only application data is available

Comment: 'Exception thrown (first chance)'

Symbol search path is: srv*

Executable search path is:

Windows 10 Version 19042 MP (4 procs) Free x64

Product: WinNt, suite: SingleUserTS

19042.1052.amd64fre.vb_release.190528-1742

Machine Name:

Debug session time: Thu Jun 24 23:56:53.000 2021 (UTC + 8:00)

System Uptime: not available

Process Uptime: 0 days 0:00:00.031

....................................................

.........................................

Probably caused by : ntdll.dll ( ntdll!_report_gsfailure+26 )

```

从该文件中可以看出,引发崩溃的模块是“ntdll.dll”,该模块发现了一些不良内存行为并引发了异常。像上面这样的Minidump文件能够帮助我们快速找出程序的异常来源。

2.分析系统崩溃的原因:

当操作系统崩溃时,Windows会生成更高级别的minidump文件,其中包含有关系统崩溃的更多信息,如:

堆栈跟踪和寄存器内容,以及指向导致崩溃的特定线程的指针;

Windows 错误报告信息;

与操作系统相关的其他调试信息。

这些信息可以通过Windows错误报告或在WinDbg中使用内联的.symfix和.symstore命令和符号服务器(如Microsoft符号服务器)进行分析。下面是一个简单的例子:

1.首先,让我们找到一个导致系统崩溃的Scilab应用程序,然后让Windows自动生成Minidump文件。可以按照以下步骤进行:

在Scilab中运行以下命令:

```cmd

[retval] = tempname(TMPDIR);

```

将其复制粘贴到Scilab代码编辑器中,单击“运行”。

关闭Scilab进程。在Windows 显示器中,Scilab 进程在后台运行,可以在任务管理器中查看或关掉该进程。

Windows 显示器显示“Scilab.exe 已停止工作”错误,并提供“关闭”按钮。

通过单击“关闭”按钮,可以将 minidump 文件保存到本地计算机上。

2.现在,使用WinDbg打开Minidump,加载Windows符号表并进行调试。以下是指南:

下载和安装Windows SDK。

打开WinDbg,单击“文件”,选择“打开崩溃转储”。

选择之前保存的Minidump文件。

如果出现以下消息,则应检查路径是否正确,并单击“OK”:

```

Could not automatically determine the user-specified directories to search for executable files. Windbg.exe does not have any information about the symbol paths you use. Symbol Loading may be slow, due to network and the size of the symbol files being loaded. Use .symfix and .symfix+ to configure your symbol paths.

```

在WinDbg的命令行上输入以下命令:

```

.symfix+; .reload /f

```

这个命令会告诉WinDbg使用符号路径服务查找符号,并强制重新加载模块。

在WinDbg的命令行上输入以下命令:

```

!analyze -v

```

此命令启动分析,并生成以下输出:

```

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

KERNEL_MODE_HEAP_CORRUPTION (13a)

The user mode heap manager has detected corruption in a heap. Typically this

indicates that a heap pointer has been corrupted or overwritten. If you look

back in the stack for any function named RtlHeapTrkX or for a function such

as RtlFreeHeap that calls RtlpLogHeapFailure, you may find the culprit.

Arguments:

Arg1: 0000000000000021, Type of corruption: scrub after a queue

Arg2: 0000000017e40000

Arg3: 0000000017e40d5e

Arg4: 0000000000000000

Debugging Details:

------------------

Unable to load image Unknown_Module_00000000`01000000, Win32 error 0n2

*** ERROR: Module load completed but symbols could not be loaded for Unknown_Module_00000000`01000000

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner

---------

```

该Minidump文件指出了一个指向内核级别堆的损坏。此处显示我们应该查找一个名为RtlHeapTrkX的函数或RtlFreeHeap的函数以查找崩溃源。但该Minidump文件没有其他有用的信息,因此可能需要保存缩小搜索范围的崩溃数据,并将信息提供给操作系统供应商。

六、总结

minidump文件是操作系统在应用程序或系统发生异常或崩溃时生成的一种文件,通常包含导致应用程序或系统崩溃的堆栈跟踪、寄存器、内存分配和其他有用的信息。使用适当的工具和符号,可以对Minidump文件进行分析,以找出造成崩溃的代码行。我们可以通过Visual Studio调试器或使用ProcDump命令行实用程序手动生成minidump文件。同时,我们也可以通过对Minidump文件进行分析,了解应用程序或系统崩溃的原因,这对于软件开发和维护至关重要。 如果你喜欢我们三七知识分享网站的文章, 欢迎您分享或收藏知识分享网站文章 欢迎您到我们的网站逛逛喔!https://www.37seo.cn/

点赞(56) 打赏

评论列表 共有 0 条评论

暂无评论
立即
投稿
发表
评论
返回
顶部