2023年12月15日发(作者:)

健壮应用程序异常信息收集,捕捉UnhandledException,并生成dump文件

最近负责的一个项目的应用系统老是原因不明的结束。因为该应用程序是Windows

service的缘故,调试起来很麻烦,再加上问题一直找不到重现的办法。而当问题发生后,日志内并没有任何记录,同时该应用的进程也已经结束,在系统事件日志和里面也没有发现什么有用的信息。考虑到重现问题需要很多的信息支持,另外程序确实需要在发生异常时自身收集更多的信息,所以为程序加入未捕捉异常的处理,该处理中包含了通过代码生成Dump文件。

大致的做法是,加入一个ledException事件,以在发现未捕捉异常时触发;然后就通过windbg的API函数:MiniDumpWriteDump生成dump文件,以便分析问题。

以下处理未捕捉异常的ledException事件的示例代码:

//在程序初始阶段,将处理函数加入到ledException事件中,以便发现未捕捉异常时触发。

//该语句放到程序初始化的函数中即可

ledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

//这是处理函数,与初始化函数同在一个class内

void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)

{

Exception ex = ionObject as Exception;

//这两个是自定义的日志记录函数,

// ("Unhandled Exception occur in Method:" + ng());

// (ng());

//生成dump文件

p(@"D:", llMemory);

}

这样定义完成后,程序中所有没有被atch捕获的Exception都将触发事件ledException。事件处理完成后,异常将继续向上抛,程序会因为该未捕捉异常而终止,同时Windows的事件日志会记录该异常,然后触发系统默认的调试引擎。因此,响应ledException事件并不代表你的应用不会因为未捕捉异常而终止,ledException事件仅仅是让你在遇到该情况下能自动收集更多的信息而已。

下面我们讲讲如何生成dump文件。通过代码生成dump文件,需要使用windbg的(该dll可以在windbg的安装目录中找到)中的API函数:MiniDumpWriteDump(更详细的用法可以MSDN)。原理不多说了,无非就是import dll然后就是调用而已。具体代码如下:

using System;

using c;

using ;

using pServices;

using stics;

using ;

using ing;

namespace DumpCreator

{

/**/

///

/// 该类要使用在windows 5.1 以后的版本,如果你的windows很旧,就把Windbg里面的dll拷贝过来,一般都没有问题

/// 是windows自带的 dll文件 。

///

public static class MiniDump

{

/**/

/*

* 导入

*/

[DllImport("")]

private static extern Boolean MiniDumpWriteDump(

IntPtr hProcess,

Int32 processId,

IntPtr fileHandle,

MiniDumpType dumpType,

ref MinidumpExceptionInfo excepInfo,

IntPtr userInfo,

IntPtr extInfo);

/**/

/*

* MINIDUMP_EXCEPTION_INFORMATION 这个宏的信息

*/

struct MinidumpExceptionInfo

{

public UInt32 ThreadId;

public IntPtr ExceptionPointers;

public UInt32 ClientPointers;

}

[DllImport("")]

private static extern uint GetCurrentThreadId();

/**/

/*

* 自己包装的一个函数

*/

public static Boolean TryDump(String dmpPath, MiniDumpType dmpType)

{

//使用文件流来创健 .dmp文件

using (FileStream stream = new FileStream(dmpPath, ))

{

//取得进程信息

Process process = rentProcess();

// MINIDUMP_EXCEPTION_INFORMATION 信息的初始化

MinidumpExceptionInfo mei = new MinidumpExceptionInfo();

Id=(UInt32)GetCurrentThreadId();

ionPointers=eptionPointers();

Pointers=1;

//这里调用的Win32 API

Boolean res = MiniDumpWriteDump(

,

,

ousGetHandle(),

dmpType,

ref mei,

,

);

//清空 stream

();

();

return res;

}

}

public enum MiniDumpType

{

None = 0x00010000,

Normal = 0x00000000,

WithDataSegs = 0x00000001,

WithFullMemory = 0x00000002,

WithHandleData = 0x00000004,

FilterMemory = 0x00000008,

ScanMemory = 0x00000010,

WithUnloadedModules = 0x00000020,

WithIndirectlyReferencedMemory = 0x00000040,

FilterModulePaths = 0x00000080,

WithProcessThreadData = 0x00000100,

WithPrivateReadWriteMemory = 0x00000200,

WithoutOptionalData = 0x00000400,

WithFullMemoryInfo = 0x00000800,

WithThreadInfo = 0x00001000,

WithCodeSegs = 0x00002000

}

}

}

该代码是我从《如何让程序抓到dump文件,MiniDumpWriteDump windbg扩展》看到的,后作了一些修改。调整部分在主要是增加了GetCurrentThreadId()这个系统的API函数来获取当前线程的系统ThreadID。使用原文的代码生成的dump文件,使用windbg加载后,会提示找不到当前线程。该问题估计是因为作者误将托管线程ID作为系统线程ID传递给MiniDumpWriteDump导致。

完成这两个步骤,就可以处理那些让人头痛的未捕捉异常问题了。但是这个方法只能处理托管环境下的未捕捉异常,如果是托管环境下,发生的非托管异常,似乎不能捕捉。

另外提醒一下的就是,在windbg分析dump时,异常线程的堆栈最顶的函数是UnhandledException事件函数......