|
|
|
date: Tue, 24 Jun 2008 02:12:39 -0700 (PDT),
group: microsoft.public.vsnet.debugging
back
Re: MiniDumpWriteDump generates empty dumps
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" 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" wrote in message
>
> news:13a071ba-2f2b-4e6f-b488-c51a7be1b441@e39g2000hsf.googlegroups.com...
>
>
>
> > 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.
date: Thu, 10 Jul 2008 07:29:51 -0700 (PDT)
author: Dennis Mikhailitsky
Re: MiniDumpWriteDump generates empty dumps
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
"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" 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" wrote in message
> >
> > news:13a071ba-2f2b-4e6f-b488-c51a7be1b441@e39g2000hsf.googlegroups.com...
> >
> >
> >
> > > 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.
>
>
date: Thu, 31 Jul 2008 03:40:23 -0700
author: Bishnu
Re: MiniDumpWriteDump generates empty dumps
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]
Marc Sherman wrote:
> "Jochen Kalmbach [MVP]" wrote in message
> news:%23f3Ysiz8IHA.4108@TK2MSFTNGP04.phx.gbl...
>> 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
>
>
>
date: Mon, 04 Aug 2008 08:53:33 -0700
author: pat styles [microsoft]
Re: MiniDumpWriteDump generates empty dumps
I experience this problem in a native application.
Denis
On 31 ìÉÐ, 13:40, Bishnu wrote:
> 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
>
>
>
> "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" 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" wrote in message
>
> > >news:13a071ba-2f2b-4e6f-b488-c51a7be1b441@e39g2000hsf.googlegroups.com> > > > 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.
date: Wed, 20 Aug 2008 11:03:15 -0700 (PDT)
author: Dennis Mikhailitsky
|
|
