Yes, you're correct - this is a hurdle for freeware, low-volume, and hobbyist developers. There is a team here that is working on making this more accessible to more software developers over time, and they will need to tackle this in order to reach that broader community. Their focus for the past few years has been on getting the large vendors, whose problems affect the largest % of customers, to focus on fixing the problems in their applications. They are making excellent progress on this, and hopefully you have seen responses to reports sent on crashes in 3rd party apps or drivers. This will continue as they work to make crash data more accessible and actionable to developers of all sizes.
I used to run the Windows Feedback team which built crash reporting into Windows XP (if you don't like "send error reports" you can blame me:-)
There are 2 things that people should know to put the 450K reporting systems into clearer perspective:
1.) Crash reports typically form a clear and very steep pareto curve. In fact, the top 1% of problems on XP accounted for over half of the reports. In other words; in general people tend to hit the same issues. This makes sense from a common sense perspective as well; one would expect a defect in a common code path in a popular application to be encountered more frequently than uncommon code paths in unpopular applications. It also means that emphasis can be placed on fixing *the most important* issues for the majority of customers and working down the curve to cover as much breadth as possible.
2.) The way crash reporting works is that it handles any unhandled exception which results in an app crash, or any kernel bugcheck. This means that 3rd party applications and drivers are reported as well as crashes in the OS and MS applications. When last I worked on this, there were over 6 million unique.exes reported and more than 95% of the reports by volume were in 3rd party code paths. I expect that distribution is a little more skewed towards MS code over the Vista development cycle since it was under devel, but my bet is that it is still predominantly 3rd party.
At the end of the day, the way that I hope people look at this is that it is better to have data about problems and act upon it, than to not collect the data. 450K Vista systems reporting errors means that the Vista team and 3rd party app/driver developers have had the data and opportunity to act upon it. This is a good thing.
The code doesn't need to be signed in order for the developer to get crash reports, but they do have to have a Verisign Class 3 cert in order to access data on their apps. This is to ensure that only one company can claim to be "Adobe" or "Blizzard" since Class 3 certs can only be issued in a given company's name once.
See my other post about what data can be sent under what circumstances. You are correct that we only ordinarily request the stack, not heap, when we request dump data at all (85% of the time we don't collect - even though you see it in the "Send/Don't Send" dialog.)
There is also a setting to exclude reporting for specific applications if you're concerned about apps which create large stack dumps. We added this setting specifically for this situation - to ensure that WER doesn't slow customers down from restarting the crashed app and getting back to what they were doing. You can find this under My Computer, Properties, Advanced, Error Reporting. The Choose Programs options lets you tune this.
That said, keep in mind that if you don't report the error, the company who wrote the app may not know the app has a problem they need to fix.:-)
The capability built into the OS would be a very poor way for a company to monitor employee activity, as data is only sent when the system encounters a problem (crash, hang, etc.), and the data is limited to that problem. Contrary to speculation, WER does not log activity such as which websites were browsed, emails sent, etc. If a problem occurs, a small snapshot of memory is collected if the user consents to send it. (The author of the story is correct that within a corporation the IT department can choose to send reports automatically to an internal site, but not automatically to MS.) You can satisfy your curiosity about what data would be sent fairly easily; write a small app that crashes (deref a null pointer or div/0). When the crash dialog comes up, take a look at what's included - load the minidump in the debugger to get a good look. You'll see that trying to use this data to monitor employee activity would be essentially useless. In an 8hr workday you'd be indescribably lucky to get a 1/2 second peek at what the employee was doing in just one thread of one app.
Hi, I'm Gabe Aul and I'm the Group Program Manager for the feedback technologies in Windows - both XP and Longhorn.
I've been reading the posts on this topic and would be glad to provide information to people who are interested in learning more about this functionality.
First, let me clarify what this actually is. Longhorn will contain the next generation of the Windows Error Reporting functionality (also known as "Watson") which is designed to detect problem states and allow customers to optionally report the problems to Microsoft to see if information is available to help them resolve it. More information on this functionality can be found here: http://www.microsoft.com/presspass/newsroom/office/features/connectionwp.asp and http://www.microsoft.com/mscorp/execmail/2002/10-0 2customers.asp
We currently respond to about half of the reports sent per/day with information about how to fix, workaround, or troubleshoot the problem. This includes both Microsoft and 3rd party applications, and there are over 1300 software vendors who are using WER to fix problems in their code, based on customer reports.
The most common questions/concerns I've seen posted seem to be:
"Can I turn this off?"
Yes, this is easy to turn off either through UI or Group Policy
"Is this opt-in or opt-out?"
This is strictly opt-in. In other words, no data is sent without express permission of the customer. Even the default for the buttons is "don't send" so that customers don't accidentally send by pressing Enter. This is true with both XP and Longhorn. The data collection policy for WER can be reviewed here: http://oca.microsoft.com/en/dcp20.asp. This is the statement customers can review before they click "send".
"What exactly is being sent to Microsoft?"
~85% of the time, we collect a parameterized description of the problem only. For app crashes the parameters are:
Name, version, and time/date stamp of the exe Name, version, and time/date stamp of the dll Hex offset into the module where the crash occurred.
~15% of the time, we collect some additional "first level" data to classify or diagnose the problem. For app crashes, this is a minidump of the process which crashed and a.txt file describing the application. Customers can review the information and choose not to send if they are not comfortable doing so.
~1/10th% of the time, we ask for some "second level" data; such as heap data for the crashed process. Customers are given an additional prompt for this data which has stronger wording to ensure they understand what is being sent and explicitly agree. Again, the default button is "don't send."
"What is the risk that reports may contain personal or sensitive data?"
For parameters; the risk is near zero. A hypothetical corner case where this could happen would be if an app was named so as to include private data (i.e. "my_password_is_foo_.exe") which is extraordinarily unlikely.
For first level data; it's possible, but uncommon, that the minidump may contain some personal data. For example; if your financial app crashed while you were typing in your account number, that number could be in a variable for the function that is on the stack at crash time, and therefore in the minidump. Other local variables for the process would not be in the minidump. Encrypted data in the stack variables is of course not readable. I have debugged hundreds of minidumps and have personally never seen such a case, but it is theoretically possible and we warn customers of this possibility in our data collection policy which customers can view before they send the report.
Slashdot Mirror
Yes, you're correct - this is a hurdle for freeware, low-volume, and hobbyist developers. There is a team here that is working on making this more accessible to more software developers over time, and they will need to tackle this in order to reach that broader community. Their focus for the past few years has been on getting the large vendors, whose problems affect the largest % of customers, to focus on fixing the problems in their applications. They are making excellent progress on this, and hopefully you have seen responses to reports sent on crashes in 3rd party apps or drivers. This will continue as they work to make crash data more accessible and actionable to developers of all sizes.
I used to run the Windows Feedback team which built crash reporting into Windows XP (if you don't like "send error reports" you can blame me :-)
There are 2 things that people should know to put the 450K reporting systems into clearer perspective:
1.) Crash reports typically form a clear and very steep pareto curve. In fact, the top 1% of problems on XP accounted for over half of the reports. In other words; in general people tend to hit the same issues. This makes sense from a common sense perspective as well; one would expect a defect in a common code path in a popular application to be encountered more frequently than uncommon code paths in unpopular applications. It also means that emphasis can be placed on fixing *the most important* issues for the majority of customers and working down the curve to cover as much breadth as possible.
2.) The way crash reporting works is that it handles any unhandled exception which results in an app crash, or any kernel bugcheck. This means that 3rd party applications and drivers are reported as well as crashes in the OS and MS applications. When last I worked on this, there were over 6 million unique .exes reported and more than 95% of the reports by volume were in 3rd party code paths. I expect that distribution is a little more skewed towards MS code over the Vista development cycle since it was under devel, but my bet is that it is still predominantly 3rd party.
At the end of the day, the way that I hope people look at this is that it is better to have data about problems and act upon it, than to not collect the data. 450K Vista systems reporting errors means that the Vista team and 3rd party app/driver developers have had the data and opportunity to act upon it. This is a good thing.
The code doesn't need to be signed in order for the developer to get crash reports, but they do have to have a Verisign Class 3 cert in order to access data on their apps. This is to ensure that only one company can claim to be "Adobe" or "Blizzard" since Class 3 certs can only be issued in a given company's name once.
See my other post about what data can be sent under what circumstances. You are correct that we only ordinarily request the stack, not heap, when we request dump data at all (85% of the time we don't collect - even though you see it in the "Send/Don't Send" dialog.) :-)
There is also a setting to exclude reporting for specific applications if you're concerned about apps which create large stack dumps. We added this setting specifically for this situation - to ensure that WER doesn't slow customers down from restarting the crashed app and getting back to what they were doing. You can find this under My Computer, Properties, Advanced, Error Reporting. The Choose Programs options lets you tune this.
That said, keep in mind that if you don't report the error, the company who wrote the app may not know the app has a problem they need to fix.
The capability built into the OS would be a very poor way for a company to monitor employee activity, as data is only sent when the system encounters a problem (crash, hang, etc.), and the data is limited to that problem. Contrary to speculation, WER does not log activity such as which websites were browsed, emails sent, etc. If a problem occurs, a small snapshot of memory is collected if the user consents to send it. (The author of the story is correct that within a corporation the IT department can choose to send reports automatically to an internal site, but not automatically to MS.) You can satisfy your curiosity about what data would be sent fairly easily; write a small app that crashes (deref a null pointer or div/0). When the crash dialog comes up, take a look at what's included - load the minidump in the debugger to get a good look. You'll see that trying to use this data to monitor employee activity would be essentially useless. In an 8hr workday you'd be indescribably lucky to get a 1/2 second peek at what the employee was doing in just one thread of one app.
I've been reading the posts on this topic and would be glad to provide information to people who are interested in learning more about this functionality.
First, let me clarify what this actually is. Longhorn will contain the next generation of the Windows Error Reporting functionality (also known as "Watson") which is designed to detect problem states and allow customers to optionally report the problems to Microsoft to see if information is available to help them resolve it. More information on this functionality can be found here: http://www.microsoft.com/presspass/newsroom/office
We currently respond to about half of the reports sent per/day with information about how to fix, workaround, or troubleshoot the problem. This includes both Microsoft and 3rd party applications, and there are over 1300 software vendors who are using WER to fix problems in their code, based on customer reports.
The most common questions/concerns I've seen posted seem to be:
"Can I turn this off?"
Yes, this is easy to turn off either through UI or Group Policy
"Is this opt-in or opt-out?"
This is strictly opt-in. In other words, no data is sent without express permission of the customer. Even the default for the buttons is "don't send" so that customers don't accidentally send by pressing Enter. This is true with both XP and Longhorn. The data collection policy for WER can be reviewed here: http://oca.microsoft.com/en/dcp20.asp. This is the statement customers can review before they click "send".
"What exactly is being sent to Microsoft?"
Name, version, and time/date stamp of the exe
Name, version, and time/date stamp of the dll
Hex offset into the module where the crash occurred.
"What is the risk that reports may contain personal or sensitive data?"