Some don’t know they can get this information. But even if you do get the information, it’s usually very difficult to figure out what caused the problem. Most of the problems are crashes. Some crashes are easy to figure out because the root cause of the crash is at the same point in the code as the crash itself. However, many crashes are caused by events that happened long before the crash. Those are hard to figure out when all you have is a snapshot of the state of the world at the time of the crash. You can’t rewind to see how you got into the state that caused the crash (the root cause); you can only see the immediate cause of the crash. For example, a program may overwrite some memory that it shouldn’t when you do a copy operation, but it doesn’t cause a problem until some other part of the program looks at that memory, which may happen many, many thousands of instructions later. You’ll see the bad memory in the crash dump, but you won’t know how it got that way so you can’t fix it.
Deciphering these crash dumps is a skill that few people have. Even if a company has someone who can do it, they probably use that person to work on issues that have been reported through tech support rather than using the mechanism built into Windows.
The question in the OP occurred to me yesterday as well. Why does Windows wait until you open Task Manager to check for a solution? Surely, if there were a solution available, the program would not have crashed (or would have stopped hanging) in the first place?
The “solution” is almost always an update to one or more system components or application programs. Once your application has crashed, it’s done. They can’t uncrash it. It wouldn’t do you any good to have them swoop in and automatically provide the solution when Word crashes or hangs. What they look for is a known update to the program or operating system that will avoid the problem the next time.
And it really depends on what you’re doing and why: I notice the success rate is significantly higher on the more common editions of Windows–in particular, XP Professional has about a 30% solution find rate and and Vista/7 Professional can be upwards of 50% (it’s especially good at sorting 32-vs-64bit compatibility issues, because that’s where MS has been focusing a lot of their problemfixing efforts lately)
I’m friends with an engineering manager at MS, and I asked him this very question – “do you guys really look at the crashdumps sent when Windows gets an error and the user reports it?” His answer was, yes, absolutely, they do look at this stuff. There’s groups at MS whose job revolves around tracking these sorts of things, and hopefully solving the problem.
I work at a different software company that does exactly the same thing – when one of our apps crashes, it sends the crashdump to us (after it asks you if it’s okay to do so). We track what apps/components are having problems in the field, keep a database of them, and engineers get assigned to check them out, try to replicate them, etc. I’ve been assigned bugs that read “a user sent in a crashdump, we think X is the problem, please analyze and fix”. So, yeah, companies spend money trying to fix these things, and the reporting mechanism is in fact useful, if not for you then for the next person.
Of course, your only other viable OS options have pretty much the same business plan. So unless you are prepared to write your own perfect, proprietary OS, you don’t have much choice.
I have a problem with the newest version of one of my development tools. They told me that it was an issue with Adobe’s Flash and that I should uninstall Flash and install the latest version.
This did not work.
I eventually had to go back to an older version of the dev tool.
And sometimes Microsoft screws up really royally and makes the system blame a component of yours for crashes that are occurring on systems where your software has never been installed because of a wrong entry in a database … somewhere. And imagine the actual faulting component belongs to software much, much more popular and frequently used than yours, and also crashes a heck of a lot.
Just try reaching someone at Microsoft who can fix that problem.
We finally did, but it took a lot of work, and in the meantime our tiny software company was flooded with angry callers who demanded to know how our component got on their computer (it didn’t). Let me tell you, between a diagnosis result from Microsoft saying it was your company’s fault their computer keeps crashing, and your tech support person saying it’s not… yeah, I got called a liar a lot for awhile.
This is largely true. The information available from Microsoft is pretty limited in scope. We’ve used it from time to time, but generally the vast majority of problems get solved through support channels because we have the ability to correspond with affected users, give them potential fixes, find out enough about their environment to replicate the problem, etc.
Granted, as the makers of driver software, we are a bit of an outlier in terms of the information that’s going to be useful to us.
We’ve used the information from time to time, but it’s not a core part of our process (at least, last I checked). We have limited time and resources, and we try to focus on people whom we know are using the current version and with whom we can work to resolve their immediate need, rather than some random crash that happened to someone at some point months ago who tried our software once with a known problem device on a computer with a massively borked Windows installation.
Whenever I install Windows, one of the first things I do is turn this silliness off. I’d rather just be returned to the desktop than have to press cancel on that “Windows is checking…” message.