Re: Analysing a minidump cause by a release build

Pete,
Since you got a .dmp file generated from the .dump /ma command, you have a complete picture of the process at the time of the dump creation. You indicate that you see only one call stack. How well-experienced are you with using WinDbg? If it's new to you, then perhaps you are unaware of some of the commands that will let you survey the stacks of other threads. I suspect this is a multi-threaded app, and maybe you're only looking at one of the call stacks?

The command "~" (just the tilde on a line by itself) will display a summary of all the running threads at the time of the dump.
Using "~ns" (where n is the number of a thread, and s is really the letter s) will change the context to that thread.
The "k" commands (there are numerous variations, like kb, kp, kbn, kpn, etc.) will display the call stack in a variety of ways.

Let me know if i'm barking up the wrong tree here, or if you need more guidance in using WinDbg. There's a pretty good help file that comes with it that details all of this.

Peter wrote:
Hi Martin,

Thanks for the pointer which led to interesting reading. I don't think the iterator bug I built into my code causes a stack overflow or my unhandled exception filter.

Errors like incrementing/decrementing stl iterators beyond their boundaries is clearly something I would love to be able to trap. After all, VS 2005 Express can trap the error I built into my code example correctly and show me the exact location of the problem so there clearly is a way to handle this case.

Interesting is that if I remove the line:

SetErrorMode(SEM_NOGPFAULTERRORBOX);


from my code sample, and then run the app I get the WER dialog. I can also see that the WER process wrote a minidump to my Local Settings\Temp folder, but access to it is denied (I can't even copy it). If I click "Debug..." the minidump disappears. On my machine the WER dialog is owned by a process DWWIN which doesn't even show in task manager.

So I thought I'd use WinDbg as my JIT debugger like this:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug

Debugger="C:\Program Files\Debugging Tools for Windows\windbg.exe" -p %ld -e %ld -g -c '.dump /o /ma c:\TEMP\new.dmp; q' -Q -QS -QY -QSY
Auto=1

I then executed my test program again and this time Windbg kicked in instead of WER and wrote the c:\temp\new.dmp file. However, the content of it was really rather useless as the only stack trace I got was:

ntdll!DbgBreakPoint+0x1
ntdll!DbgUiRemoteBreakIn+0x2d

Looking at the modules tells me that all symbols for all modulules are present in the form of PDB's, so not a lack of symbol fault.

It is this minidump I'm interested in. I don't want it sent to Microsoft, I want it myself and I don't want the user to be prompted for it either.

Also, I have tried using a __try/__except SEH handler where the minidump is produced by the __except, but this has not changed the result.

Pete

"Martin T." <0xCDCDCDCD@xxxxxx> wrote in message news:h49emh$32h$1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Peter wrote:
In the meantime I've gone through heaps of literature on the subject on the net. While I learned heaps, I'm still struggling to get this beast under control.

I guess from our perspective, the most interesting way of creating minidumps is by calling the DbgHelp API MiniDumpWriteDump inside the application. The problem is, it doesn't always fire.

Attached is a small application that uses it. In the main app you can see
I see no attachment? Maybe you'll better inline the code?

two statements which both cause a fatal errors: one error is reported by the Visual Studio debugger as a "Fatal C Runtime Library Error" and the other as a "C++ Access Violation Exception".

The test application only produces a minidump for the second error.

Sure, this is already better than nothing, but is there a way to trap all unhandled errors?

In my experience, there are some errors that are never handled. Example being certain cases of stack overflows, where the process that encounters the problem apparently is terminated immediately by the OS without anything being executed at all.

Maybe see an old thread here:
http://groups.google.com/group/microsoft.public.vc.debugger/browse_frm/thread/fe7f63ba857ee66f/4f0bea4eb7e612f7

br,
Martin
.

Relevant Pages

  • Re: Analysing a minidump cause by a release build
    ... Since you got a .dmp file generated from the .dump /ma command, you have a complete picture of the process at the time of the dump creation. ... You indicate that you see only one call stack. ... I can also see that the WER process wrote a minidump to my Local Settings\Temp folder, but access to it is denied. ...
    (microsoft.public.vc.debugger)
  • Re: StackOverflowException coming from within the CLR?
    ... What is the exception code in those SEHExceptions (you can use!do ... !DumpStack is a raw stack dump similar to 'dds esp' so it shows a lot ... > Is there any way to work around this so I can create the minidump? ...
    (microsoft.public.dotnet.framework.clr)
  • Re: WINDBG:Memory access error
    ... most of the times the minidump does not contain enough ... If you can reproduce the issue, switch to kernel memory dump. ... value assigned to all parameters of Driver Entry routine in the stack. ...
    (microsoft.public.development.device.drivers)
  • Re: The Promise of Forth
    ... After awhile I ... found a chart of the Z80 command set and I wrote a disassembler, ... stack operator. ... Then I got my own PC and I tried out Pygmy Forth. ...
    (comp.lang.forth)
  • TIP #211: Add Full Stack Trace Capability
    ... ADD FULL STACK TRACE CAPABILITY ... This TIP proposes adding a new subcommand to the *info* command, ... flag to the *level* subcommand, to get a list of all the current stack ... % proc bob { ...
    (comp.lang.tcl)
Loading