I’m sure at one time or another you’ve all seen a certain happy window pop up on your phone. You know, the one that says a problem has occurred and asks if you’d be willing to tell Microsoft about it. If you haven’t seen it on your phone, well awesome, then maybe you’ve seen it on your desktop machine.
What you might not know is that this window is generated by Watson, which is a component of Windows Error Reporting (WER). Specifically, Watson is the client-side executable that is activated when an unhandled exception occurs on your phone. Watson is responsible for preparing an error report (stack details, system information, variable information, etc), notifying the user about the error (happy window), and with the users consent sending the file to Microsoft (via data or ActiveSync). Assuming the user chooses to send the report, these encrypted files are then added to a WER database where they can be reviewed by Microsoft technical support personnel and Microsoft developers.
That’s definitely great, but if the reports all go to Microsoft how can you as a developer take advantage of this great data? Well, I’ve been in touch with the team responsible for reviewing and addressing these reports and we’d like to try to be more active about sharing with you. While we can’t share the reports themselves, what we can do is use this blog to talk about some of the most common crashes we see that result from coding and development issues. For this inaugural post, I’d like to take a quick look at three issues that have been showing up recently.
Issue #1: You’re passing THAT in the buffer!?
One issue that has showing up frequently concerns applications that try to retrieve text from a treeview item using the message TVM_GETITEM. For this scenario, the caller is responsible for passing a buffer and a buffer size to a TVITEM structure. The function TV_GetItem() then copies the amount of requested text to the output buffer using wcsncpy(). The reports we’re seeing are for crashes during this operation. Upon investigation it seems that there could be a mismatch between the buffer allocated and the buffer size specified by the application in the TVITEM structure. Buffer size should be specified in TCHARS, not in bytes. The following code fragment shows the reason for the crash.
Issue #2: What did that buffer ask for again?
Another issue we’re seeing is with applications that are trying to retrieve column header text with the message LVM_GETCOLUMN. Similarly to the previous issue, the caller is responsible for passing a buffer and the buffer size in an LV_COLUMN structure. The function Str_GetPtrW() then copies the amount of requested text to the output buffer. It’s during this operation that we’re seeing crashes. Once again, it seems this issue is caused by a mismatch between the buffer allocated and the buffer size specified by the application in the LV_COLUMN structure. Within LV_COLUMN the buffer size must be specified in TCHRS as opposed to bytes, otherwise the application will exceed the bounds of the buffer.
Issue #3: .NET CF v1.0 is sooo 1990s
A final issue we’ve been seeing lately, concerns the .NET CF. Sometimes .NET CF v1.0 applications are installing MSCOREE1_0.DLL, which is the .NET CF v1.0 runtime. This version is no longer being shipped and should not be installed when the .NET CF v2.0 is installed. Although this issue is more general than the other two, we’ve seen this problem fairly frequently.
Please let us know if you found this information useful or, if you didn’t, what we can do to make it more relevant.