Claus Brod


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




Re: Bucket ID 8, event type

DHON


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






Re: Bucket ID 8, event type

Saar Picker - MSFT

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






Re: Bucket ID 8, event type

Claus Brod

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)





Re: Bucket ID 8, event type

DHON

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





Re: Bucket ID 8, event type

Claus Brod

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

 





Re: Bucket ID 8, event type

Claus Brod

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)






Re: Bucket ID 8, event type

Jason Hardester - MSFT

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






Re: Bucket ID 8, event type

Claus Brod

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.





Re: Bucket ID 8, event type

DHON

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..............





Re: Bucket ID 8, event type

DHON

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.





Re: Bucket ID 8, event type

Jason Hardester - MSFT

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






Re: Bucket ID 8, event type

Claus Brod

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





Re: Bucket ID 8, event type

Jason Hardester - MSFT

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






Re: Bucket ID 8, event type

DHON

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