DonDu's Blog https://docs.microsoft.com/archive/blogs/dondu/feed.xml Musings on Software Development Wed, 17 Apr 2019 03:39:43 GMT en-US hourly 1 Writing Minidumps from Exceptions in C# https://docs.microsoft.com/archive/blogs/dondu/writing-minidumps-from-exceptions-in-c Sun, 31 Oct 2010 17:05:00 GMT https://blogs.msdn.microsoft.com/dondu/2010/10/31/writing-minidumps-from-exceptions-in-c/  

This is part of a related series of posts:

Minidumps are about debugging, and when you write in C# the vast majority of times that you need to debug, it will be because of some exception that was thrown.  So let’s see what is involved in capturing information about Exceptions in a minidump.

First a simple test method that creates a vaguely interesting callstack and throws an exception…

   1: public static void CreateStackWithException(int level = 1)
   2: {
   3:     bool cleanedUp = false;
   4:     try
   5:     {
   6:         if (level == 6)
   7:             throw new Exception();
   8:         CreateStackWithException(level + 1);
   9:     }
  10:     finally
  11:     {
  12:         cleanedUp = true;
  13:     }
  14: }

The CreateStackWithException method calls itself recursively until the level is 6, at which point is throws an Exception object.  (The coding guidelines say that you shouldn’t throw plain Exception objects but of course this is just for exploring behavior so it doesn’t matter in this case.)  The method also has a finally block which cleans up some (very simple) state, to illustrate how that interacts with exception handling and  minidumps.

Now a simple method to invoke CreateStackWithException and catch the exception and write a minidump.

   1: static void CatchTest()
   2: {
   3:     try
   4:     {
   5:         CreateStackWithException();
   6:     }
   7:     catch (Exception ex)
   8:     {
   9:         string stackTrace = ex.StackTrace;
  10:         string fileName = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "MiniDumpDemo_Catch.mdmp");
  11:         using (FileStream fs = new FileStream(fileName, FileMode.Create, FileAccess.ReadWrite, FileShare.Write))
  12:         {
  13:             MiniDump.Write(fs.SafeFileHandle, MiniDump.Option.WithFullMemory, MiniDump.ExceptionInfo.Present);
  14:         }
  15:     }
  16: }

The CatchTest method calls CreateStackWithException.  It catches the exception, grabs a local copy of the Exception.StackTrace property (you’ll see why in a bit), and then writes a minidump to a file called MiniDumpDemo_Catch.mdmp in your My Documents folder.

Once we execute that and load the minidump into Visual Studio 2010 and Debug with Mixed, we see this popup…

ExceptionDialog

We get that pop-up because we included exception pointers in the minidump.

Except…  I am running Windows 7 x64, and when I run this test as a 64-bit process, I get the exception pop-up.  But when I run it as a 32-bit process I don’t get the pop-up.  I investigated, and the call to System.Runtime.InteropServices.Marshal.GetExceptionPointers() returns null in the catch block, when running as a 32-bit process.  The low-level mechanisms for raising exceptions are very different between 32-bit and 64-bit processes, so that is probably the cause.

Let’s look at the callstack as displayed in the debugger.

   1: ntdll.dll!NtGetContextThread()  + 0xa bytes    
   2: ntdll.dll!string "Dereferencing"()     
   3: [Managed to Native Transition]    
   4: MiniDumpDemo.exe!MiniDump.Write(System.Runtime.InteropServices.SafeHandle fileHandle = {Microsoft.Win32.SafeHandles.SafeFileHandle}, MiniDump.Option options = WithFullMemory, MiniDump.ExceptionInfo exceptionInfo = Present) Line 98 + 0x40 bytes    C#
   5: MiniDumpDemo.exe!MiniDumpDemo.Program.CatchTest() Line 63 + 0x2e bytes    C#
   6: MiniDumpDemo.exe!MiniDumpDemo.Program.Main(string[] args = {string[0]}) Line 80 + 0x5 bytes    C#
   7: [Native to Managed Transition]    
   8: mscoreei.dll!_CorExeMain()  + 0x49 bytes    
   9: mscoree.dll!_CorExeMain_Exported()  + 0x69 bytes    
  10: kernel32.dll!BaseThreadInitThunk()  + 0xd bytes    
  11: ntdll.dll!RtlUserThreadStart()  + 0x21 bytes

That’s not actually a very good result:  The exception happened within several levels of recursion inside the CreateStackWithException method, but that method doesn’t appear on the callstack captured in the debugger at all.  All of that context has been lost, making it much harder for us to use the minidump to determine the cause of the exception.

But at least we have the actual Exception object in the minidump, and we can inspect that.  We’ll just use the minidump to view the Exception.StackTrace property…

   1: -        $exception    {"Exception of type 'System.Exception' was thrown."}    System.Exception
   2: -        StackTrace    '$exception.StackTrace' threw an exception of type 'System.NotSupportedException'    string {System.NotSupportedException}
   3: +        base    {"Exception stack trace information is not available while minidump debugging."}    System.SystemException {System.NotSupportedException}

Whoa!  It’s a conspiracy!  The Exception.StackTrace property doesn’t work inside of minidumps, and there is an explicit error message generated.

And that’s why we snapped a copy of the Exception.StackTrace property before we wrote the minidump.  We can use the Call Stack window to change the context to the CatchTest method on the stack, and then we can inspect the local strackTrace variable in that call frame.

   1: at MiniDumpDemo.Program.CreateStackWithException(Int32 level) in MiniDumpDemo\Program.cs:line 20
   2: at MiniDumpDemo.Program.CreateStackWithException(Int32 level) in MiniDumpDemo\Program.cs:line 20
   3: at MiniDumpDemo.Program.CreateStackWithException(Int32 level) in MiniDumpDemo\Program.cs:line 20
   4: at MiniDumpDemo.Program.CreateStackWithException(Int32 level) in MiniDumpDemo\Program.cs:line 20
   5: at MiniDumpDemo.Program.CreateStackWithException(Int32 level) in MiniDumpDemo\Program.cs:line 20
   6: at MiniDumpDemo.Program.CreateStackWithException(Int32 level) in MiniDumpDemo\Program.cs:line 20
   7: at MiniDumpDemo.Program.CatchTest() in MiniDumpDemo\Program.cs:line 55

That’s much better.  I’ve personally had many many instances where I’ve been given only a callstack like that and the bug is usually painfully obvious.  Occasionally it takes a few minutes of thought and reading the code to figure out the bug.  Just having the text of the callstack is useful so much of the time that the server software we develop just writes the callstack to a log file and we inspect the log file later.

But it’s not actually ideal.  Ideal would be to have the full context of the location of the exception in the minidump.  The reason that we don’t have that is we are writing the minidump from within a catch handler, and the way exceptions work, the stack has been unwound and all of the finally blocks have run before the catch handler starts running.  (I’m not going to attempt to describe it in any detail here.  Here’s a post that provides some information:  https://blogs.msdn.com/b/clrteam/archive/2009/02/05/catch-rethrow-and-filters-why-you-should-care.aspx)

One solution would be to write the minidump from inside of CreateStackWithException just before the exception is thrown.  However that would require that you push a lot of the policy related to minidumps (the filename of the minidump, whether to write the minidump or not) down into code that is less likely to have information about those policies.  You could solve those problems with dependency injection https://en.wikipedia.org/wiki/Dependency_Injection but what if the location where the exception is being thrown is in a module that you can’t rebuild?

This post has grown fairly long, so I am going to close.  But first here is a taste of a solution…

   1: static void FilterTest()
   2: {
   3:     try
   4:     {
   5:         ExceptionFilter.Invoke(
   6:             () => {
   7:                 CreateStackWithException();
   8:             },
   9:             (ex) => {
  10:                 string stackTrace = ex.StackTrace;
  11:                 string fileName = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "MiniDumpDemo_Filter.mdmp");
  12:                 using (FileStream fs = new FileStream(fileName, FileMode.Create, FileAccess.ReadWrite, FileShare.Write))
  13:                 {
  14:                     MiniDump.Write(fs.SafeFileHandle, MiniDump.Option.WithFullMemory, MiniDump.ExceptionInfo.Present);
  15:                 }
  16:             });
  17:     }
  18:     catch (Exception)
  19:     {
  20:         /* ignore */
  21:     }
  22: }
   1: ntdll.dll!NtGetContextThread()  + 0xa bytes    
   2: [Managed to Native Transition]    
   3: MiniDumpDemo.exe!MiniDump.Write(System.Runtime.InteropServices.SafeHandle fileHandle = {Microsoft.Win32.SafeHandles.SafeFileHandle}, MiniDump.Option options = WithFullMemory, MiniDump.ExceptionInfo exceptionInfo = Present) Line 98 + 0x40 bytes    C#
   4: MiniDumpDemo.exe!MiniDumpDemo.Program.FilterTest.AnonymousMethod__1(System.Exception ex = {"Exception of type 'System.Exception' was thrown."}) Line 41 + 0x2e bytes    C#
   5: ExceptionFilter.dll!ExceptionFilter.Invoke(System.Action body = {Method = Could not evaluate expression}, System.Action<System.Exception> filter = {Method = Could not evaluate expression}) Line 89    Unknown
   6: [Native to Managed Transition]    
   7: ntdll.dll!RtlpExecuteHandlerForException()  + 0xd bytes    
   8: ntdll.dll!RtlDispatchException()  + 0x38c bytes    
   9: ntdll.dll!KiUserExceptionDispatcher()  + 0x2e bytes    
  10: KERNELBASE.dll!RaiseException()  + 0x3d bytes    
  11: [Managed to Native Transition]    
  12: MiniDumpDemo.exe!MiniDumpDemo.Program.CreateStackWithException(int level = 6) Line 20    C#
  13: MiniDumpDemo.exe!MiniDumpDemo.Program.CreateStackWithException(int level = 5) Line 20 + 0xa bytes    C#
  14: MiniDumpDemo.exe!MiniDumpDemo.Program.CreateStackWithException(int level = 4) Line 20 + 0xa bytes    C#
  15: MiniDumpDemo.exe!MiniDumpDemo.Program.CreateStackWithException(int level = 3) Line 20 + 0xa bytes    C#
  16: MiniDumpDemo.exe!MiniDumpDemo.Program.CreateStackWithException(int level = 2) Line 20 + 0xa bytes    C#
  17: MiniDumpDemo.exe!MiniDumpDemo.Program.CreateStackWithException(int level = 1) Line 20 + 0xa bytes    C#
  18: MiniDumpDemo.exe!MiniDumpDemo.Program.FilterTest.AnonymousMethod__0() Line 34 + 0xa bytes    C#
  19: ExceptionFilter.dll!ExceptionFilter.Invoke(System.Action body = {Method = Could not evaluate expression}, System.Action<System.Exception> filter = {Method = Could not evaluate expression}) Line 74    Unknown
  20: MiniDumpDemo.exe!MiniDumpDemo.Program.FilterTest() Line 32 + 0xe9 bytes    C#
  21: MiniDumpDemo.exe!MiniDumpDemo.Program.Main(string[] args = {string[0]}) Line 79 + 0x5 bytes    C#
  22: [Native to Managed Transition]    
  23: mscoreei.dll!_CorExeMain()  + 0x49 bytes    
  24: mscoree.dll!_CorExeMain_Exported()  + 0x69 bytes    
  25: kernel32.dll!BaseThreadInitThunk()  + 0xd bytes    
  26: ntdll.dll!RtlUserThreadStart()  + 0x21 bytes

Using an exception filter, you can write the minidump before the stack is unwound.  That gives you the full callstack from the point where the exception is thrown, without any finally blocks having run, so you have the full context in the minidump.

The ExceptionFilter.Invoke method is code I wrote in IL.  The C# language doesn’t provide support for writing exception filters, so you have to resort to one of several mechanisms to author the code.  In my next post, I will cover in detail my ExceptionFilter.Invoke method.

]]> Writing Minidumps in C# https://docs.microsoft.com/archive/blogs/dondu/writing-minidumps-in-c Sun, 24 Oct 2010 18:48:00 GMT https://blogs.msdn.microsoft.com/dondu/2010/10/24/writing-minidumps-in-c/ This is part of a related series of posts:

the first in what I intend to be a group of related posts, about exceptions and error handling in C#.

Minidumps are a mechanism for "post-mortem debugging" - debugging your application after it is "dead".  A minidump is a snapshot of the memory of your application, typically taken when it is has encountered a fatal error.  Various debuggers support loading minidumps and "debugging" with them, which really means just exploring them, since you can't do things like single-step or change the value of variables when the program isn't running any longer.  The .Net Framework 4.0 and Visual Studio 2010 finally bring easy minidump debugging to C# code.

In Windows, a minidump is created through the MiniDumpWriteDump API https://msdn.microsoft.com/en-us/library/ms680360(VS.85).aspx.  Since that is a native API, we need some interop code in order to write minidumps from C#.  Jochen Kalmbach has done the hard work in his short but excellent post https://blog.kalmbach-software.de/2008/12/13/writing-minidumps-in-c/.  I've taken his example and only made some minor changes, resulting in this...

 

using System;

using System.Diagnostics;

using System.Runtime.InteropServices;





public static class MiniDump

{

    // Taken almost verbatim from https://blog.kalmbach-software.de/2008/12/13/writing-minidumps-in-c/

    [Flags]

    public enum Option : uint

    {

        // From dbghelp.h:

        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,

        WithoutAuxiliaryState = 0x00004000,

        WithFullAuxiliaryState = 0x00008000,

        WithPrivateWriteCopyMemory = 0x00010000,

        IgnoreInaccessibleMemory = 0x00020000,

        ValidTypeFlags = 0x0003ffff,

    };



    public enum ExceptionInfo

    {

        None,

        Present

    }



    //typedef struct _MINIDUMP_EXCEPTION_INFORMATION {

    //    DWORD ThreadId;

    //    PEXCEPTION_POINTERS ExceptionPointers;

    //    BOOL ClientPointers;

    //} MINIDUMP_EXCEPTION_INFORMATION, *PMINIDUMP_EXCEPTION_INFORMATION;

    [StructLayout(LayoutKind.Sequential, Pack = 4)]  // Pack=4 is important! So it works also for x64!

    public struct MiniDumpExceptionInformation

    {

        public uint ThreadId;

        public IntPtr ExceptionPointers;

        [MarshalAs(UnmanagedType.Bool)]

        public bool ClientPointers;

    }



    //BOOL

    //WINAPI

    //MiniDumpWriteDump(

    //    __in HANDLE hProcess,

    //    __in DWORD ProcessId,

    //    __in HANDLE hFile,

    //    __in MINIDUMP_TYPE DumpType,

    //    __in_opt PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,

    //    __in_opt PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,

    //    __in_opt PMINIDUMP_CALLBACK_INFORMATION CallbackParam

    //    );



    // Overload requiring MiniDumpExceptionInformation

    [DllImport("dbghelp.dll", EntryPoint = "MiniDumpWriteDump", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Unicode, ExactSpelling = true, SetLastError = true)]

    static extern bool MiniDumpWriteDump(IntPtr hProcess, uint processId, SafeHandle hFile, uint dumpType, ref MiniDumpExceptionInformation expParam, IntPtr userStreamParam, IntPtr callbackParam);



    // Overload supporting MiniDumpExceptionInformation == NULL

    [DllImport("dbghelp.dll", EntryPoint = "MiniDumpWriteDump", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Unicode, ExactSpelling = true, SetLastError = true)]

    static extern bool MiniDumpWriteDump(IntPtr hProcess, uint processId, SafeHandle hFile, uint dumpType, IntPtr expParam, IntPtr userStreamParam, IntPtr callbackParam);



    [DllImport("kernel32.dll", EntryPoint = "GetCurrentThreadId", ExactSpelling = true)]

    static extern uint GetCurrentThreadId();



    public static bool Write(SafeHandle fileHandle, Option options, ExceptionInfo exceptionInfo)

    {

        Process currentProcess = Process.GetCurrentProcess();

        IntPtr currentProcessHandle = currentProcess.Handle;

        uint currentProcessId = (uint)currentProcess.Id;

        MiniDumpExceptionInformation exp;

        exp.ThreadId = GetCurrentThreadId();

        exp.ClientPointers = false;

        exp.ExceptionPointers = IntPtr.Zero;

        if (exceptionInfo == ExceptionInfo.Present)

        {

            exp.ExceptionPointers = System.Runtime.InteropServices.Marshal.GetExceptionPointers();

        }

        bool bRet = false;

        if (exp.ExceptionPointers == IntPtr.Zero)

        {

            bRet = MiniDumpWriteDump(currentProcessHandle, currentProcessId, fileHandle, (uint)options, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero);

        }

        else

        {

            bRet = MiniDumpWriteDump(currentProcessHandle, currentProcessId, fileHandle, (uint)options, ref exp, IntPtr.Zero, IntPtr.Zero);

        }

        return bRet;

    }



    public static bool Write(SafeHandle fileHandle, Option dumpType)

    {

        return Write(fileHandle, dumpType, ExceptionInfo.None);

    }

}

 

 

The most significant change I made was to add an override for the MiniDumpWriteDump interop declaration, that supports passing NULL (aka IntPtr.Zero) for the expParam parameter.  The reason isn't applicable to this particular blog post since we aren't (yet) attempting to store "exception information" in the minidump, but what I found was that on my Windows 7 x64 machine, under particular circumstances the test program running as x86 under WOW64, the Marshall.GetExceptionPointers method would return IntPtr.Zero, while running the test program as x64 the method would return a well-formed exception pointer.  And when the ExceptionPointers field of expParam was IntPtr.Zero, the MiniDumpWriteDump call would have an Access Violation, the solution to which was to pass expParam as IntPtr.Zero.  So the two overloads of MiniDumpWriteDump support either a non-existent expParam (passed as IntPtr.Zero), or a well-formed expParam passed as a ref MiniDumpExceptionInformation with the ExceptionPointers field set to the return value from Marshall.GetExceptionPointers).

Of course we need an example of how to make the call to create a minidump...

        static void MainlineTest()

        {

            string fileName = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments), "MiniDumpDemo_Mainline.mdmp");

            using (FileStream fs = new FileStream(fileName, FileMode.Create, FileAccess.ReadWrite, FileShare.Write))

            {

                MiniDump.Write(fs.SafeFileHandle, MiniDump.Option.WithFullMemory);

            }

        }

The result is a file called minidump_mainline.dmp in your My Documents folder.  If you open that file in Visual Studio 2010, you'll get a page that displays information about the minidump.  On the right is a link to Debug With Mixed, which will start the debugger against the minidump.  At that point you can explore the call stack and inspect variables and fields.  The callstack will show execution as being in the middle of the call MiniDump.Write...

 	ntdll.dll!NtGetContextThread()  + 0xa bytes	

 	ntdll.dll!string "Dereferencing"() 	

 	[Managed to Native Transition]	

>	MiniDumpDemo.exe!MiniDump.Write(System.Runtime.InteropServices.SafeHandle fileHandle = {Microsoft.Win32.SafeHandles.SafeFileHandle}, MiniDump.Option options = WithFullMemory, MiniDump.ExceptionInfo exceptionInfo = None) Line 94 + 0x42 bytes	C#

 	MiniDumpDemo.exe!MiniDump.Write(System.Runtime.InteropServices.SafeHandle fileHandle = {Microsoft.Win32.SafeHandles.SafeFileHandle}, MiniDump.Option dumpType = WithFullMemory) Line 105 + 0x11 bytes	C#

 	MiniDumpDemo.exe!MiniDumpDemo.Program.MainlineTest() Line 73 + 0x28 bytes	C#

 	MiniDumpDemo.exe!MiniDumpDemo.Program.Main(string[] args = {string[0]}) Line 81 + 0x5 bytes	C#

 	[Native to Managed Transition]	

 	mscoreei.dll!_CorExeMain()  + 0x49 bytes	

 	mscoree.dll!_CorExeMain_Exported()  + 0x69 bytes	

 	kernel32.dll!BaseThreadInitThunk()  + 0xd bytes	

 	ntdll.dll!RtlUserThreadStart()  + 0x21 bytes

In the next post, writing minidumps from inside exception handlers to capture as much information as possible about why the application is failing.

 

]]>