Why do you have to wait for Windows Error Reporting to check for solutions before it restarts the application?

Leo Davidson wonders why you have to wait for Windows Error Reporting to check for solutions before it restarts the application. Why not do the two in parallel?

Well, for one thing, when the application restarts, it might freak out if it sees a dead copy of itself. I know for sure that I would freak out if I woke up one morning and saw my own dead body lying next to me.

While Windows Error Reporting is checking for a solution, it still has access to the carcass of the crashed application, because it may need to refer to it in order to answer follow-up questions from the server. (“Hey, was version 3.14 of PI.DLL loaded into the process when it crashed? If so, then I may have an idea what went wrong.”) And so that, if you ask it to submit the crash to Microsoft, it can grab the information it needs in order to generate the crash report.

Now suppose you start up a new copy of the application right away. If the application is a single-instance program, it will look around for another copy of itself, and hey look, it’ll find its own lifeless body in the middle of the computer version of an autopsy. It will then try to send messages to the dead program, saying, “Hey, the user wants to open document X; could you do that for me?” And it won’t get a response because, well, the program is dead. It’s never going to respond.

Some programs don’t even try to pass information along. They just find the existing copy of the program, and call Set­Foreground­Window on its main window, thereby switching to it. Of course, what they tried to do was switched to a crashed program.

Even worse, what if the second copy of the program tries to extract information from the existing copy of itself? If the existing copy crashed, it’s highly likely that the crash was caused by corruption in the program’s internal data structures. When the second copy tries to extract the corrupted data, it may itself crash. Immediately launching the replacement program creates a very quickly-growing pile of dead programs, and your screen basically gets spammed with Windows Error Reporting dialogs faster than you can click OK.

The crashed program has effectively launched a denial of service attack against itself.

Before trying to start the program again, Windows makes sure that the previous copy has received a proper burial. Because few programs are prepared to see their own cadaver.

Bonus chatter: Another common scenario is that the program crashes at startup. Automatically restarting the program would just launch another copy that immediately crashes. Again, you get into the situation where you get a dozen copies of the program launched per second, all of which immediately crash.

Comments (47)
  1. pcooper says:

    I'm sure there are more "features" that could be added here. Windows could somehow try to "hide" processes that Error Reporting is working on extracting data from. There could be a "Restart now" button in the dialog for the user to click. Error Reporting could be smarter about how many copies of itself should run at once.

    But I can't imagine how any of those could possibly be worth the effort, considering by the time you have a crash things have already broken horribly. Making crash recovery any more complicated than it already is would just be another chance for things to go wrong.

  2. I'm under impression MS doesn't care about its own crash information. Windows 7 explorer crash (on deleting a folder in the tree pane) still left unfixed even in SP1.

    [The crash information is studied very carefully. In Windows XP, 29% of all crashes were fixed in SP1. (I can't find statistics on Windows 7.) Sorry your crash was not in that 29%. -Raymond]
  3. de@iru.ch says:

    Raymond, sadly you only told us why a stupid implementation of the proposal wouldn't work. It'd be great if you could explain why it's not done in a way that would work (either quickly copy all info to another location or hide the process). I guess the answer is less interesting: Too much work for too little benefit?

    ["Quickly copy all info": "All info" is basically the entire state of the computer. You have the process address space (2GB or even more on 64-bit machines), the window manager state, the file system state, etc. How do you quickly copy 2GB of data, most of which is probably needs to get paged in first? It reminds me of the Monty Python sketch "How To Do It." And imagine how happy malware authors would be if it were possible to hide a process. -Raymond]
  4. David Crowell says:


    I assume that's not an explorer bug, but a shell extension.  I can't reproduce it on my machine.  I'm sure the Microsoft Support folks could determine the issue if you provide a stack trace.  :)

  5. kog999 says:


    To go alone with the too little benefit I think you have to consider a program crashing to be a lets say "traumatic event" for the user. They have already been inconvienced and possibly lost data, If windows error reporting take an extra 20 seconds to complete before restarting the app that should be the least of there worries.

  6. Can you not set it already to ask you each time before reporting so you can quickly click "Restart" without reporting and "Check for solutions" later from Action Center.

  7. de@iru.ch says:

    @Raymond: Mapping the same address space just requires the duplication of some PTEs – that's done in a few microseconds. Window state should be copiable very quickly too (most likely not paged out anyway). The file system is a good argument, didn't think of that.

    Also you don't have to hide the process from everyone – changing it's identity would be good enough. The big problem with that would be that you'd have to change it in all the various name spaces… As the kernel already has a concept of all the things a process owns it could do a proper job there.

    It's certainly doable. But probably not worth the effort?

  8. Thanks for answering that!

    I didn't realise WER was a two-way conversation, or that it might require info that takes a long time to generate/store, and only require it sometimes such that it doesn't make sense to generate/store all of it in advance, then kill the process and do the query in the background.

    I assumed the OS would collect any required info (DLL versions, crash minidump perhaps; things which generally take under a second to save to disk and which definitely take much less time than the query itself takes) and bundle that off in the request.

    Thanks again for the explanation of what's going on.

  9. Damien says:

    I don't know about you guys, but I have never had this system actually find a solution for me, as a result I have disabled it.

  10. Justin Chase says:

    I find both of these steps incredibly annoying. I wish it would neither try to find a solution (since it never does, it always fails) or restart since just restarting is almost never what I actually want. For example VS crashes all the time and when I open it I may have opened it from a command prompt that has some special environment variables set which affects how projects open and get built. If VS is just automatically restarted by the OS then it doesn't have those parameters and I end up having to wait for it to load to remember that fact and close it down and reopen it manually anyway. Just let me open crashed apps up again the way I know they aught to be opened please.

  11. Rick C says:

    @Damien and Justin Chase, I have had it find solutions a few times.  Usually there's a newer version of a driver that fixes whatever caused the crash.

  12. Joshua says:

    @Justin Case: Join the party. I've taken to patching out bugs in Visual Studio by injection. Obviously this does not work if Visual Studio restarts itself.

  13. User #{598DE456-3B99-42D2-9FAF-99E9BAFCBB60} says:

    I would be very lucky if any of my bugs were fixed by Microsoft,

    but currently I'm on my own.

    No, honest why do actively developed programs trigger WER?

  14. @alegr1 I just performed the steps exactly as you described and the folder was deleted without a problem, Explorer just moved up a directory. I'm running Windows 7 x64 SP1.

  15. James says:

    @David Crowell: I'm not competent enough to understand the stack trace alegr1 posted, but I can confirm that Explorer in a fresh Win7 x64 setup with no 3rd party shell extensions displays a "Location is not available" error and then crashes on cue. So there. :)

  16. James says:

    @Brad: I'm surprised you couldn't reproduce the issue. I'm using SP1 as well. I find it interesting though that there need to be some files (at least one) in the folder or else the crash does not seem to occur. Since the crash also does not occur in other random locations, could it be due to the indexing service trying to index the files in the Documents folder and crashing Explorer when it's rudely interrupted (complete guess on my part of course).

  17. @James: I just tried it again and the crash occurred. It seems to happen only when I do it via the "Libraries" branch of the tree view, doesn't happen via the Computer->Partition->Users->User->Documents branch.

  18. EricE says:

    @alegr1, I can confirm the crash as well.  Windows 7 Pro 64-bit, SP1.  Start | Documents, create new folder, renamed it to zdiddly to get it to the bottom of the list.  Copied 5 Excel files and one image into the directory.  Selected the directory in the left pane and then shift-deleted it.  Explorer pops up a message box saying that the location is no longer available.  When the box was dismissed, Explorer crashed.

  19. This particular crash exposes a usability problem and also reminds me of another usability problem.

    Explorer is watching for the folder changes, using, as I think, ReadDirectoryChanges function. This function doesn't always work, mostly because of some fine security issues or race conditions. For example, I've seen it not working if the folder owner/creator was different from the current user.

    If the Explorer is asked to navigate to a folder which is not there anymore, it might do much better than showing a dreaded modal dialog. Another example of bad modal dialogs is when the system returns from hibernation and the network folder connections are broken. Or when you reconnect an RDP session, all open folders in \tsclient become invalid. The error message in this case is even more cryptic.

  20. I've reproduced this explorer crash in Win8 RP doing the same steps.

  21. Damien says:

    It wound seem *reasonable* to have a limit of *2* (wow, for once the right answer wasn't zero, one or inifinity) for open WER windows per binary – if you're the first WER window, attempt to launch a fresh copy and do the error reporting in parallel. If you're the second WER window, then act as the current one does. That removes the self_DOS and startup crash issues you raise, whilst making things more responsive if the application *doesn't* look for other copies of itself

  22. Adam Rosenfield says:

    My experience with a certain program is that often when it sometimes crashes after doing a certain thing, after it gets restarted by WER, it'll crash again if I do the same thing again.  But if I close it, re-launch it normally, and repeat that same thing, it *doesn't* crash.  Does WER do anything special when re-launching a crashed program?  Or could that program be doing something to try to reload some of its previous state (despite not having a cadaver to inspect) that would cause it to behave differently than if it were re-launched manually?

  23. km007 says:


    What your basically describing is process forking. The new process inherits all the handles and address space of the old process. I believe Windows 7 adds a similar feature called reflected processes which is the same thing. By reflecting the process into a dummy process you can take a minidump of the process without actually freezing it for the entire duration.

  24. @David Crowell:

    As you wish:

    1. Create a folder in Documents, put a few files in it.

    2. Select the folder in the tree pane.

    3. Hit Shift+Del, click Yes.

    4. The folder will be deleted, Explorer now complains that the selected folder disappeared.

    5. As you dismiss the complain message box, Explorer crashes:

    0:022> !analyze -v


    *                                                                             *

    *                        Exception Analysis                                   *

    *                                                                             *


    Debugger CompCtrlDb Connection::Open failed 80004005

    Cannot access CompCentralDB. You may need to request access: http://windows/access

    Debugger Dbgportaldb Connection::Open failed 80004005

    Database Dbgportaldb not connected


    DUI70!DirectUI::BTreeLookup<HINSTANCE__ *,DirectUI::IClassInfo *>::GetItem+f

    74b0852e 394104          cmp     dword ptr [ecx+4],eax

    EXCEPTION_RECORD:  ffffffff — (.exr 0xffffffffffffffff)

    ExceptionAddress: 74b0852e (DUI70!DirectUI::BTreeLookup<HINSTANCE__ *,DirectUI::IClassInfo *>::GetItem+0x0000000f)

      ExceptionCode: c0000005 (Access violation)

     ExceptionFlags: 00000000

    NumberParameters: 2

      Parameter[0]: 00000000

      Parameter[1]: 3215b819

    Attempt to read from address 3215b819

    FAULTING_THREAD:  0000137c


    PROCESS_NAME:  Explorer.EXE

    ERROR_CODE: (NTSTATUS) 0xc0000005 – The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

    EXCEPTION_CODE: (NTSTATUS) 0xc0000005 – The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.



    READ_ADDRESS:  3215b819


    DUI70!DirectUI::BTreeLookup<HINSTANCE__ *,DirectUI::IClassInfo *>::GetItem+f

    74b0852e 394104          cmp     dword ptr [ecx+4],eax





    LAST_CONTROL_TRANSFER:  from 74b08692 to 74b0852e


    06c5f53c 74b08692 671abac8 00000000 00380030 DUI70!DirectUI::BTreeLookup<HINSTANCE__ *,DirectUI::IClassInfo *>::GetItem+0xf

    06c5f550 74b08f48 671abac8 74b085e8 00380030 DUI70!DirectUI::Element::_GetLocalValueFromVM+0x13

    06c5f568 74b08f1a 671abac8 00000000 13789890 DUI70!DirectUI::Element::_GetSpecifiedValueIgnoreCache+0x13

    06c5f580 74b08676 671abac8 00000000 06c5f5c0 DUI70!DirectUI::Element::_GetSpecifiedValue+0x292

    06c5f590 671f5079 671abac8 00000002 00000000 DUI70!DirectUI::Element::GetValue+0x40

    06c5f5a8 671bc27c 00000000 00000001 00000000 EXPLORERFRAME!ItemLayout::GetItemCount+0x14

    06c5f5c0 671bc1d1 06c5f5f4 00000000 00000000 EXPLORERFRAME!UICollection::TryToRealizeIndex+0x24

    06c5f624 671e1ead 07e350b8 671e1e95 06c5f6fc EXPLORERFRAME!UIItemsView::LocateFocusedItem+0xd3

    06c5f62c 671e1e95 06c5f6fc 000004cc 00000000 EXPLORERFRAME!UIItemsView::_ProcessUpdateFocus+0xe

    06c5f680 765686ef 0069094e 000004cc 00000000 EXPLORERFRAME!UIItemsView::WndProc+0x48a

    06c5f6ac 76568876 74b0bbaa 0069094e 000004cc USER32!InternalCallWinProc+0x23

    06c5f724 765643cf 00758334 74b0bbaa 0069094e USER32!UserCallWinProcCheckWow+0x14b

    06c5f754 765643f5 ffff0111 0069094e 000004cc USER32!CallWindowProcAorW+0x99

    06c5f774 74aa2ab7 ffff0111 0069094e 000004cc USER32!CallWindowProcW+0x1b

    06c5f798 765686ef 00000000 000004cc 00000000 DUser!ExtraInfoWndProc+0x76

    06c5f7c4 76568876 74aa2a52 0069094e 000004cc USER32!InternalCallWinProc+0x23

    06c5f83c 765643cf 00758334 74aa2a52 0069094e USER32!UserCallWinProcCheckWow+0x14b

    06c5f86c 765643f5 74aa2a52 0069094e 000004cc USER32!CallWindowProcAorW+0x99

    06c5f88c 74d9450e 74aa2a52 0069094e 000004cc USER32!CallWindowProcW+0x1b

    06c5f8a8 74d9463d 0069094e 000004cc 00000000 comctl32!CallOriginalWndProc+0x1a

    06c5f90c 74d945f1 13c1c978 0069094e 000004cc comctl32!CallNextSubclassProc+0x3d

    06c5f930 671f3020 0069094e 000004cc 00000000 comctl32!DefSubclassProc+0x46

    06c5f9a4 671f2fad 0069094e 000004cc 00000000 EXPLORERFRAME!UIItemsView::_UIItemsViewSubclassProc+0x2a6

    06c5f9c0 74d9463d 0069094e 000004cc 00000000 EXPLORERFRAME!UIItemsView::s_UIItemsViewSubclassProc+0x1c

    06c5fa24 74d945f1 13c1c978 0069094e 000004cc comctl32!CallNextSubclassProc+0x3d

    06c5fa48 671f33cd 0069094e 000004cc 00000000 comctl32!DefSubclassProc+0x46

    06c5fa68 671f3375 0069094e 000004cc 00000000 EXPLORERFRAME!CToolTipManager::_PropertyToolTipSubclassProc+0x12b

    06c5fa84 74d9463d 0069094e 000004cc 00000000 EXPLORERFRAME!CToolTipManager::s_PropertyToolTipSubclassProc+0x1c

    06c5fae8 74d945f1 13c1c978 0069094e 000004cc comctl32!CallNextSubclassProc+0x3d

    06c5fb0c 74d8fa37 0069094e 000004cc 00000000 comctl32!DefSubclassProc+0x46

    06c5fb28 74d9463d 0069094e 000004cc 00000000 comctl32!TTSubclassProc+0x59

    06c5fb8c 74d946e1 13c1c978 0069094e 000004cc comctl32!CallNextSubclassProc+0x3d

    06c5fbec 765686ef 0069094e 000004cc 00000000 comctl32!MasterSubclassProc+0x54

    06c5fc18 76568876 74d9469d 0069094e 000004cc USER32!InternalCallWinProc+0x23

    06c5fc90 765689b5 00758334 74d9469d 0069094e USER32!UserCallWinProcCheckWow+0x14b

    06c5fcf0 76568e9c 74d9469d 00000000 06c5fd44 USER32!DispatchMessageWorker+0x35e

    06c5fd00 671b3500 06c5fd18 00000002 00000000 USER32!DispatchMessageW+0xf

    06c5fd44 67212081 00000000 00000000 06c5fd6c EXPLORERFRAME!CExplorerFrame::FrameMessagePump+0x495

    06c5fd54 672125c5 03a02208 7655817d 03907a60 EXPLORERFRAME!BrowserThreadProc+0x49

    06c5fd6c 67212572 03a07bc8 03907a60 06c5fd9c EXPLORERFRAME!BrowserNewThreadProc+0x43

    06c5fd7c 671b041e 03907a60 01000000 80000000 EXPLORERFRAME!CExplorerTask::InternalResumeRT+0x11

    06c5fd9c 772c618e 03907a74 7fffffff 039e82e8 EXPLORERFRAME!CRunnableTask::Run+0xce

    06c5fdb8 772c60f9 06c5fdf4 00000000 00000000 SHELL32!CShellTask::TT_Run+0x167

    06c5fe00 772baa98 06c5fe90 771d46bc 039e82e8 SHELL32!CShellTaskThread::ThreadProc+0xa3

    06c5fe08 771d46bc 039e82e8 00000000 00000000 SHELL32!CShellTaskThread::s_ThreadProc+0x1b

    06c5fe90 76c71194 0016f1b4 06c5fedc 77f1b299 SHLWAPI!WrapperThreadProc+0x1b5

    06c5fe9c 77f1b299 0016f1b4 7138b9ec 00000000 kernel32!BaseThreadInitThunk+0xe

    06c5fedc 77f1b26c 771d45e9 0016f1b4 00000000 ntdll!__RtlUserThreadStart+0x70

    06c5fef4 00000000 771d45e9 0016f1b4 00000000 ntdll!_RtlUserThreadStart+0x1b


    SYMBOL_NAME:  DUI70!DirectUI::BTreeLookup<HINSTANCE__ *,DirectUI::IClassInfo *>::GetItem+f

    FOLLOWUP_NAME:  wintriag


    IMAGE_NAME:  DUI70.dll


    STACK_COMMAND:  dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~22s ; kb

    FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_DUI70.dll!DirectUI::BTreeLookup_HINSTANCE___*,DirectUI::IClassInfo_*_::GetItem


    WATSON_STAGEONE_URL:  watson.microsoft.com/…/0003852e.htm

    Followup: wintriag


  25. Engywuck says:

    german Win7 x32 SP1, confirmed

    btw: when is SP2 due?

  26. Amit says:

    Has anyone actually seen WER dialog find a solution? For me it always says Windows did not find a solution to your problem…

  27. de@iru.ch says:

    By the way: Explorer still crashes in Win8 RP when deleting a folder from the Documents library in the treeview.

  28. t@speot.is says:

    This just made it onto the front page of Reddit as "One of the biggest lies of Microsoft": http://i.imgur.com/WHdZf.jpg

  29. David Walker says:

    @Amit:  If you read the comments, others have already answered your question.  Yes, people have had WER find solutions to their problems.  I have too.

  30. David Walker says:

    I can reproduce the Explorer crash also, IF you start by opening Documents from Libraries as someone else mentioned.  Interesting.  

    Windows 7 x64, SP1.

  31. I've had the Win7 explorer crash when deleting a directory that is currently open, just like everyone else here is complaining about.  Running Win7 x64 SP1 here – everything up-to-date on Windows Update.  I've tried to train myself not to delete anything that is open in explorer.  If I forget, it seems like 50/50 chance explorer will blow up.

    Personally I'm surprised it hasn't been fixed yet; you'd think there would be a boatload of people at Microsoft who would try to delete a directory that is open and want to see the problem fixed.  It's not like this is a rare crash.

    "I've reproduced this explorer crash in Win8 RP doing the same steps."

    That's discouraging.  Sheesh…. maybe…. cross your fingers… if we're lucky, they will fix it in Windows 9!!!  Too late to fix it in Win8, and heaven forbid you actually want to see it fixed in Win7.  Of course, when it's fixed, we'll be dealing with all the new bugs introduced in Win8 for years to come…

    That's the thing about Windows – it's 99% stable these days, but it has 1% of bugs that they never fix yet always affect me somehow, which stand out like really annoying thorns in the backside.

  32. "That's the thing about Windows – it's 99% stable these days, but it has 1% of bugs that they never fix yet always affect me somehow, which stand out like really annoying thorns in the backside."

    So true. Good example: Intellimouse software, which one can install from Windows Update, if you got MS mouse. After its installation, wheel scrolling in IE becomes EXTREMELY fast. This problem was known and existed for a few years since major version 8 of intellimouse (judging by users' complaints on MS forums). The problem is still there in major version 10.

  33. Cheong says:

    @alegr1 : Confirmed Explorer in Win7 x64 with lastest patch and no custom shell extensions will crash when following these instructions.

    From the stack trace it seems like UI bug where the BTree view doesn't handle the folder delete case well…

  34. Anthony Wieser says:

    WER (now sysdev.microsoft.com) is brilliant, but you need to sign up.

    Once you do, you upload xml summaries of images of your shipped files, and when the system checks for errors, it will upload a stack trace of the crash for you, that you can download later.

    If you figure out a solution or workaround to the problem, you the developer can upload a response file, which is shown to the user as a "solution".  So the reason @Amit and @User{GUID} don't see any responses is because the developer hasn't joined up.

    You should join.  Really you should.  You just need to get a Verisign certificate and a notary to certify your business papers, and then you in business.


    I don't work for Microsoft, and never have, but have found a lot of bugs this way.  Our software is configured to email us crash dumps, but most users don't bother to send them in.

  35. ender says:

    Why does Microsoft limit many of their services to Verisign only? There are several other certificate providers.

  36. Joshua says:

    @Anthony Wieser: I've intercepted the crash readouts for direct injection only to find my debugger can't use the minidump files to produce usable backtraces. For me, there's no point in joining so I just don't care anymore.

  37. kog999 says:

    so reguarding the explorer bug posts. has anyone called MS Support to report this as a bug. It still may not get fixed at least you will get a lot closer to getting it fixed the posting on Raymonds personal blog.

  38. "has anyone called MS Support to report this as a bug."

    I haven't:

    1.  They will charge me money before I can even talk to somebody about reporting it.  Since my computer came with Windows 7 preinstalled, I am not sure if that is even an option since I didn't buy the retail version.  And I don't see how I'd even begin to get anywhere with my OEM's technical support on this – it's a Windows problem, not a problem with my computer hardware.
    2.  I will probably have to argue with some clueless outsourced person overseas who is reading a script.  It will probably take hours, and the call would have to be elevated to people higher up who have a clue – if I can convince them to do that.

    3.  I've heard they will refund your money if it turns out to be a bug in the product.  But since they start out by charging my credit card, the onus is on me to try to prove that it's a bug.  That could be difficult (see #2) – plus if they don't acknowledge it's a bug, then they get to keep my money.

    The system is stacked against me as an individual user; I'm not worth enough money to Microsoft to bother with.  Maybe if I was a large company buying thousands of licenses I would have some clout, but I'm not.  If I had a more direct line to people at Microsoft who have a clue, I'd be more willing to bother – but I don't really know anyone there.

    Maybe it won't be as bad as I think it would be.  But it's often said that a new software feature starts with "-100 points" – there needs to be enough benefits to justify the cost.  Same thing with this issue.  It's annoying, but not annoying enough to make me want to go through all that hassle.

  39. Jim says:

    I'm pretty Raymond's article wasn't titled "Why WER is great and has fixed all crashes in Explorer". He explained one aspect of it, and if another aspect of it isn't working that's not really relevant. Anyway unfixed Explorer bugs reported with it aren't even WER's responsibility, it's up to the Explorer team to look at the data and use it.

  40. @JamesJonston:

    I've been through that (though I used "free" MSDN support cases), and the whole thing is incredibly ineffective and frustrating. Every next support person cannot be bothered to read the case history. And then (in one case) when you talk to yet another guy, they finally find that it's a known problem (was \tsclient losing connection from a virtual machine when the VM window size is changed).

    Another time I was hoping MS would contact the BD-drive vendor and file the bug against them (media state change not detected when BDR-205 is connected to an AHCI controller). As it turns, MS doesn't have any clout with IHVs. Or don't care to be an advocates for user that have to convince the IHV that there is a problem. I even had an IO trace (BUSTRACE) for them proving the bug. A reply from the IHV support was "if you're not satisfied, you may return the product". Thanks, but no thanks.

    And also, how many support cases from users is required before MS will consider fixing a bug? 10? 100?

    Is it a surprise I don't bother anymore?

    [Depending on the component, 100 crashes may not be enough. You may have to get it into the hundreds of thousands. Remember, you're in competition with every other crash in that component. -Raymond]
  41. Danny says:

    "The crash information is studied very carefully. In Windows XP, 29% of all crashes were fixed in SP1. (I can't find statistics on Windows 7.) Sorry your crash was not in that 29%. -Raymond]"</quote>

    Well Ray? Nothing to say? After alegr1 exposed how you can easy do it and all people experienced you went silent for the rest of the comments! Done with thermonuclear comments after you check it on your PC as well?

    [Just because it's easy to do doesn't mean it's in the top 29% of all crashes. (A lot of times, I go silent because I queued up an article to discuss the matter further.) -Raymond]
  42. [Just because it's easy to do doesn't mean it's in the top 29% of all crashes.]

    Each component has its own crashes. This particular problem has been 100% of Explorer crashes I personally experienced. Or is it like "we only fix the buggiest parts"?

    [Bug-fixing resources are finite. It sounds like you would focus them on the parts of Explorer that aren't very buggy. -Raymond]
  43. Cheong says:

    @alegr1 : Agreed. My MSDN support call experience didn't go very satisfactory too. That was a UI bug of Excel that's been floating around for some time. A few workaround has been posted on the web but all of them requires your Office document not be protected by password. So I decided to use my MSDN support incident to see if anything can be done on it. On the case description I clearly stated the workarounds I've found and why they won't work for me, and I just demend that they forward a bug report for me to responsible division in MS (everything in English).

    The support person handling this case is speaking Mandarin, but my mother tongue is Cantonese. Okay, my Mandarin is not good but I can live with that… but he keeps sending me "solutions" that I already stated in the case description that won't work in attempt to close the case… In the end I have to tell him to stop… it's just a known feature defect and just help me submit the case to the bug database.

  44. Neil says:

    I don't always run my development software under a debugger, so when it crashes, I have to wait for WerFault.exe to "process" the crash before I can click Debug, even though I have asked Windows not to report errors from my application…

  45. 640k says:

    WER is not worth the time, it's a pain to use as a developer. Your resources are better spent fixing bugs randomly.

  46. Joshua says:

    [It sounds like you would focus them on the parts of Explorer that aren't very buggy. -Raymond]

    In general, that's often a better idea than it sounds. Getting rid of the last few crash bugs in a much less buggy section may or may not increase the general perception disproportionally becusue tolerance for certain kinds of bugs is lower in components that don't have many left. Also, very buggy components get replaced with less friction so you are more likely to lose them anyway.

  47. Anthony: Getting crash dumps can be handy; the last desktop (GUI) app I shipped, I included a last-resort exception handler which would POST the backtrace via HTTP. Not totally reliable of course – no use with authenticating forced proxies, or of course offline users – but good enough to gather useful information and fix problems when they arose.

    The Verisign-only restriction is a pain (and odd, with no reason ever given that I've seen), particularly since until recently it also meant that only certain types of businesses could register at all (no "sole trader" businesses or individuals) but they have finally fixed that, so once I explained to their support rep that Scotland is not actually a part of England, I managed to obtain the certificate in question. (The UK verification agent couldn't find my lawyer on the list of English lawyers, for a reason some basic geography makes obvious.)

    This MS Research paper made interesting reading, with a smattering of statistics too: research.microsoft.com/…/sosp153-glerum-web.pdf

Comments are closed.