locked
Bucket ID 8 RRS feed

  • Question

  • Hi all,

    on my Vista system, I generated a lot of crash reports using WER-aware code (i.e. code which explicitly uses WerReportCreate() and WerReportSubmit()). When I look at those crash reports in the Problem History window, I find that many of those crash reports have a bucket ID of 8. This doesn't look like a bucket ID as it would be assigned for a crash report which makes it to the Winqual site. Does a bucket ID of 8 have a special meaning, such as "not accepted by Winqual", or "submitted to Winqual and waiting to be classified", or something similar?

    Thanks!

      Claus

    http://www.clausbrod.de/Blog

    • Moved by Max Wang_1983 Tuesday, April 26, 2011 2:14 AM forum consolidation (From:Windows Error Reporting for ISVs)
    Wednesday, June 20, 2007 6:02 AM

Answers

  •  

    Claus,

     

    Actually, the event with Bucket ID of 8 is not the event you're trying to report, but an event letting us know that someone tried to attempt what you are attempting now. As you can tell, Microsoft does not accept all reported events. We filter out unknown event types. Since your report is not of a recognized event type, it is being rejected. The Bucket ID 8 event is reporting the rejection to us. In the future, we plan to allow users of http://winqual.microsoft.com to register their own event types for collection.

     

    DHON,

     

    Event ID on the site is synonymous with Bucket ID. This may change in the future, but for now you can enter the Bucket ID in the search box on the site to retrieve a particular event, as long as this event belongs to your company. We are working to develop new views that can more meaningfully expose events. If there is a particular view you would like, please let us know in the comment form on any page in the site.

     

    Thanks,

    -Saar Picker

    Developer Portal - http://winqual.microsoft.com

    Wednesday, June 20, 2007 5:31 PM
  •  

    Hi Dhon,

     

    Althrough the AppMap tool is not explicitly supported on Vista, there are no known problems with running it on Vista at this time. The tool is still considered a Beta because we are still accepting feedback for revising it. Keeping it in Beta mode allows us to quickly turn around new features and bug fixes. You should feel safe using it on Vista or Windows XP/2003, though we don't guarantee it will be completely trouble-free.

     

    If you do run into any problems or there are any modifications you would find useful, please let us know here on this forum or in the site comment boxes.

     

    Thanks,

    -Saar Picker

    Developer Portal - http://winqual.microsoft.com/

    Wednesday, June 27, 2007 1:50 AM
  • Hi DHON,

     

    Since you are working against a deadline, send an email to WER@Microsoft.com and we will get you any technical support you need for implementing WER APIs to do Error Reporting, Application Restart and Recovery, and additional Data Collection.  I am on that email alias as well so we will be expecting your mailing.   That way we can get your contact information and perhaps even set up a conference call with you.

     

    You don't need to use WerReportCreate.  This is for creating a custom 'non-fatal' event.  In your case, you don't need to do anything but use the restart and recovery APIs.

     

    I don't have a date to communicate to you for exposing automated custom event registration through Winqual, but if this is something you need today we can manually register it for you and work with you directly on the review process to get approval for the registration.  We can also create a custom report for you while we implement a formal solution.  We are here to help!

     

    I don't feel that there is a logo requirement for using the WER APIs (I talked to the Logo PM, and he confirmed this), but it would be a good idea to use the recovery APIs since the report has a priority and order list for executing data collection, recovery, and restart when WER is invoked.  Basically, then you register for data collection, recovery, and application restart the events happen in that order (1- Data Collection, 2- Recovery + callback, 3 - App Restart).  It's not clear how the timing would be if you used WER for reporting but did your own recovery and restart.  WER may not be finished doing what it needed when the app is restarted.

     

    Kind regards,

    -Jason

    Wednesday, June 27, 2007 5:52 PM

All replies

  •  

    Same is the case with me. For all the reports at my end, bucket id mentioned is 8.

    Also, when you login to Winqual, there also I can't find the bucket id - only event id is noticeable.

    Can anybody tell me how to find the bucket id of a particular reports in Winqual server ?

     

    Thanks,

    DHON

    Wednesday, June 20, 2007 9:06 AM
  •  

    Claus,

     

    Actually, the event with Bucket ID of 8 is not the event you're trying to report, but an event letting us know that someone tried to attempt what you are attempting now. As you can tell, Microsoft does not accept all reported events. We filter out unknown event types. Since your report is not of a recognized event type, it is being rejected. The Bucket ID 8 event is reporting the rejection to us. In the future, we plan to allow users of http://winqual.microsoft.com to register their own event types for collection.

     

    DHON,

     

    Event ID on the site is synonymous with Bucket ID. This may change in the future, but for now you can enter the Bucket ID in the search box on the site to retrieve a particular event, as long as this event belongs to your company. We are working to develop new views that can more meaningfully expose events. If there is a particular view you would like, please let us know in the comment form on any page in the site.

     

    Thanks,

    -Saar Picker

    Developer Portal - http://winqual.microsoft.com

    Wednesday, June 20, 2007 5:31 PM
  • Saar,

    thanks a lot for the explanation! So this means that hardly any of the crash reports which I ever tried to send from Vista clients actually made it to the Winqual servers - I'm getting that bucket ID 8 all the time, basically, so almost all my crash reports were rejected!

    We have signed our product with a Verisign ID, and we explicitly mapped four different versions of the product which we're testing. For one of these versions, two crash reports made it to the Winqual site, even though the cab files are missing. There should have been more crash reports than just two for that version, because I ran a lot more tests. For the other three test versions,  the situation is even worse - no crash report which originated from a Vista system has showed up on the Winqual site.

    We started to test more or less systematically more than two weeks ago, so we're well beyond the usual delay of 3-4 days.

     Claus (running out of ideas)

    Wednesday, June 20, 2007 7:35 PM
  • Thank you Saar for clearing my doubt.

    So, not a single crash report at my end reached Winqual(bucket id = 8)

     

    Another observation :

    When user is online and the crash happens, report is immediately sent and bucket id is assigned.

    In case user is offline, report is queued up and later on when online; I go to "Problem Reports and Solutions" and check for a

    solution. Now, satus of that report changed to "Report sent". If you open that report, bucket id not shown. What is the reason ?

     

    I induced AV into Notepad.exe thru ThreadHijacker and received the following report with meaningfull bucket id (Winqual event id) :

     

    Problem signature

    Problem Event Name: APPCRASH

    Application Name: notepad.exe

    Application Version: 6.0.6000.16386

    Application Timestamp: 4549b0be

    Fault Module Name: StackHash_5ca6

    Fault Module Version: 0.0.0.0

    Fault Module Timestamp: 00000000

    Exception Code: c0000005

    Exception Offset: 000c0005

    OS Version: 6.0.6000.2.0.0.256.4

    Locale ID: 1033

    Additional Information 1: 5ca6

    Additional Information 2: f97edd77e921976e524b381d08b56403

    Additional Information 3: db13

    Additional Information 4: aeb79da6b2d41ef2c9852a2ddfad7821

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

    Version.txt

    AppCompat.txt

    minidump.mdmp

    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: 356519695

     

    When I did the same to MicrosoftWord  I received :

     

    Problem signature

    Problem Event Name: APPCRASH

    Application Name: WINWORD.EXE

    Application Version: 11.0.6568.0

    Application Timestamp: 42e178a5

    Fault Module Name: StackHash_bda4

    Fault Module Version: 0.0.0.0

    Fault Module Timestamp: 00000000

    Exception Code: c0000005

    Exception Offset: 02510005

    OS Version: 6.0.6000.2.0.0.256.4

    Locale ID: 1033

    Additional Information 1: bda4

    Additional Information 2: 50938b1b1a918ec83c25fa941e022ac6

    Additional Information 3: ad08

    Additional Information 4: 43e82d96f535b47ce8675fc73c2109be

     

     

    without any bucket id assigned. Although report status was "Report sent"

     

    Any explaination !

     

    I don't know why Microsoft is not providing sample code for these new APIs. Every time they refer to the sample code available for old ReportFault API - not the Vista specific

    WER API. Looking at the forum, it seems no one has succesfully executed these new WER API on Vista.

     

    Thanks,

    DHON

     

     

    Thursday, June 21, 2007 5:06 AM
  • Saar,

     

    two more questions for clarification (sorry).

     

    First, you say that a bucket ID of 8 means that our crash reports were rejected by the servers. I assume this means that those crash reports will never show up on the Winqual site, no matter how long we wait for any processing to complete, right?

     

    Second, you say that those crash reports may have been of an unexpected event type, which would lead to rejection. When you say "event type", are we talking about the event type parameter that is passed in the call to WerReportCreate()? Code example:

     

    Code Snippet

    PCWSTR eventType = L"werapitest (eventType)";

    HREPORT hReportHandle;

    if (SUCCEEDED(pWerReportCreate(eventType, WerReportCritical,

          &werReportInfo, &hReportHandle)) {

      ...

    }

     

     

    If that is the event type we're talking about, which value should I use as the event type to make sure my crash reports are accepted? The mysterious APPCRASH_EVENT constant from werapi.h maybe?

     

    If "event type" means something different, what exactly is it, and how can I fix it so that my crash reports come through?

     

    Thanks,

     

      Claus

     

     

     

     

    Thursday, June 21, 2007 7:03 AM
  • I tried APPCRASH_EVENT as the magic "event type" constant now, and indeed, this changes behavior.

    Before, both WerReportCreate() and WerReportSubmit() would report success, but the Problem History would indicate a bucket ID of 8, and no information was sent to the Winqual site.

    Now, with the APPCRASH_EVENT event type, WerReportSubmit() returns with E_FAIL, with no indication of what the problem actually is. No entries in the event log nor in the Problem History window.

    From these observations, we can conclude that the event type parameter in WerReportCreate() indeed plays a significant role in the crash reporting process, i.e. it is not just a cosmetic parameter.

    Once again, I'm stuck. In a way, this is worse than before. Before these findings, I could hope that this is all some configuration and/or processing issue on the Winqual site which would magically resolve itself over time. Now, I have reason enough to think that my WER code is faulty, but I have long run out of ideas for tweaking it. Oh, what I would give for WER API sample code! Saar, Jason, Kinshu, whoever's listening at Microsoft: My code is at http://www.clausbrod.de/Blog/DefinePrivatePublic20070618. Any hints on what else I could try?

    Claus (frustrated)


    Thursday, June 21, 2007 1:19 PM
  • Hi Claus,

     

    I am sorry that the APIs are a cause of frustration for you.  I have taken your post (via email) to the lead developer of the APIs for WER on Windows Vista as well as others, and the feedback is that you should not create a report in this way for a crash (instead, let the default behavior handle creating your event and simply register for your data collection and other desired behavior). 

     

    In the way you are attempting to use the the WERAPIs here, you will need to go out of process to be reliable and will also need to register the event name. On top of that, you will also need to be able to create bucketing parameters (Event Crash Signatures) reliably.

     

    I do know that if you are defining a 'custom' eventtype, your event will not reach Winqual as it will be rejected by the Microsoft servers that handle the incoming WER traffic.  This is because event types are required to be registered (somethig required for the way you are using the APIs in your sample).  All of the default event types are obviously registered such as 'Crash32' and 'Crash64'.  This is why you can see these types of events in Winqual and not your custom test one.

     

    We have released the ability to do custom events in Windows Vista in anticipation of enabling developers around the world to define custom (...non-fatal) events to gain more insight into the behavior of applications released in the wild.  We will enable developers to use this behavior by offering an event registration workflow on Winqual.  It will be similar to the general workflow of registering a WER response today with states such as 'Pending Approval', 'Declined', and 'Live'. 

    The code required to enable this scenario is not yet in place, and there are some complexities we are working through in regards to legal agreements around the usage of these report types and assurance of not intentionally collecting personally identifiable information.

     

    Claus, does this ease your frustration?  We are here to help!

     

    Kind regards,

    -Jason

    • Proposed as answer by micTronic Tuesday, August 10, 2010 8:18 AM
    Thursday, June 21, 2007 5:16 PM
  • Jason,

    I'm all in favor of using the OS default exception handling, I share all the concerns about trying to deal with crashes in an application environment which has already become unstable, and I've been lobbying internally to follow recommendations such as yours.

    However, the harsh reality is that our application has had a top-level exception handler for decades now, which has worked so well that our customers won't accept it if we suddenly remove their safety net. We've got a plan to reduce the dependency on the top-level exception handler in several steps, over several releases, but at this point, just relying on the OS and letting the app crash is not yet an option for us.

    The first step in the direction of Microsoft's recommendations is to start using the WER dialog, which is what I have been working on for several weeks now - but only to learn that the Winqual site intentionally rejects my crash reports, that there is no sample code whatsoever to learn from, and now (from you) that it essentially cannot be done anyway. Does that ease my frustration? Well, not exactly.

    But then, maybe it can be done. After all, good ol' ReportFault() does almost everything we want, even on Vista, apparently also including sending crash reports to the Microsoft servers. If ReportFault() can do that, why not the new WER APIs?

    You mention I need to register the event name. Is "event name" the same as the event type parameter in WerReportCreate()? If so, do I also need to register the event name/type if I just the apparently predefined "APPCRASH" constant? Or should I use "Crash32"?

    Thanks,

      Claus

    http://www.clausbrod.de/Blog

    PS: Don't get me wrong, I appreciate all your help and your input. I don't mean to sound harsh or impolite, but I probably do - this stuff is simply one of the most frustrating development tasks I've been working on in quite some time.

    Thursday, June 21, 2007 7:31 PM
  • After spending sufficient time to implement WER API successfully,  I came to following conclusion :

     

    If you have not introduced WER API into your code and your product crashed, then

     

         -  You get a detailed report with attached files to it.

         -  Also bucket id returned seems to be meaningfull

     

    Now, you introduced WER API to your code and your application crashed :

     

         - Not a detailed report found in Problem Reports and Solutions

         - Bucket id returned is 8 - which means rejected.

     

    After all this behavior and going thru this forum, I feel,  WER APIs  released by Microsoft are not yet proven.

    If this is the state of these API, can somebody from Microsoft confirms this,  so that I can wait till the issues are fixed by Microsoft instead of shooting in the dark ?

     

    Looking for some suggestion from Microsoft people..............

     

     

     

     

     

    Friday, June 22, 2007 6:34 AM
  • Hi Claus,

    Here, I have one more observation. When I use APPCRASH event type behavior is similar to what you mentioned.

    Now, If I use another registered event type PCA2 (no idea what this event type is for), WerReportSubmit() returns S_OK and report is also visible in Report history - ofcourse with bucket id = 8.

     

    I used PCA2 as I found a report with this event name and valid bucket id.

     

     

    Friday, June 22, 2007 7:24 AM
  • Claus, DHON,

     

    I think I am missing some essential information.  Why are you trying to create your own crash eventtype? 

     

    For some additional information ...a crash is already a known eventtype, so you don't have to define it.  Depending on the computer, a general native code crash is defined as 'Crash32' or 'Crash64' depending on the Operating System type.  There are some special exceptions that are typed differently such as Buffer Overruns (when the code is compiled with the Visual Studio /GS switch) and DEP (Data Execute Protection - or NX).  We also see special casing of a crash for Safe CRT (an example would be an unsafe string copy using the S-CRT APIs). 

    In addition to these events, there are managed code events, Hung application events, and Mobile device events that are publically consumable without having to define the eventtype.  The signature types for these events are already defined as well, and are matched at the service on report.  It's not that Winqual blocks events that are not registered, but rather they never get accepted by the front end reporting servers because they don't fit the schema for the eventtype.

     PCA2 in an internal eventtype (Generically created through code and registered on the Microsoft servers).  You get BucketID 8 here because you are not matching up on known signatures for that eventtype.  It's rather moot because mimicking this eventtype will not get you what you need because it is not publically exposed (it's used internally).

     I feel I missed the problem you have been trying to solve, and that has lead to some confusion since the answers offered are reactive to the questions. 

     

    Let me know what problem(s) you are trying to solve and I'll make sure you get the assistance you need. 

     

    Kind regards,

    -Jason

     

    Friday, June 22, 2007 3:56 PM
  • Jason,

    thanks again for the background.

    All I want is this: When a crash occurs, the WER dialogs should be displayed to alert the user, and to give him the choice to send the crash data to the Microsoft servers. That's all.

    Why did I use my own event types? Because the documentation is unclear about the relevance and meaning of the "event type" parameter in the WerReportCreate() API, and because until very recently I did not even know that there are also some predefined event types, and that they have a special meaning to the whole reporting mechanism. Correct me if I'm wrong, but I don't think those special event types such as "Crash32" and "Crash64" are documented anywhere.

    On top of that, I found it extremely difficult to get to the core of the issue. To debug WER code, one has to know an awful lot about how the Winqual servers work; determine what the meaning of certain magic bucket IDs is; find out that the old way of setting up a CER server (by using a simple network share) doesn't work any longer on Vista; obtain and set up Microsoft Operations Manager 2007 which seems to be the "successor" solution to the old CER approach; or, alternatively, as in my case, set up some network sniffing tools in order to find out what kind of data are exchanged; dig through the documentation of various generations of error reporting infrastructure documentation with different nomenclatures for similar things; and all this in the context of exception filters, which aren't that simple to debug anyway. Oh, and not to forget, whenever I finally arrive at a reasonably stable state of code, I have to wait at least three days until I can verify my changes by checking the "latest" crash reports on the Winqual site.

    Probably it's just me, but the whole topic has a distinct "beware the leopard" feeling to me (see http://www.planetclaire.org/quote9.html).

    BTW, using "Crash32" or "Crash64" as an event type in WerReportCreate() doesn't work for me either - I still get bucket ID 8.

    I was able to get a reasonable bucket ID using "APPCRASH" as an event type today. I'm still debugging this version of the code, and probably will have to wait three days for the crash reports to show up on Winqual, but this approach finally looks promising. More on this hopefully by Monday.

    Claus

    http://www.clausbrod.de/Blog

    Friday, June 22, 2007 5:39 PM
  • Claus, I agree with you, the documentation is not very clear. 

     

    I have the right teams involved to correct that, although you won't find documentation for eventtype names of Crash32 and such in the API documentation since this is transparent to folks consuming the APIs.  It is true that we expose those eventtype names 'as is' in Winqual but that can change.  I simply  explained the behavior here because I saw examples of eventtype names taken from the event logs that had report success. 

     

    In reading your posts, it is clearly difficult to 'test' your WER implementation.  I'll champion making this easier in the future.  I see the difficulty stemming around a lack of code examples, and a test harness that will give a success/fail for the ability to report to Microsoft successfully.

     

    I would separate that problem from actually 'debugging'.  You don't need to know the details of how the service works to download and debug a failure, but in your case you are looking to show that everything works end-to-end.  I agree that E2E testing is really hard.  I envision that this is why you brought CER into the fold since it is not really mainstream with reporting crash data through Microsoft and making it available in the WER Services hosted on https://winqual.microsoft.com.  CER and AEM are ITPRO management solutions that enable an administrator to broker crash data between the client machines and Microsoft, and is not a solution we expect ISVs to have to implement or test against.  You have my commitment that I'll champion a solution.

     

    On an aside, you don't have to set up network sniffers to use WER.  (that gives the wrong impression to readers). 

    In looking at your posts holistically, you are trying to solve a very specific problem... how to handle your own exception and yet still use WER so that you can gain logo compliance.  What you are trying to do is not recommended by the WER client or WER Service team in general so there is no documentation on it. 

    We will talk to the Windows Vista Software Logo PM to see what your logo options are.  It's not a technical problem, but rather a business problem.  It is technically possible to do what you want, and you should engage with your Logo contacts to make sure what you are trying to do solves the problem of logo acceptance.  If it does, then I am sure they will provide the implementation details (or they can bring in folks from the WER teams to assist).  Does that make sense? 

     

    I am not minimize the troubles you are having (and I apologize for them), but on the other hand I don't want to confuse readers into thinking they have to go through a thousand convoluted steps to use WER successfully. 

     

    ...this forum is set up to provide answers and exchange ideas to make things better.  I'll assist in getting the help you are looking for (see my post in your related thread here).

     

    kind regards,

    -Jason

    Saturday, June 23, 2007 6:29 PM
  • Hi Jason,

    Thanks for clarifying some of my doubt.

    The product I am working sends a crash report to a particular mail id of the company (crashreport@abc.com) with details. It also saves any open document whenever a crash occurs. This is the present status of my product. Till now it is not using any WER API - not even ReportFault().

    Now, I am looking into implementation of this part and ofcourse I have a timeline set for this. As you mentioned, documentation is not clear, so I am running into lots of problem and not sure at this point whether I will be able to deliver it in the planned release of the product !

     

    Coming back to implementation, if we don't need to mention our own event type, then we always have to mention APPCRASH event type in WerReportCreate(). PCA2 is also not exposed. Does this change will solve my problem ? Will the crash dump added to my report ? Let me try. Fyi, I am using reporting thru internet - not CER/AEM.

     

    In one of your earlier post you mentioned that user will be able to register his own eventtype and Microsoft is working on that flow.

    Can you let me know when we can expect that update from Microsoft ?

     

    I have another query. As I already mentioned we do save any open document if crash occurs. In this scenario do we need to implement WER specific Application Recovery callback separately ? If not implemented, will that be an obstacle in getting the certificate for TC32 ?

     

    As I am running against a specific deadline, so your prompt answer will help me in taking faster decision.

     

    If you need any further info about my product, pl., let me know.

     

    Thanks,

    DHON

    Monday, June 25, 2007 5:14 AM
  • Jason,

    seems like part of our initial communication disconnect was (slightly exaggerated) that Microsoft didn't really expect any ISV to use the WER APIs for crash reporting, while at least for me such usage was obvious, and in fact it was hard to see for me what other purpose those WER APIs could possibly have than reporting crash data and sending them to the Winqual site.

    Once again, I appreciate your help with this, and thank you as well for your willingness to bring up and discuss the topic internally on a broader scale.

    I just checked the latest crash reports on Winqual, and it seems that finally the expected reports from my Vista clients arrived there! So it seems that my latest approach (still based on the WER APIs) actually works. I'll double-check, and then post about the details.

    Cheers,

      Claus

    http://www.clausbrod.de/Blog

    Monday, June 25, 2007 6:21 AM
  • Hi Claus,

    Congratulations !

    At last some hope of succesfull mplementation of  WER.

     

    Please, share the changes at your end.

    One of course is eventtype - which has to be L"APPCRASH"

    what are the others ?

     

    What about the crashdump ?

     

    What are the flags you are using in WerReportSubmit() ?

     

    Waiting for your replies...............

     

    Thanks,

    DHON

    Monday, June 25, 2007 8:37 AM
  •  

    What I noticed is that, when I assign eventtype as L"APPCRASH" in  WER_REPORT_INFORMATION then other members of that struc has to  be filled with related info. Otherwise WerReportSubmit fails.

    Claus : As you have implemented successfully with L"APPCRASH", so could you pl., share the values of other parameters in that struc ?

    I am really impatient now after knowing that things are working properly at your end

     

     

    Monday, June 25, 2007 9:50 AM
  • Hi Jason, Claus

     

    Here are some update from my side.

    I used APPCRASH as event name and called WerReportSubmit() with WER_SUBMIT_NO_QUEUE flag and it was failing. Reason, according to me  is that my product is not mapped explicitely - although earlier version of the product was mapped. As Jason mentioned earlier that mapping has to be explicit.

     

    Now, I used WER_SUBMIT_QUEUE flag and WerReportSubmit() is working properly. Also, dump is attached to the report. Now, my report looks like

     

    Product

    Appln 7.30r0

    Problem

    Stopped working

    Date

    6/25/2007 4:10 PM

    Status

    Not Reported

    Description

    Critical runtime problem

    Problem signature

    Problem Event Name: APPCRASH

    OS Version: 6.0.6000.2.0.0.256.4

    Locale ID: 1033

    Files that help describe the problem

    minidump.mdmp.

     

    Hope that once product is mapped, report will be posted to Winqual ! I would like to have following info in my report - which at present is not there. Any suggestion ?

     

    Application Version: 11.0.6568.0

    Application Timestamp: 42e178a5

    Fault Module Name: StackHash_bda4

    Fault Module Version: 0.0.0.0

    Fault Module Timestamp: 00000000

    Exception Code: c0000005

    Exception Offset: 02510005

     

    Feeling lots better now    

     

    Still I have one/two questions.

    a) How, can I open my .mdmp file ?

    b) Is the mapping of the product is total responsibility of Wiqual account administrator of the company ?

    c) Do I need to have any particular exe in my system so that report reaches the Winqul server ?

     

    Waiting for some response.............

     

    Regards,

    DHON

     

    Monday, June 25, 2007 11:26 AM
  • Hi all,

     

    the details of my solution are now available from http://www.clausbrod.de/Blog/DefinePrivatePublic20070625 - feedback most welcome. Thanks again in particular to Saar and Jason who provided hints on what to look for.

     

      Claus

     

     

     

    Monday, June 25, 2007 12:31 PM
  • DHON,

     

    if you use WerReportSubmit() in queueing mode, then I don't think you're testing the complete process, i.e. "end-to-end", to quote Jason. My guess is that even after registering/mapping your code, the Winqual servers will still reject your crash reports.

     

    Minidump files can be opened and inspected in Visual Studio ("Open/Project"). Load the file, then hit F5. (I sometimes prefer to use Windbg for minidump analysis.)

     

    As far as I understand it, Microsoft does not prescribe who in your company is responsible for product mapping.

     

    And finally, executables such as wermgr.exe and WerFault.exe are used for error reporting. On systems which have the WER API, those executables are part of the OS, so you don't have to worry about that part.

     

    Claus

     

    Monday, June 25, 2007 1:31 PM
  • Thank you Claus, for clearing my doubt.

     

    Yes, without end to end testing I won't be sure.  Also we never implemented this kind of error reporting in our earlier releases.

    I have an account in Winqual with limited permissions. Admin right is with another person. In this case, can I map the product ?

    Also what is the exact process of mapping ? What are the files we need to select ?

     

    Would you please share this info from your practical experience ? Now, atleast I am able to generate a much detailed report. So as a next step,  would like to send the report to Winqual.

     

    Thanking you again for your help..

     

    Thanks,

    DHON

     

    Tuesday, June 26, 2007 3:55 AM
  • DHON,

     

    on winqual.microsoft.com, you'll find a link that says "Establish an account". On the next page, select your company. Enter your user name and password, and enter your account details. Your registration will be sent to the "company account administrator" in your company who is responsible for managing Winqual accounts, and s/he will give you the required access rights - at least this is how it worked for me. I was asked whether I wanted to view and download crash reports only, or if I also needed to map products.

     

    If you already have an account, check with te company account admin, and have him modify your privileges.

     

    When I registered, there already was someone in my company who handled the product mapping, and so I got myself view/download privileges only. Therefore, I cannot really comment on the details of product mapping. But the process is approximately like this: Using the Microsoft Product Feedback Mapping Tool that you can download from Winqual, you generate an XML file which contains data about your executables and DLLs such as name, link date, checksum, version info, and signature information. That file is then uploaded to the Winqual servers, which tells the servers how to handle crash reports coming from that particular version of your software.

     

    We were told that in general it is sufficient to map the main .exe only. That executable must have version information, and needs to be signed.

     

    Hope this helps,

     

    Claus

     

    http://www.clausbrod.de/Blog

     

     

    Tuesday, June 26, 2007 5:18 AM
  • Thanks for all the information. But documentation says that this tool does not have support for Vista.

     

  • Windows XP and Server 2003 Support

    AppMap.exe currently runs on the Windows XP and Server 2003 platforms. AppMap is not supported on prior Windows versions of Windows Operating Systems or the new version, Windows Vista.

     

    So, how it was handled in your organization ? Also this release is Beta only. But, I could generate the xml file - not sure whether uploading of this file will solve the issue !

     

Tuesday, June 26, 2007 7:06 AM
  • DHON,

     

    our executables are the same on Vista and on XP, and we simply run the mapping process on an XP machine. Even if your Vista bits were different, you could still at least install them on an XP system (or mount a shared directory) and then run the mapper tool.

     

    Claus

     

    Tuesday, June 26, 2007 7:29 AM
  •  

    Hi Dhon,

     

    Althrough the AppMap tool is not explicitly supported on Vista, there are no known problems with running it on Vista at this time. The tool is still considered a Beta because we are still accepting feedback for revising it. Keeping it in Beta mode allows us to quickly turn around new features and bug fixes. You should feel safe using it on Vista or Windows XP/2003, though we don't guarantee it will be completely trouble-free.

     

    If you do run into any problems or there are any modifications you would find useful, please let us know here on this forum or in the site comment boxes.

     

    Thanks,

    -Saar Picker

    Developer Portal - http://winqual.microsoft.com/

    Wednesday, June 27, 2007 1:50 AM
  •  

    Thanks Saar, for the update about AppMap

     

    Thanks,

    DHON

    Wednesday, June 27, 2007 4:59 AM
  • Hi DHON,

     

    Since you are working against a deadline, send an email to WER@Microsoft.com and we will get you any technical support you need for implementing WER APIs to do Error Reporting, Application Restart and Recovery, and additional Data Collection.  I am on that email alias as well so we will be expecting your mailing.   That way we can get your contact information and perhaps even set up a conference call with you.

     

    You don't need to use WerReportCreate.  This is for creating a custom 'non-fatal' event.  In your case, you don't need to do anything but use the restart and recovery APIs.

     

    I don't have a date to communicate to you for exposing automated custom event registration through Winqual, but if this is something you need today we can manually register it for you and work with you directly on the review process to get approval for the registration.  We can also create a custom report for you while we implement a formal solution.  We are here to help!

     

    I don't feel that there is a logo requirement for using the WER APIs (I talked to the Logo PM, and he confirmed this), but it would be a good idea to use the recovery APIs since the report has a priority and order list for executing data collection, recovery, and restart when WER is invoked.  Basically, then you register for data collection, recovery, and application restart the events happen in that order (1- Data Collection, 2- Recovery + callback, 3 - App Restart).  It's not clear how the timing would be if you used WER for reporting but did your own recovery and restart.  WER may not be finished doing what it needed when the app is restarted.

     

    Kind regards,

    -Jason

    Wednesday, June 27, 2007 5:52 PM
  • Hi Jason,
    Sorry to tag onto this thread a full 2 years later.  I'm having the same troubles Claus Brod had.  I've read his blog and this thread and I still don't get it.  The documentation seems to be in the same state it was 2 years ago (i.e. WER is still basically undocumented) and it appears from what I read in this thread and on his blog that one shouldn't be using WerCreateReport to report crashes.  This thread does not make it clear what one should do instead when one wants to attach a file.  Our code is exactly like Claus' in that we have had our own error detection, file creation and emailing, etc.  Now in order to get a logo we are required to do WER.  If I pull out all of our own code so that the OS naturally handles WER, how can I get the log file created and attached to the windows error report?  I've hooked up WER code just like what's mentioned in Claus' blog but again, that seems to be an unsupported and unrecommended approach.

    I feel like I've had to go through a thousand convoluted steps to get WER going.  I note that WerCreateReport only gets about 52 hits in google and most are due to Claus Brod trying to figure this out.  Who uses this stuff?  If I didn't know better, WER is something to keep users treading water and running in place instead of further developing their product.

    Thanks in advance.
    -Michael Viking
    Tuesday, July 7, 2009 9:08 PM