David Ching


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++)




Re: .mdmp files not being created

Claus Brod


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






Re: .mdmp files not being created

David Ching

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






Re: .mdmp files not being created

David Ching

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





Re: .mdmp files not being created

Claus Brod

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





Re: .mdmp files not being created

David Ching

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





Re: .mdmp files not being created

Claus Brod

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





Re: .mdmp files not being created

David Ching

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





Re: .mdmp files not being created

Claus Brod

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





Re: .mdmp files not being created

netcrazy

HI Claus,
I tried setting the reg key "ReportQueue" but still my application did not create a minidump file on vista. Am i missing any project settings ...




Re: .mdmp files not being created

Claus Brod

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





Re: .mdmp files not being created

David Ching

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





Re: .mdmp files not being created

Jason Hardester - MSFT

Hi David,

What Operating Systems are you creating minidump tutorials for The behavior is different in Windows Vista than it is in older operating systems.

Let me address various ways to get minidumps on the local machines for 'sneaker-net' and then direct you to what we had envisioned.

Sneaker-net

If you map your files on winqual, we will put the server into collection mode for your file's crashes. This is interesting to you for the sneaker-net approach since minidumps are only stored locally in Windows Vista if the servers were collecting data at the time of the report. (...also, I believe the minidump will be available if the computer is offline)

Sneaker-net approach for older operating systems is easy... set up CER policies to report crash information to a local folder or shared folder, and have the 'Cabs' folder sent to you via whatever transport = sneaker-net. You don't need to change your code, but you do need to be aware of expected client side behavior to be successful in the sneaker-net approach. For example, CER is not supported in Windows Vista. Instead, AEM is the method to use (the protocol is different). AEM requires Operations Manager 2007, so there is overhead for an IT shop if they are not already leveraging this technology whereas CER was overly simple. On Windows Vista, there is another solution (target's end-users) called Problem Reports and Solutions ...or wercon.exe. If the back-end services were collecting data for the crash, the same data is available through wercon.exe.

What Microsoft had envisioned

For Developers - We had envisioned developers and ISVs to use Winqual to access crash information by mapping their products/files. In this way, it did not matter where the report came from; Winqual would prioritize failures based on volume and growth of the reports over 90 days and enable developers and ISVs to create responses that would be displayed tot eh users if they encountered the crash again with information that could prevent the crash (update available, workaround, and so on). Error Reporting for Applications happens by default without any needed application code unless the application is handling their own exceptions (...and as Claus mentioned, I don't encourage anyone to implement their own exception handler).

For IT-PROs - We had also envisioned the need for IT-Professionals (System/Network administrators of companies) to manage what should be allowed to leave the corporate wire in regards to error reporting. To achieve this management in the past, we offered Corporate Error Reporting. This was a set of client policies and a tool that redirected error reports from within the IT shop to a common location where the Admin could use the tool to configure common reporting behavior and broker the data to Microsoft for the types of data the Admin allowed. (See CER). This solution was not scalable for large IT-PRO shops as the tool used local memory to load the crash data in the common folder and apply the reporting rules. The larger the share size and # of unique reports the longer it would take to load and report. For Windows Vista, it was decided to change the reporting protocol to use http/https and interact with Operations Manager 2007 using AEM (Agentless Event Management).

For End Users - Finally, we had envisioned that it would be useful for an end-user top see (historically) what Error Reporting events happened on their computer. To enable this, we created wercon.exe. Through this tool, users can not only see what happened in the past, but they can check for solutions (responses) without having to wait for the crash to happen again. The tool does keep crash data around in a queue so to prevent unneeded utilization of disk space Microsoft decided to only store crash data (minidumps) for crashes that the Microsoft reporting servers were collecting for.

Did we screw it up I hope not. Let us know if we did so we work on fixing it..

Kind regards,

-Jason






Re: .mdmp files not being created

David Ching

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





Re: .mdmp files not being created

JPSA

> Did we screw it up I hope not. Let us know if we did so we work on fixing it.

We do map our products and files with winqual, and this provides very useful information, but there are a couple of circumstances where this is insufficient:

a) When a customer needs immediate support, or needs to provide us with extra information (e.g. sample data) along with the problem report

b) When the minidump does not enough information, and we need a full dump including the heap to diagnose the fault

In the past we have asked users in this situation to use Dr Watson to collect a full crash dump, and get it to us via CD-R or ftp or something. What should we ask customers using Vista to do

Thanks for any advice!