.mdmp files not being created

Hello, Under what conditions is the .mdmp file created or not I have written an app that (deliberately) dereferences a NULL pointer, but the generated error report does not have the "Files that help describe the problem" section when listing the report from the Control Panel "Problem Reports and Solutions". Viewing other reports that had been put there, some of them have the files and some don't.

DrWtsn32 on WinXP does create a minidump when my program crashes, and I would like the same behavior to occur on Vista. How can I configure WER to create a minidump in this instance

Thanks,

David (MVP, Visual C++)

David,

on Vista, minidumps are transmitted only upon explicit demand from the server, at least that is how I understand it. Jason Hardester's post at http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=1426737&SiteID=1 explains some of the rationale behind the server's decisions.

You can force the system to always generate minidumps by enabling queuing mode: Set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ForceQueue (DWORD) to 1. Crash report data are stored in c:\Users\someusername\AppData\Local\temp and C:\ProgramData\Microsoft\Windows\WER\ReportQueue.

Hope this helps,

Claus

http://www.clausbrod.de/Blog

Claus, thank you so much. I set the ForceQueue and now the minidump is saved! I really appreciate it. I had seen doc of the ForceQueue but did not think it had anything to do with whether minidumps were created.

Cheers,

David

http://www.dcsoft.com

OK, while setting ForceQueue to 1 does happily generate the minidump, now the user sees no UI of this happening. Before, a dialog said

<Program> has stopped working

...

[Debug] [Close Program]

Is there a way to both generate the minidump AND have the dialog

Thanks,

David

I used ForceQueue for debugging purposes only, and the fact that the dialogs didn't appear was acceptable in that scenario.

If you register and map your app with the Winqual servers, then the servers will at least occasionally request minidump information from your app, and then you'll be able to download the minidumps from Winqual.

Another option is to shut off the Internet connection when the crash occurs. The dialogs will then be displayed, but when WER finds out it cannot send stuff to the servers, it will archive the crash data (including minidumps) so that they can be re-sent at some later point in time.

A variation of this idea is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\CorporateWERServer to the name of some machine in your network. When a crash occurs, WER will assume that a "Corporate Error Reporting" server is running on that box, and will try to talk to port 1273. If there's no answer, then WER will probably create the minidump and keep it around for later.

Of course, you could also set up a real Corporate Error Reporting server which always requests the minidump information from the client. I haven't tried this myself yet, though.

Claus

http://www.clausbrod.de/Blog

Hi Claus,

Yes, well, it would be much nicer to have the dialog when ForceQueue=1, because otherwise the user won't even know a crash has occurred until the program is noticed missing! If the program has no UI, that is hard indeed. I appreciate your words on the workarounds, but only the Corporate server seems like the real deal. (I can't imagine asking the user to unplug the Internet!). That tidbit really came in handy on explaining what to do to get minidumps to work on Vista.

Best,

David

Oh, I see. My assumption was that you only need a setup for development purposes, not necessarily for end users.

If you register and map your app at Winqual, then the Winqual servers will request minidump information basically whenever a "new" type of crash occurs, i.e. a type of crash which the servers don't know about yet. At least that's how I understand the theory behind it, and if it works in practice as well, it means you as a developer will be able to get all required crash information from the Winqual servers.

If you don't want to go through Microsoft, and the code in question is for an in-house application for which you have some control over its deployment, CER/AEM becomes a viable option, i.e. install an error reporting server within in the company.

But maybe Saar or Jason have some additional ideas about configuration or registry options which help to accomplish what you want

Claus

http://www.clausbrod.de/Blog

It seems MS means for us to use Winqual servers or the corporate error reporting servers as the only means of getting the minidumps to the developers, and for some of my clients, these suit the bill just fine. But for smaller shops, they do just fine sneaker-netting the minidump from QA to the developer, and it seems this sneaker-net idea is not as good with the new Windows Error Reporting way of doing things.

I was tasked to author a tutorial on minidumps, and to be honest, I'm not sure if my audience will prefer the traditional Dr. Watson way, or the new WER way. But it would have been nice if the Dr. Watson way had been totally preserved within WER, for the people who prefer to do it that way.

Thanks again for all your good info.

-- David

Just a wild idea which I'm sure Jason may not like so much (and I understand why) :

• Call SetUnhandledExceptionFilter to register your own top-level exception filter code.
• In that exception filter, call MiniDumpWriteDump to create a minidump file of your own describing the crash.
• Return from the filter with EXCEPTION_CONTINUE_SEARCH.

Check out http://www.clausbrod.de/Blog/DefinePrivatePublic20070627 for some demo code!

Cheers,

Claus

The registry value name is "ForceQueue", not "ReportQueue". See http://msdn2.microsoft.com/en-us/library/aa363489.aspx for Microsoft's documentation on WER-related registry settings. (Those registry keys, by the way, are completely independent from the MiniDumpWriteDump() demo code I posted.)

Hope this helps,

Claus

Claus, thanks. This is a valid option, but the whole point of Dr. Watson and WER is so we don't have to alter our code at all to get minidumps! I'm sure MS didn't mean to screw up WER so bad that it forces developers to write their own minidumps!

Cheers,

David

Hi Jason,

Thank you very much for taking the time to write this thorough response! I very much appreciate it. The tutorial I am creating covers crash dumps on XP and Vista, and the target audience is for ISV developers. In all of the small-medium sized ISV shops (e.g. 5-10 developers) I have worked with, not one of them has set up servers to handle crash dumps. If the QA dept found a crash, then they would attach the minidump file to the bug report, and the developer would take it from there. In XP, simply setting up DrWtsn32 to specify the folder where the dump file would be placed is all that is necessary. This works really well. So I wish that WER still made this easy.

I hear you about how we're supposed to use Winqual, and to be honest, I have not used it, so it may be easier than I think. It's unclear to me whether Winqual is meant to be used for pre-release software I think I read it requires a Verisign signing cert. Why is that My signing cert is not from Verisign, it's from Comodo because it's way cheaper. In any event, registering for Winqual seems overkill when internal QA depts are more than capable of managing their own minidumps the sneaker-net way.

It seems a half-hearted attempt was made to preserve that way with the ForceQueue reg key; however, since it disables the dialog that notifies of a crash, it's not very usable. Could you fix it so that it doesn't disable the dialog

Also, does CER == Dr. Watson; because AFAIK, Dr. Watson does not use "cabs"

If I could give you some feedback, it's that the message of how to use WER is not exactly crystal clear; it seems Microsoft as a company seems to have given up on even trying to get a crystal clear message about how to use their new technologies, instead relying on grassroots efforts like this forum, blogs, etc. I'm thrilled those exist, and doubly thrilled for your and Claus' presence and heroic effort, but really, shouldn't the official doc writers be capable of explaining these things

Best,

David