ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Windows Error Reporting for ISVs

Claus Brod


Hi all,

I'm experimenting with the available APIs for error reporting. On XP systems, I'm using ReportFault(), which seems to work as expected- it displays the WER dialogs, sends data to the Winqual site (including minidump data), launches a debugger when asked for by the user etc. Is this the right place to ask questions about those APIs If not, please ignore the following. (But if you know where I should ask instead, please drop me a note, thanks!)

On Vista, ReportFault()'s behavior changed, unfortunately. With the default error reporting settings (automatic reporting without asking the user), it sends the crash report to the Winqual site - and then terminates the application. However, in my particular case, I need to re-gain control after WER reporting in my application in order to perform additional logging and clean-up, and to provide users with an option to continue working for a limited time (for example, to try and save their current data).

Since ReportFault() didn't do what I wanted, I tried the WerReportCreate/WerReportSubmit combo instead. Those APIs do indeed return and don't terminate the application - but they also don't seem to report all the crash details correctly. For example, I've never seen any indication that one of the crash reports produced by the WerReport* APIs contained minidump information (judging from the problem report history in wercon.exe).

My first guess is that I'm simply not using the WerReport* APIs correctly - but after trying lots of different options and variations, I'm pretty much at a loss. Hence my questions:

- Where can I find tested sample code which uses WerReportCreate/WerReportSubmit()

- Is there a way to use ReportFault() under Vista without terminating the application


Thanks!

Claus Brod

Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Jason Hardester - MSFT


Hi Claus,

We can help you here with your WERAPI questions. Off hand, I think you would be interested in the restart and recovery APIs in addition to the WER Data Collection APIs. I envision that the new rich WERAPIs in Windows Vista will enable you to do everything you need. I'll talk to the Developer Lead of the APIs to see if there are any samples or guidance available and one of us will get back to you.

In the meanwhile, you can explore these APIs at http://msdn2.microsoft.com/en-us/library/ms681656.aspx (Core WERAPIs) and http://msdn2.microsoft.com/en-us/library/aa373342.aspx (Application Restart and Recovery APIs).

Kind Regards,

-Jason






Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

Jason,

thanks a lot for your help!

I haven't looked into the details of the recovery/restart APIs yet, but I was told that they impose an upper time limit for saving the state of the application. Is that true If so, that might be an issue for us, as our customers often work with data consuming several GB in memory, and saving those data can take an almost arbitrary amount of time.

Anyway, the immediate problem I'm trying to solve is to use the WER API to inform the user about the crash, create a crash report, attach minidump data, and send the whole package off to the Winqual site. The core of our WER code looks approximately like this:

Code Snippet

// Set up parameters for WerReportCreate()
WER_REPORT_INFORMATION werReportInfo;
memset(&werReportInfo, 0, sizeof(werReportInfo));
werReportInfo.dwSize = sizeof(werReportInfo);

wcscpy_s(werReportInfo.wzFriendlyEventName,
_countof(werReportInfo.wzFriendlyEventName), L"Friendly event name");
wcscpy_s(werReportInfo.wzDescription,
_countof(werReportInfo.wzDescription), L"Critical runtime problem");
werReportInfo.hwndParent = AfxGetMainWnd()->m_hWnd;

PCWSTR eventType = L"MyApp";
HREPORT hReportHandle;
if (SUCCEEDED(pWerReportCreate(eventType, WerReportCritical,
&werReportInfo, &hReportHandle)) && hReportHandle) {
WER_EXCEPTION_INFORMATION werExceptionInformation;
werExceptionInformation.bClientPointers = FALSE;
werExceptionInformation.pExceptionPointers = inExceptionPointer;
bool dumpAdded = SUCCEEDED(pWerReportAddDump(hReportHandle, ::GetCurrentProcess(),
::GetCurrentThread(), WerDumpTypeMiniDump, &werExceptionInformation, NULL, 0));

WER_SUBMIT_RESULT submitResult;
DWORD submitOptions = WER_SUBMIT_ADD_REGISTERED_DATA | WER_SUBMIT_OUTOFPROCESS;
if (SUCCEEDED(pWerReportSubmit(hReportHandle, WerConsentNotAsked,
submitOptions, &submitResult))) {
// handle submitResult
// ...
}
}



All the return values are OK and as expected, and yet, according to wercon.exe, the minidump information is always missing in the crash report - and so far, none of our crash reports (which were triggered from Vista systems) even made it the Winqual site.

It's probably an obvious and simple mistake on my part, which I'm just not seeing after staring at this code for several days now 8-)

Thanks!

Claus

http://www.clausbrod.de/Blog



Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

John Brown

Claus Brod wrote:
Hi all,

I'm experimenting with the available APIs for error reporting. On XP systems, I'm using ReportFault(), which seems to work as expected- it displays the WER dialogs, sends data to the Winqual site (including minidump data), launches a debugger when asked for by the user etc.

That doesn't sound correct to me. In my experience, ReportFault() just returns frrvLaunchDebugger when somebody hits the 'debug' button and it is then up to you to do the launching. Are you sure you're not just seeing the exception go all the way out to the Unhandled Exception Filter provided by the O/S, which itself calls ReportFault() and knows how to launch the debugger




Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

John,

thanks for your message. It's not about the case when a debugger is launched - that works. It's the default reporting path (i.e. without hitting "Debug") which terminates the application - on Vista, that is.

Last night, I debugged into ReportFault() on Vista, and found that it launches a child process (wermgr.exe) which does the actual reporting. And while I don't have final proof for that claim yet, I think that it is that child process which terminates the calling process, probably using TerminateProcess() or similar APIs. In my test app, I have a top-level exception handler which catches everything, and I also tried a variation in which I explicitly called SetUnhandledExceptionFilter().

To sum it up, I'm pretty sure that ReportFault() changed its behavior in Vista. That in itself is not a showstopper since Vista has the new WER APIs which provide more explicit control for the error reporting process - but so far, I can't get fully satisfying results with those APIs, either. Hence my quest for sample code.

Claus

http://www.clausbrod.de/Blog


Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

For sample code and details about my findings on how ReportFault() on Vista behaves, check out my blog entry at http://www.clausbrod.de/Blog/DefinePrivatePublic20070616

Hope this clarifies some of my earlier notes on ReportFault().

Cheers,

Claus


Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

Hi all,

lacking sample code which shows how the WER APIs should be used correctly, I decided to make my own faulty code available instead The idea is to use this code to illustrate the issues which at least DHON and I seem to have, and give others a chance to look at the code, discover the embarrassingly dumb mistakes in it, and point them out to me

Well, a man can hope, can't he...

The code and a summary of the core issue (no minidumps with the new WER APIs, or so it seems) can be reviewed at http://www.clausbrod.de/Blog/DefinePrivatePublic20070618

Cheers,

Claus


Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

KINSHU [MSFT]

Hi Claus,

ReportFault is a deprecated API in Vista. We do not recommend setting up exception filters and calling ReportFault for crash reporting. Instead for reliability we recommend that you let the OS handle the exception. Your observation is correct that in some cases ReportFault on Vista may lead to process terminations. Further we also do not recommend trying to continue a process after it has encountered a crash. In Vista if you want to support Application recovery, please look at the RegisterApplicationRecoveryCallback API (http://msdn2.microsoft.com/en-us/library/aa373345.aspx). The callback can run for as long as needed if it keeps doing a keep alive ping as mentioned in the documentation.

Please let us know if there are further questions.

Thanks,

Kinshuman





Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

Letting the application crash and let the OS handle the situation instead of using our own exception handling mechanism is not (yet) an option for us. I definitely sympathize with the rationale behind this recommendation, and I hope that over time we'll get there, but at this point, it's just something that is deemed unacceptable from a user's perspective.

I'm not using ReportFault() any longer, except on XP where we don't have the new WER APIs. I would still maintain that ReportFault()'s behavior even on Vista itself is inconsistent, but that is not that relevant to me anymore now that I'm using the WER APIs on Vista.

My real issue is that an application which uses the WER APIs somehow can't send crash reports (or at least not complete ones, i.e. including minidumps) to the Winqual site - see earlier posts and my blog entry at
http://www.clausbrod.de/Blog/DefinePrivatePublic20070618. That's the area where I really need some help, I guess, because I'm running out of ideas 8-(

Thanks,

Claus

http://www.clausbrod.de/Blog


Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Jason Hardester - MSFT

Hi Claus,

I need to defer to Kinshu on the details of the WER APIs, but I do know that the Windows Vista WER behavior for saving the minidump is dependent on the Server side data request. This means that there will only be a minidump (or whatever was explicitly specified) if the servers are asking for a cab file containing data collection. This behavior is not consistent with older versions of Windows Error Reporting on XP and Server 2003.

Have you mapped your test application in Winqual This will set the server for data collection for your file. If this is the case, and you still don't see your cab files please post the event ID and EventType and I'll take a look at the servers.

Kind Regards,

-Jason





Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

Jason,

thanks a lot - what you're describing could indeed explain the differences in behavior that I'm seeing!

We created all the required mappings for the test applications, and did receive a couple of crash reports for them which were sent from XP client systems, and so I assume the registration and mapping process probably worked OK.

We registered a new version of a test application yesterday, and sent off a couple of crash reports this morning. We'll wait the usual 3-4 days now; if we still don't see any crash reports from Vista clients by then, I will post or send the event IDs.

Thanks for all your help!

Claus

http://www.clausbrod.de/Blog


Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Claus Brod

Jason,

when you say " there will only be a minidump.... if the servers are asking for a cab file containing data collection", I read this to mean:
  • By default, the clients do not produce a minidump file during WerReportSubmit().
  • During message exchange, the servers can ask the clients for additional information, and in that case, a minidump file will be produced locally and then sent to the server.
Is that an accurate interpretation

Thanks!

Claus


Top

Re: ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista

Jason Hardester - MSFT

Yes, that's right.

I do not know how the behavior changes when the data collection API is used though. I envision that the dump file would be created right away when WER data collection was registered by the application and made available through WERCON.exe on the local machine. However, this may be a wrong assumption. I'll check with Kinshu.

Thanks,

-Jason





Top