Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Windows Error Reporting and Online Crash Analysis are your friends.

Windows Error Reporting and Online Crash Analysis are your friends.

  • Comments 31

I normally don’t do “me too” posts, since I figure that most of the people reading my blog are also looking at the main weblogs.asp.net/blogs.msdn.com feed, but I felt obliged to chime in on this one.

A lot of people on weblogs.msdn.com have been posting this, but I figured I’d toss in my own version.

When you get an “your application has crashed, do you want to let Microsoft know about it?” dialog, then yes, please send the crash report in.  We’ve learned a huge amount of where we need to improve our systems from these reports.  I know of at least three different bug fixes that I’ve made in the audio area that directly came from OCA (online crash analysis) reports.  Even if the bugs are in drivers that we didn’t write (Jerry Pisk commented about creative lab’s drivers here for example), we still pass the info on to the driver authors.

In addition, we do data mining to see if there are common mistakes made by different driver authors and we use these to improve the driver verifier – if a couple of driver authors make the same mistake, then it makes sense for us to add tests to ensure that the problems get fixed on the next go-round.

And we do let 3rd party vendors review their data.  There was a chat about this in August of 2002 where Greg Nichols and Alther Haleem discussed how it’s done.  The short answer is you go here and follow the instructions.  You have to have a Verisign Class 3 code-signing ID to do participate though.

Bottom line: Participate in WER/OCA – Windows gets orders of magnitude more stable because of it.  As Steve Ballmer said:

About 20 percent of the bugs cause 80 percent of all errors, and — this is stunning to me — one percent of bugs cause half of all errors.

Knowing where the bugs are in real-world situations allows us to catch the high visibility bugs that plague our users that we’d otherwise have no way of discovering.

  • It still costs a bomb to get the code-signing ID that you need, but I suppose you don't want to send user's dumps to just anybody.

    We still need more entrants in the PKI marketplace. FreeSSL is by far the cheapest for SSL certificates, but isn't supported on Pocket PC, for example (I was looking at Exchange ActiveSync last week - having just set up my employer's first Exchange server - nothing like running before you can walk!)
  • could MS do some sort of stability manager
    reporting uptimes and signalling non-certified software/drivers ?
  • PocketPC doesn't let you add a new CA? I didn't know that.

    You're right that the cost of entry is high, but that barrier to entry is there to ensure that the person getting the dumps for an application is the legitimate owner of the application. It'd be really bad if Sun could sign up for Oracle's crash reports.
  • Exactly, if it gets too easy to obtain a certificate, then why should I trust them anymore?
  • Stefan,
    How would we be able to do this for non certified software? If "client.exe" crashes, which vendors "client.exe" is it? The executable isn't signed, so we don't know that it's Asheron's Call that crashed (instead of someone's LOB application).
  • 1. Create a self-signed certificate.
    2. Use this certificate to sign your application.
    3. Issue your application.
    4. Use the certificate to sign a request to access the Windows Error Reporting data for your application.

    You have proved that the entity requesting the crash reports is the same entity that created the application. Verisign wasn't involved (or any other CA) so it didn't cost $400.

    This doesn't work because Microsoft insist on a Verisign certificate, but this seems to be a commercial requirement rather than a technical requirement.

    I suspect that the real reason is to suppress demand for the crash reports - running this service can't be cheap for Microsoft.
  • Could be Carlos, but I'm not 100% sure about it.

    How can Microsoft trust your root CA? If the cert is self-signed, there's no way of knowing who you are. At least if you've signed up for a code signing cert with verisign, we can prove that you (a) have $700 to pay for the certificate and (b) have proven (to Verisign) that you really are who you purport to be.

    I don't believe that Microsoft gets ANY money from this program (I may be wrong), and if that's the case, why would Microsoft do this simply to enrich Verisign (since they're the ones getting the money)?
  • Funny, when I went to https://winqual.microsoft.com , i got a warning about an "unknown Certificate Authority". :)

    The only question I have about the $400 VeriSign fine is why is there only 1 company that can offer this? Surely VeriSign isn't the only company equipped for this service.
  • Shannon, I don't know why the GE CyberTrust Root CA's not installed in your browser, that's the root CA for that site.

    I don't know why VeriSign's the only company that Microsoft's contracted with to provide code signing certs, there are probably complicated business reasons I don't understand behind it.
  • You don't need to know who I am, you just need to know that I'm the same person who signed the software. You don't need to trust my root certificate to know this.

    On reflection, I think the reasons for requiring a Verisign certificate are more practical. Most software in the field is either unsigned (in which case Microsoft needs a Verisign certificate to identify the business requesting the crash reports) or signed with a Verisign certificate (so one exists anyway.) There's probably no-one but me signing software with a self-signed certificate :)
  • Shannon,
    I checked the cert out in Firefox and it also complained that it couldn't find the issuing certificate.
    But it also didn't allow me the option of adding the Microsoft CA. What's wierd is that even though it doesn't trust the Microsoft CA, I thought that the SSL cert verification was supposed to walk the chain of trust to the root CA and was supposed to trust a child CA if the parent CA is trusted.

    And in this case, the root CA (Ge CyberTrust) is trusted in Mozilla.

    Very wierd.
  • I looked in Mozilla, and the problem is probably that the chain is not there.

    Looking at the certificate hierarchy, I only see winqual.microsoft.com, which is signed by "Microsoft Secure Server Authority". Mozilla might know the root CA, but it can't know how to get from that certificate to the root CA, unless the server tells it (I know there is a way to make the server send both its certificate and other certificates in the chain, at least in Apache. I don't know how to do it in IIS).

    So, the fix is to make the server send the full certificate chain, and then I suppose Mozilla will trust the server.
  • I wonder why IE can walk the chain to the parent CA but firefox/mozilla can't.

    IE. claims that the issuer of the Microsoft SSA is Microsoft Internet Authority, and the issuer of that cert is the GE CA.

  • IE can walk the chain to the parent CA because IE ships with knowledge of "Microsoft Secure Server Authority" and "Microsoft Internet Authority".

    Look under "Intermediate Certification Authorities" in the certificate manager.
  • Whoops, I should think before I post...

    The two Microsoft CA certificates don't appear in "Intermediate Certification Authorities" until you've visited a site that uses them.
Page 1 of 3 (31 items) 123