locked
ReportFault() vs. WerReportCreate/WerReportSubmit() on Vista RRS feed

  • Question

  • 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

    • Moved by Max Wang_1983 Tuesday, April 26, 2011 1:20 AM forum consolidation (From:Windows Error Reporting for ISVs)
    Wednesday, June 13, 2007 8:53 PM

Answers

  • 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

     

    Thursday, June 14, 2007 4:15 PM
  • 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

    Tuesday, June 19, 2007 6:32 AM
  • 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

     

    Tuesday, June 19, 2007 3:58 PM
  • Helen,

     

    A couple of answers for you:

     

    First,

    In an XP environment, users have to opt in to send us the data each time they encounter a crash, but in Vista, you only have to opt in once, when you first brought the machine on line.  If you have a Vista box, you can type WERCON at the start menu to bring up the WER Console and see all crashes that have been reported to MS.  The key value you want to see is BucketID, which is the EventID you will look for when you log in to the WinQual portal.  On older machines, the plumbing is not as good, so you won't have nearly as much data to work with.

     

    Second

    When a crash32 (the most common kind) occurs, we get 6 variables reported:

     

    AppName

    AppVersion

    ModName (module at the top of the stack)

    ModVersion

    ExceptionCode

    Offset

     

    When you mapped, the three bits we need are the filename, the file version, and the Linkdate/BuildDate.  We use the first two to identify files you "own" when a crash comes in.  The date is used to identify possible file name collisions, where two users are mapping the exact same file.  We want to make sure that you legitimately own a file (such as an open source dll, etc) and are not mapping a file from a competitor so that you can see their crash data. 

     

    Third,

    Claus is a very active user on the forum, so I'll let him authenticate the veracity of his code.  You can also contact him directly with questions via his blog/forum.  I find him to be very helpful.

     

    Hope that helps.  Feel free to contact us directly at wer AT microsoft DOT com.

     

    B

    Wednesday, February 27, 2008 5:35 PM

All replies

  • 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

     

    Thursday, June 14, 2007 4:15 PM
  • 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


    Thursday, June 14, 2007 5:03 PM
  •  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?

     

     

    Friday, June 15, 2007 4:20 PM
  • 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


    Friday, June 15, 2007 5:17 PM
  • 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

    Saturday, June 16, 2007 3:18 PM
  • 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

    Monday, June 18, 2007 3:24 PM
  • 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

    Tuesday, June 19, 2007 6:32 AM
  • 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

    Tuesday, June 19, 2007 7:02 AM
  • 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

     

    Tuesday, June 19, 2007 3:58 PM
  • 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

    Tuesday, June 19, 2007 4:10 PM
  • 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

    Tuesday, June 19, 2007 5:50 PM
  • 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

    Tuesday, June 19, 2007 8:09 PM
  •  

    Hi

     

    I have been following this thread and have downloaded and mapped a version of the example from http://www.clausbrod.de/cgi-bin/view.pl/Blog/DefinePrivatePublic20070625. It seems to work in as far as it says the report is uploaded. I have yet to see any info on my WinQual account.

     

    One question, it never prompts to ask if it is OK to send the data?

    Have I missed something?

     

    What criteria is used to marry up the exe with the winqual account.

    +Certificate

    +ExeName

    +Version

    and / or

    +Date

     

    Thanks

    Helen

     

    Wednesday, February 27, 2008 9:11 AM
  • Helen,

     

    A couple of answers for you:

     

    First,

    In an XP environment, users have to opt in to send us the data each time they encounter a crash, but in Vista, you only have to opt in once, when you first brought the machine on line.  If you have a Vista box, you can type WERCON at the start menu to bring up the WER Console and see all crashes that have been reported to MS.  The key value you want to see is BucketID, which is the EventID you will look for when you log in to the WinQual portal.  On older machines, the plumbing is not as good, so you won't have nearly as much data to work with.

     

    Second

    When a crash32 (the most common kind) occurs, we get 6 variables reported:

     

    AppName

    AppVersion

    ModName (module at the top of the stack)

    ModVersion

    ExceptionCode

    Offset

     

    When you mapped, the three bits we need are the filename, the file version, and the Linkdate/BuildDate.  We use the first two to identify files you "own" when a crash comes in.  The date is used to identify possible file name collisions, where two users are mapping the exact same file.  We want to make sure that you legitimately own a file (such as an open source dll, etc) and are not mapping a file from a competitor so that you can see their crash data. 

     

    Third,

    Claus is a very active user on the forum, so I'll let him authenticate the veracity of his code.  You can also contact him directly with questions via his blog/forum.  I find him to be very helpful.

     

    Hope that helps.  Feel free to contact us directly at wer AT microsoft DOT com.

     

    B

    Wednesday, February 27, 2008 5:35 PM
  • Thanks for that, the WERCON tool is very useful, I have found the bucket IDs and been able to see that the file I attached to the report is infact there and valid Smile I am now waiting to see the reports appear in the WinQual site.

     

     

    Thursday, February 28, 2008 9:36 AM
  •  

    I have waited a few days and still no sign of anything at the winqual site Sad

    Is there any way to track where its gone

    According to my system I have sent....

     

    27/2/08

    Problem signature

    Problem Event Name: APPCRASH

    Application Name: WERTest.exe

    Application Version: 1.0.0.0

    Application Timestamp: 3BAB9954

    Fault Module Name: WERTest.exe

    Fault Module Version: 1.0.0.0

    Fault Module Timestamp: 3BAB9954

    Exception Code: C0000005

    Exception Offset: B57AE

    OS Version: 6.0.6000.2.0.0.768.3

    Locale ID: 2057

    Extra information about the problem

    Bucket ID: 668675194

    3/3/07

    Problem signature

    Problem Event Name: APPCRASH

    Application Name: WERTest.exe

    Application Version: 1.0.0.0

    Application Timestamp: 3BAB9954

    Fault Module Name: WERTest.exe

    Fault Module Version: 1.0.0.0

    Fault Module Timestamp: 3BAB9954

    Exception Code: C000008E

    Exception Offset: B5780

    OS Version: 6.0.6000.2.0.0.768.3

    Locale ID: 2057

    Files that help describe the problem (some files may no longer be available)

    WERTest.elf

    View a temporary copy of these files

    Warning: If a virus or other security threat caused the problem, opening a copy of the files could harm your computer.

    Extra information about the problem

    Bucket ID: 668675053

    7/3/07

    Problem signature

    Problem Event Name: APPCRASH

    Application Name: WERTest.exe

    Application Version: 1.0.0.0

    Application Timestamp: 3BB36D9C

    Fault Module Name: WERTest.exe

    Fault Module Version: 1.0.0.0

    Fault Module Timestamp: 3BB36DA0

    Exception Code: C000008E

    Exception Offset: DB2B0

    OS Version: 6.0.6000.2.0.0.768.3

    Locale ID: 2057

    Extra information about the problem

    Bucket ID: 675261837

     

    Thanks

    Helen

    Friday, March 7, 2008 2:06 PM
  • Helen,

     

    I'm going to take this conversation off-line so I can share more specific information with you.

     

    b

     

    Monday, March 10, 2008 5:29 PM
  •  Helen Elcock wrote:

    One question, it never prompts to ask if it is OK to send the data?



    Yup, that's the default behavior on Vista. You can change this from the "Problem Reports and Solutions" control panel, if I remember correctly. (Cannot verify this right now, I'm posting this from my Ubuntu laptop 8-) )


    A variant of the code which I posted to my blog is used in one of our applications every day, and crash data has been coming in from quite a number of places over a period of several months, so I can confirm that the code works as, uhm, advertised.


    Claus

    http://www.clausbrod.de/Blog


    Sunday, April 6, 2008 12:05 PM
  • 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


    Thanks very much!
    Tuesday, January 25, 2011 7:08 AM