MiniDumpWriteDump generates empty dumps
Dennis Mikhailitsky
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
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
"Dennis Mikhailitsky" <mikhai...@gmail.com> wrote in message
news:13a071ba-2f2b-4e6f...@e39g2000hsf.googlegroups.com...
Dennis Mikhailitsky
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.
On 25 Чер, 00:00, "Marc Sherman" <masherman1...@yahoo.com> wrote:
> 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
>
> "Dennis Mikhailitsky" <mikhailit...@gmail.com> wrote in message
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.
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
"Dennis Mikhailitsky" wrote:
> 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.
>
> On 25 Чер, 00:00, "Marc Sherman" <masherman1...@yahoo.com> wrote:
> > 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..
Jochen Kalmbach [MVP]
> 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
news:O%23OGkcy8...@TK2MSFTNGP04.phx.gbl...
> Hi 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]
> 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...
Marc Sherman
> Hi Marc!
>
>> 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.
>
> 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`.
> 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>
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.
>
> 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]
>> 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 ;)
pat styles [microsoft]
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]
Marc Sherman
news:489725FD...@microsoft.com...
> 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]
>
> Marc Sherman wrote:
>> 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]
> 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
I experience this problem in a native application.
Denis
Brycej
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" <mikhai...@gmail.com> wrote in message
news:9c7d2531-26ed-495b...@y38g2000hsy.googlegroups.com...