Discussion:
MiniDumpWriteDump generates empty dumps
(too old to reply)
Dennis Mikhailitsky
2008-06-24 09:12:39 UTC
Permalink
Hello,

I keep experiencing this problem when MiniDumpWriteDump generates
empty crash dumps. I have a program that calls this function in
exception handlers. On 1 machine all crash dumps are generated
perfectly well, while on another machine in 99% cases crash dumps
generated end up being empty (not a single byte is written to the dump
file). The very same program is being used in both cases. The OS is
Win 2003 Server, SP2. Any suggestions would be highly appreciated.

Thanks in advance.
Marc Sherman
2008-06-24 21:00:40 UTC
Permalink
Are you using the same version of dbghelp.dll in both cases?

Also, many recommend doing the minimum in your exception handler and having
another "healthy" process call MiniDumpWriteDump on the crashing process.
Your crashing process may be so corrupt that it can't write the dump file.
The most you would want to do in your exception handler is set an event that
would cause the other process to generate the dump file.

Marc
Post by Dennis Mikhailitsky
Hello,
I keep experiencing this problem when MiniDumpWriteDump generates
empty crash dumps. I have a program that calls this function in
exception handlers. On 1 machine all crash dumps are generated
perfectly well, while on another machine in 99% cases crash dumps
generated end up being empty (not a single byte is written to the dump
file). The very same program is being used in both cases. The OS is
Win 2003 Server, SP2. Any suggestions would be highly appreciated.
Thanks in advance.
Dennis Mikhailitsky
2008-07-10 14:29:51 UTC
Permalink
On the machine where dumps are generated fine, I have multiple
dbghelp.dll files. The one from windows\system32 is 5.2.3790.1830. On
the machine where empty dumps are created, the version is
5.2.3790.3959. Usually the crashes are caused by the wrong pointer
access, so I believe it should not be too destructive for the
application, yet often times crash dumps are empty.
Post by Marc Sherman
Are you using the same version of dbghelp.dll in both cases?
Also, many recommend doing the minimum in your exception handler and having
another "healthy" process call MiniDumpWriteDump on the crashing process.
Your crashing process may be so corrupt that it can't write the dump file.
The most you would want to do in your exception handler is set an event that
would cause the other process to generate the dump file.
Marc
Post by Dennis Mikhailitsky
Hello,
I keep experiencing this problem when MiniDumpWriteDump generates
empty crash dumps. I have a program that calls this function in
exception handlers. On 1 machine all crash dumps are generated
perfectly well, while on another machine in 99% cases crash dumps
generated end up being empty (not a single byte is written to the dump
file). The very same program is being used in both cases. The OS is
Win 2003 Server, SP2. Any suggestions would be highly appreciated.
Thanks in advance.
Bishnu
2008-07-31 10:40:23 UTC
Permalink
I have similar problem :

I am creating a crash dump file for divide by zero exception in C#.
When I write a sample console application to generate it, it creates the
dump file successfully, but when i tried to use the same code in different
application in the same machine, then it creates a dumpfile of zero bytes.

Sample code for your reference :

using System;
using System.Reflection;
using System.Runtime.Remoting;
using System.Runtime.InteropServices;
using System.IO;
using System.Threading;
using System.Globalization;


public class CallMyHelloWorld
{


public static void Main()
{
AppDomain.CurrentDomain.UnhandledException +=
new
UnhandledExceptionEventHandler(CurrentDomainUnhandledException);

int i = 0;
int j = 10 / i;
}

public static class MINIDUMPTYPE
{
public const int MiniDumpNormal = 0x00000000;
public const int MiniDumpWithDataSegs = 0x00000001;
public const int MiniDumpWithFullMemory = 0x00000002;
public const int MiniDumpWithHandleData = 0x00000004;
public const int MiniDumpFilterMemory = 0x00000008;
public const int MiniDumpScanMemory = 0x00000010;
public const int MiniDumpWithUnloadedModules = 0x00000020;
public const int MiniDumpWithIndirectlyReferencedMemory = 0x00000040;
public const int MiniDumpFilterModulePaths = 0x00000080;
public const int MiniDumpWithProcessThreadData = 0x00000100;
public const int MiniDumpWithPrivateReadWriteMemory = 0x00000200;
public const int MiniDumpWithoutOptionalData = 0x00000400;
public const int MiniDumpWithFullMemoryInfo = 0x00000800;
public const int MiniDumpWithThreadInfo = 0x00001000;
public const int MiniDumpWithCodeSegs = 0x00002000;
}




[DllImport("dbghelp.dll")]
public static extern bool MiniDumpWriteDump(
IntPtr hProcess, Int32 ProcessId, IntPtr hFile, int DumpType,
IntPtr ExceptionParam, IntPtr UserStreamParam, IntPtr CallackParam);

private static void CurrentDomainUnhandledException(
object sender, UnhandledExceptionEventArgs e)
{
CreateMiniDump();
}

private static void CreateMiniDump()
{

DateTime endTime = DateTime.Now;
string dt = endTime.ToString("yyyy.MM.dd.HH.mm.ss",
DateTimeFormatInfo.InvariantInfo);

string dumpFileName = "C:\\HelloWorldDump" + dt +".dmp";
FileStream fs = new FileStream(dumpFileName, FileMode.Create);
System.Diagnostics.Process process =
System.Diagnostics.Process.GetCurrentProcess();

MiniDumpWriteDump(
process.Handle, process.Id,
fs.SafeFileHandle.DangerousGetHandle(),
MINIDUMPTYPE.MiniDumpWithFullMemory, IntPtr.Zero, IntPtr.Zero,
IntPtr.Zero);

}
}

Can anyone help me, what might be the problem, what might be the reason for
the same code running correctly in one application and failing when run
integrated in different application (I mean it creates empty crash dump file)
?

Please help.

Thanking you in advance
Post by Dennis Mikhailitsky
On the machine where dumps are generated fine, I have multiple
dbghelp.dll files. The one from windows\system32 is 5.2.3790.1830. On
the machine where empty dumps are created, the version is
5.2.3790.3959. Usually the crashes are caused by the wrong pointer
access, so I believe it should not be too destructive for the
application, yet often times crash dumps are empty.
Post by Marc Sherman
Are you using the same version of dbghelp.dll in both cases?
Also, many recommend doing the minimum in your exception handler and having
another "healthy" process call MiniDumpWriteDump on the crashing process.
Your crashing process may be so corrupt that it can't write the dump file..
The most you would want to do in your exception handler is set an event that
would cause the other process to generate the dump file.
Marc
Post by Dennis Mikhailitsky
Hello,
I keep experiencing this problem when MiniDumpWriteDump generates
empty crash dumps. I have a program that calls this function in
exception handlers. On 1 machine all crash dumps are generated
perfectly well, while on another machine in 99% cases crash dumps
generated end up being empty (not a single byte is written to the dump
file). The very same program is being used in both cases. The OS is
Win 2003 Server, SP2. Any suggestions would be highly appreciated.
Thanks in advance.
Jochen Kalmbach [MVP]
2008-07-31 16:04:38 UTC
Permalink
Hi Bishnu!
Post by Bishnu
I am creating a crash dump file for divide by zero exception in C#.
What do you do with "managed minidumps"? There is no (supported) way to
use it...
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Marc Sherman
2008-07-31 18:00:44 UTC
Permalink
Post by Jochen Kalmbach [MVP]
Hi Bishnu!
Post by Bishnu
I am creating a crash dump file for divide by zero exception in C#.
What do you do with "managed minidumps"? There is no (supported) way to
use it...
Are you saying that the sos extension is not supported?

Marc
Jochen Kalmbach [MVP]
2008-07-31 18:10:09 UTC
Permalink
Hi Marc!
Post by Marc Sherman
Are you saying that the sos extension is not supported?
No.

Have you ever debugged a minidump (or full-dump) with managed code with
WinDbg???
Have you ever debugged a "normal" managed app with WinDbg?

You never get source lines; you can only "guess" what happend...


Please remember the thread "why my code breaks?" a couple of weeks ago...

Here again is the comment from pat styles:
<quote>
WinDbg was never designed to be a managed code debugger. It predates
the existence of managed code and has not yet been updated to support
it. There are no papers published on this topic, nor do I expect there
to be any.

..pat styles [microsoft]
</quote>

Only WinDbg 6.7.5.0 "accidently" supported managed code... and was very
fast removed from the download page...
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Marc Sherman
2008-07-31 20:47:42 UTC
Permalink
Post by Jochen Kalmbach [MVP]
Hi Marc!
Post by Marc Sherman
Are you saying that the sos extension is not supported?
No.
Have you ever debugged a minidump (or full-dump) with managed code with
WinDbg???
Have you ever debugged a "normal" managed app with WinDbg?
I've done live debugging of managed apps with WinDbg. It's not as easy as an
unmanaged app but it's somewhat doable.
Post by Jochen Kalmbach [MVP]
You never get source lines; you can only "guess" what happend...
In live debugging you can debug at the assembly level of the JITed IL code.
So you get much better than guessing. Aside from version 6.7.5.0, you can
still get a good idea of the stack with a combo of `kb` and `!clrstack`. And
you can look at CLR objects with `!do` given an address. There's the ability
to set breakpoints with `!bpmd` even though it cumbersome to specify the
assembly and method. And in JITed code you can always use good old `bu`.
Post by Jochen Kalmbach [MVP]
Please remember the thread "why my code breaks?" a couple of weeks ago...
<quote>
WinDbg was never designed to be a managed code debugger. It predates the
existence of managed code and has not yet been updated to support it.
There are no papers published on this topic, nor do I expect there to be
any.
..pat styles [microsoft]
</quote>
I know Pat always says that but I'd argue you can do some managed code
debugging with Winbdg and sos together (becuase I've done it). I think he
wants people to realize that his group is in no way responsible for sos and
that if you want support for it, you need to go elsewhere. It's also
probably annoying when people think all the built in debugger commands
should work with managed code because sos has wetted their appetite.
Post by Jochen Kalmbach [MVP]
Only WinDbg 6.7.5.0 "accidently" supported managed code... and was very
fast removed from the download page...
I wonder what the office Holiday party is like when the Windbg group and the
sos group are in the same room? Tense?

Marc
Jochen Kalmbach [MVP]
2008-08-01 13:51:42 UTC
Permalink
Hi Marc!
Post by Jochen Kalmbach [MVP]
Only WinDbg 6.7.5.0 "accidently" supported managed code... and was very
fast removed from the download page...
By the way: The download is still available ;)
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
pat styles [microsoft]
2008-08-04 15:53:33 UTC
Permalink
Since people seem to be quoting me, I would like to quote myself with
the most relevant statements that I made in the "why my code breaks?"
thread.
The Windows debugger team would love to roll out support for managed
applications in WinDbg and is moving in that direction as fast as they
technically and legally can do so, while still maintaining the quality
and stability of the product.
The next release of WinDbg will contain limited support for managed
applications. That release is due out before the end of the year.
In case I didn't make it clear enough, I said that you're getting what
you asked for. This is something that the windbg team has wanted to do
for a long time and just now have the opportunity to provide this
functionality.

It think it is best not to speculate on the reasons for the past
incompatibilities. I say that because no one ever publicly speculated
anything that approximated what the real underlying issues are. I
would love to share with you, but I can't. But let's just clarify one
thing. There is no internal animosity between the debugger team, the
.Net team, and the Visual Studio team. In fact, some of us are personal
friends.

.pat styles [microsoft]
Post by Jochen Kalmbach [MVP]
Hi Marc!
Post by Marc Sherman
Are you saying that the sos extension is not supported?
No.
Have you ever debugged a minidump (or full-dump) with managed code with
WinDbg???
Have you ever debugged a "normal" managed app with WinDbg?
I've done live debugging of managed apps with WinDbg. It's not as easy as an
unmanaged app but it's somewhat doable.
Post by Jochen Kalmbach [MVP]
You never get source lines; you can only "guess" what happend...
In live debugging you can debug at the assembly level of the JITed IL code.
So you get much better than guessing. Aside from version 6.7.5.0, you can
still get a good idea of the stack with a combo of `kb` and `!clrstack`. And
you can look at CLR objects with `!do` given an address. There's the ability
to set breakpoints with `!bpmd` even though it cumbersome to specify the
assembly and method. And in JITed code you can always use good old `bu`.
Post by Jochen Kalmbach [MVP]
Please remember the thread "why my code breaks?" a couple of weeks ago...
<quote>
WinDbg was never designed to be a managed code debugger. It predates the
existence of managed code and has not yet been updated to support it.
There are no papers published on this topic, nor do I expect there to be
any.
..pat styles [microsoft]
</quote>
I know Pat always says that but I'd argue you can do some managed code
debugging with Winbdg and sos together (becuase I've done it). I think he
wants people to realize that his group is in no way responsible for sos and
that if you want support for it, you need to go elsewhere. It's also
probably annoying when people think all the built in debugger commands
should work with managed code because sos has wetted their appetite.
Post by Jochen Kalmbach [MVP]
Only WinDbg 6.7.5.0 "accidently" supported managed code... and was very
fast removed from the download page...
I wonder what the office Holiday party is like when the Windbg group and the
sos group are in the same room? Tense?
Marc
Marc Sherman
2008-08-04 18:19:32 UTC
Permalink
But let's just clarify one thing. There is no internal animosity between
the debugger team, the .Net team, and the Visual Studio team. In fact,
some of us are personal friends.
.pat styles [microsoft]
Post by Marc Sherman
I wonder what the office Holiday party is like when the Windbg group and
the sos group are in the same room? Tense?
I was trying to be funny but this ended up just sounding stupid. I'm sorry
for saying it.

Marc
Jochen Kalmbach [MVP]
2008-08-05 12:32:45 UTC
Permalink
Hi pat!
Post by pat styles [microsoft]
In case I didn't make it clear enough, I said that you're getting what
you asked for. This is something that the windbg team has wanted to do
for a long time and just now have the opportunity to provide this
functionality.
It think it is best not to speculate on the reasons for the past
incompatibilities. I say that because no one ever publicly speculated
anything that approximated what the real underlying issues are. I would
love to share with you, but I can't. But let's just clarify one thing.
There is no internal animosity between the debugger team, the ..Net
team, and the Visual Studio team. In fact, some of us are personal
friends.
Sorry if I was too bothered about this really nice and (now) missing
feature....
I really look forward to see this new version! Wouldn't it be possible
to release a "beta" version?

Sorry for my bothering you... I will stop it and wait and see... ;)

Greetings
Jochen
Dennis Mikhailitsky
2008-08-20 18:03:15 UTC
Permalink
I experience this problem in a native application.

Denis
Post by Bishnu
I am creating a crash dump file for divide by zero exception in C#.
When I write a sample console application to generate it, it creates the
dump file successfully, but when i tried to use the same code in different
application in the same machine, then it creates a dumpfile of zero bytes.
using System;
using System.Reflection;
using System.Runtime.Remoting;
using System.Runtime.InteropServices;
using System.IO;
using System.Threading;
using System.Globalization;
public class CallMyHelloWorld
{
    public static void Main()
    {
        AppDomain.CurrentDomain.UnhandledException +=
                    new
UnhandledExceptionEventHandler(CurrentDomainUnhandledException);
        int i = 0;
        int j = 10 / i;
    }
    public static class MINIDUMPTYPE
    {
        public const int MiniDumpNormal = 0x00000000;
        public const int MiniDumpWithDataSegs = 0x00000001;
        public const int MiniDumpWithFullMemory = 0x00000002;
        public const int MiniDumpWithHandleData = 0x00000004;
        public const int MiniDumpFilterMemory = 0x00000008;
        public const int MiniDumpScanMemory = 0x00000010;
        public const int MiniDumpWithUnloadedModules = 0x00000020;
        public const int MiniDumpWithIndirectlyReferencedMemory = 0x00000040;
        public const int MiniDumpFilterModulePaths = 0x00000080;
        public const int MiniDumpWithProcessThreadData = 0x00000100;
        public const int MiniDumpWithPrivateReadWriteMemory = 0x00000200;
        public const int MiniDumpWithoutOptionalData = 0x00000400;
        public const int MiniDumpWithFullMemoryInfo = 0x00000800;
        public const int MiniDumpWithThreadInfo = 0x00001000;
        public const int MiniDumpWithCodeSegs = 0x00002000;
    }
    [DllImport("dbghelp.dll")]
    public static extern bool MiniDumpWriteDump(
        IntPtr hProcess, Int32 ProcessId, IntPtr hFile, int DumpType,
        IntPtr ExceptionParam, IntPtr UserStreamParam, IntPtr CallackParam);
    private static void CurrentDomainUnhandledException(
        object sender, UnhandledExceptionEventArgs e)
    {
        CreateMiniDump();
    }
    private static void CreateMiniDump()
    {
        DateTime endTime = DateTime.Now;
        string dt = endTime.ToString("yyyy.MM.dd.HH.mm.ss",
DateTimeFormatInfo.InvariantInfo);
        string dumpFileName = "C:\\HelloWorldDump" + dt +".dmp";
        FileStream fs = new FileStream(dumpFileName, FileMode.Create);
        System.Diagnostics.Process process =
System.Diagnostics.Process.GetCurrentProcess();
        MiniDumpWriteDump(
            process.Handle, process.Id,
fs.SafeFileHandle.DangerousGetHandle(),
            MINIDUMPTYPE.MiniDumpWithFullMemory, IntPtr.Zero, IntPtr.Zero,
IntPtr.Zero);
    }
}
Can anyone help me, what might be the problem, what might be the reason for
the same code running correctly in one application and failing when run
integrated in different application (I mean it creates empty crash dump file)
?
Please help.
Thanking you in advance
Post by Dennis Mikhailitsky
On the machine where dumps are generated fine, I have multiple
dbghelp.dll files. The one from windows\system32 is 5.2.3790.1830. On
the machine where empty dumps are created, the version is
5.2.3790.3959. Usually the crashes are caused by the wrong pointer
access, so I believe it should not be too destructive for the
application, yet often times crash dumps are empty.
Post by Marc Sherman
Are you using the same version of dbghelp.dll in both cases?
Also, many recommend doing the minimum in your exception handler and having
another "healthy" process call MiniDumpWriteDump on the crashing process.
Your crashing process may be so corrupt that it can't write the dump file..
The most you would want to do in your exception handler is set an event that
would cause the other process to generate the dump file.
Marc
Post by Dennis Mikhailitsky
Hello,
I keep experiencing this problem when MiniDumpWriteDump generates
empty crash dumps. I have a program that calls this function in
exception handlers. On 1 machine all crash dumps are generated
perfectly well, while on another machine in 99% cases crash dumps
generated end up being empty (not a single byte is written to the dump
file). The very same program is being used in both cases. The OS is
Win 2003 Server, SP2. Any suggestions would be highly appreciated.
Thanks in advance.
Brycej
2008-11-14 07:27:12 UTC
Permalink
What is the error supplied by MiniDumpWriteDump:
http://msdn.microsoft.com/en-us/library/ms680360.aspx

I noted below that the return wasn't being contested... I'll assume this was
left off for brevity.

-Brycej

"Dennis Mikhailitsky" <***@gmail.com> wrote in message news:9c7d2531-26ed-495b-b80d-***@y38g2000hsy.googlegroups.com...

I experience this problem in a native application.

Denis
Post by Bishnu
I am creating a crash dump file for divide by zero exception in C#.
When I write a sample console application to generate it, it creates the
dump file successfully, but when i tried to use the same code in different
application in the same machine, then it creates a dumpfile of zero bytes.
using System;
using System.Reflection;
using System.Runtime.Remoting;
using System.Runtime.InteropServices;
using System.IO;
using System.Threading;
using System.Globalization;
public class CallMyHelloWorld
{
public static void Main()
{
AppDomain.CurrentDomain.UnhandledException +=
new
UnhandledExceptionEventHandler(CurrentDomainUnhandledException);
int i = 0;
int j = 10 / i;
}
public static class MINIDUMPTYPE
{
public const int MiniDumpNormal = 0x00000000;
public const int MiniDumpWithDataSegs = 0x00000001;
public const int MiniDumpWithFullMemory = 0x00000002;
public const int MiniDumpWithHandleData = 0x00000004;
public const int MiniDumpFilterMemory = 0x00000008;
public const int MiniDumpScanMemory = 0x00000010;
public const int MiniDumpWithUnloadedModules = 0x00000020;
public const int MiniDumpWithIndirectlyReferencedMemory = 0x00000040;
public const int MiniDumpFilterModulePaths = 0x00000080;
public const int MiniDumpWithProcessThreadData = 0x00000100;
public const int MiniDumpWithPrivateReadWriteMemory = 0x00000200;
public const int MiniDumpWithoutOptionalData = 0x00000400;
public const int MiniDumpWithFullMemoryInfo = 0x00000800;
public const int MiniDumpWithThreadInfo = 0x00001000;
public const int MiniDumpWithCodeSegs = 0x00002000;
}
[DllImport("dbghelp.dll")]
public static extern bool MiniDumpWriteDump(
IntPtr hProcess, Int32 ProcessId, IntPtr hFile, int DumpType,
IntPtr ExceptionParam, IntPtr UserStreamParam, IntPtr CallackParam);
private static void CurrentDomainUnhandledException(
object sender, UnhandledExceptionEventArgs e)
{
CreateMiniDump();
}
private static void CreateMiniDump()
{
DateTime endTime = DateTime.Now;
string dt = endTime.ToString("yyyy.MM.dd.HH.mm.ss",
DateTimeFormatInfo.InvariantInfo);
string dumpFileName = "C:\\HelloWorldDump" + dt +".dmp";
FileStream fs = new FileStream(dumpFileName, FileMode.Create);
System.Diagnostics.Process process =
System.Diagnostics.Process.GetCurrentProcess();
MiniDumpWriteDump(
process.Handle, process.Id,
fs.SafeFileHandle.DangerousGetHandle(),
MINIDUMPTYPE.MiniDumpWithFullMemory, IntPtr.Zero, IntPtr.Zero,
IntPtr.Zero);
}
}
Can anyone help me, what might be the problem, what might be the reason for
the same code running correctly in one application and failing when run
integrated in different application (I mean it creates empty crash dump file)
?
Please help.
Thanking you in advance
Post by Dennis Mikhailitsky
On the machine where dumps are generated fine, I have multiple
dbghelp.dll files. The one from windows\system32 is 5.2.3790.1830. On
the machine where empty dumps are created, the version is
5.2.3790.3959. Usually the crashes are caused by the wrong pointer
access, so I believe it should not be too destructive for the
application, yet often times crash dumps are empty.
Post by Marc Sherman
Are you using the same version of dbghelp.dll in both cases?
Also, many recommend doing the minimum in your exception handler and having
another "healthy" process call MiniDumpWriteDump on the crashing process.
Your crashing process may be so corrupt that it can't write the dump file..
The most you would want to do in your exception handler is set an event that
would cause the other process to generate the dump file.
Marc
Post by Dennis Mikhailitsky
Hello,
I keep experiencing this problem when MiniDumpWriteDump generates
empty crash dumps. I have a program that calls this function in
exception handlers. On 1 machine all crash dumps are generated
perfectly well, while on another machine in 99% cases crash dumps
generated end up being empty (not a single byte is written to the dump
file). The very same program is being used in both cases. The OS is
Win 2003 Server, SP2. Any suggestions would be highly appreciated.
Thanks in advance.
Loading...