How to get an excel.dmp file after an Excel crash under XP ?
forfun
I am developping an Excel DLL which will be delivered on many client
computers.
Client computers will have no debugging tool and that is why I need a
core file to be able to analyse what happened if Excel crash because
of my DLL.
When Excel crash on my developper's computer, it ask me if I want to
send the debug report to Microsoft and then if I want to debug. If I
say "yes" to the debug question, XP open the debugger and everything
is fine.
But how can I get a kind of "excel.dmp" file that the user will be
able to send to me ?
Thanks in advance for your help.
Pavel Lebedinsky
When invoked, it creates a crash dump then kills the process.
So when your users get the same dialog and choose "Debug",
drwtsn32 will run and produce a dump (if you run drwtsn32
with no parameters it will tell you where the dump will be placed).
Users can then send this dump to you.
forfun
@TK2MSFTNGP15.phx.gbl:
> The default "debugger" for unhandled exceptions is drwtsn32.exe.
> When invoked, it creates a crash dump then kills the process.
>
> So when your users get the same dialog and choose "Debug",
> drwtsn32 will run and produce a dump (if you run drwtsn32
> with no parameters it will tell you where the dump will be placed).
> Users can then send this dump to you.
I am afraid it does not work for me.
Here is all what I did :
1/ I managed to make my Excel application crash in my custom DLL.
2/ Excel crashes as I wanted and displays the "Send report to Microsoft"
window. Then, I click on the "Debug" button.
3/ If I run "drwtsn32" with no parameters, it tells me that the minidump
file is called "user.dmp" and is located there :
"C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson
\user.dmp"
... but if go there, I can not find any "user.dmp" file.
4/ I verifed that I was allowed to read/write in the dump directory and it
is OK.
5/ I did a "*.dmp" file search on all my C: disk drive but all the dump
files I can find are the one located in the Windows minidump directory but
these ones are only generated when the system crashes.
Did I miss something ?
Is there something more to do to get the user dump working properly ?
Thanks in advance if you can help me.
McBacker
"forfun" <my.e...@nomail.com> wrote in message news:Xns95D8D4C339A2E...@212.27.42.79...
forfun
news:ezBLt6b...@TK2MSFTNGP11.phx.gbl:
> Type drwtsn32 -i in the run window... this will make Dr Watson the
> default debug app...
Thanks for the trick but I already tried this and it did not work better
(no dump file generated in the Dr Watson dump dir)
Moreover, when Excel display the "send report" window, I lost the "Debug"
button and I did not find anyway to restore it (perhaps I have to restore
the default debugger ?)
Do I need specific rights for debugging under XP (even if I already have
read/write rigths on the dump dir) ?
Pavel Lebedinsky
debugger, the Debug button disappears from the error reporting
dialog (which makes sense since drwtsn32 is not really a debugger).
For regular applications like notepad, when you click "Don't send"
drwtsn32 still runs in the background and creates the dump.
Office however seems to provide its own implementation of error
reporting which is separate from the one provided by Windows.
When it detects that the JIT debugger is drwtsn32 it not only
removes the Debug button, it doesn't run drwtsn32 at all.
I think this was done for security reasons. Office documents
often contain sensitive data so it's probably not a good idea
to create crash dumps by default, especially in a location that
is readable by everyone.
You can try using a different JIT debugger. For example, on XP
and later the built-in ntsd.exe can create crash dumps. Or you can
copy and rename drwtsn32 to something like mydrwtsn.exe
and use that (you'll need to edit the Debugger registry value
under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug).
I would only do that if the user is experiencing problems though.
That is, you probably shouldn't change the default configuration
since it affects the entire machine.
Or you could create the crash dump yourself. If you have only a
few entry points into your DLL you can use __try/__except
around each one and create the dump from the SEH filter function,
using MiniDumpWriteDump.
Another option is to install your own unhandled exception filter
with SetUnhandledExceptionFilter and create the dump from there
(but this again should be disabled by default because it affects the
entire process. At the very least you should provide an option
to invoke the original handler because the user might want to
use normal error reporting for some crashes).
forfun
> Looks like you're right. When drwtsn32 is registered as the JIT
> debugger, the Debug button disappears from the error reporting
> dialog (which makes sense since drwtsn32 is not really a debugger).
Even when drwtsn32 is not registered as the default JIT, I can not see any
Dr Watson running :
+ I ran the "filemon" tool (developped by Sysinternals) which reports
all the I/O accesses,
+ I ran Excel with my DLL,
+ When Excel crashed, I could see that the process "mdm" then "vs7jit"
were started and finally, the user selected debugger (but no Dr
Watson)
With Filemon, I also noticed that no "dmp" file was generated during the
whole process.
Consequently, as you say, it seems that in any case, MS Office does not use
the standard debug process when an MS Office application crahes.
PS: Do you know how to restore the Debug button in the report window ?
> You can try using a different JIT debugger. For example, on XP
> and later the built-in ntsd.exe can create crash dumps. Or you can
> copy and rename drwtsn32 to something like mydrwtsn.exe
> and use that (you'll need to edit the Debugger registry value
> under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug).
Since setting Dr Watson as the default debugger did not change, I do not
think that changing the default debugger will solve the problem.
It seems that MS Office have its own way of managing crash exceptions and
they do not use the debug registry values.
> Or you could create the crash dump yourself. If you have only a
> few entry points into your DLL you can use __try/__except
> around each one and create the dump from the SEH filter function,
> using MiniDumpWriteDump.
That an issue but it involves that I add a lot of code to my DLL to manage
the dump generation.
Since the system offers some tools for doing this, I would like the system
to do it for me ! (like Unix with core files)
> Another option is to install your own unhandled exception filter
> with SetUnhandledExceptionFilter and create the dump from there
> (but this again should be disabled by default because it affects the
> entire process. At the very least you should provide an option
> to invoke the original handler because the user might want to
> use normal error reporting for some crashes).
I did not know that issue so I am going to try it. It seems that it does
not require to add as much code as in your previous issue.
Thanks for all those tricks !
Pavel Lebedinsky
> PS: Do you know how to restore the Debug button in the
> report window ?
As I've said - on my system the Debug button disappears
when the JIT debugger in registry is set to drwtsn32 and
comes back when it's changed to anything else (including
a renamed copy of drwtsn32.exe).
Oleg Starodumov
> PS: Do you know how to restore the Debug button in the report window ?
>
Try to set the following Registry entry:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AeDebug\"Auto" = 0
> > Or you could create the crash dump yourself. If you have only a
> > few entry points into your DLL you can use __try/__except
> > around each one and create the dump from the SEH filter function,
> > using MiniDumpWriteDump.
>
I would recommend this approach (__try/__except around the entry points),
because it does not depend on the configuration of the customer's system.
Configuration of the JIT debugger can change from system to system,
so in general you cannot be sure that it is available.
> That an issue but it involves that I add a lot of code to my DLL to manage
> the dump generation.
> Since the system offers some tools for doing this, I would like the system
> to do it for me ! (like Unix with core files)
>
Another alternative is to rely on the default error reporting and obtain
the crash reports from Microsoft:
http://winqual.microsoft.com/
Regards,
Oleg