Microsoft Code at Fault for Half of all Windows Crashes

Flamester writes "In a ZDNet Australia story, Microsoft is claiming that half of all MS Windows crashes are the fault of third party code, not their own. That is, according to Dr. Watson. The article also goes into the 'rigor in which MS tests their products before release'. "

Comments

John Dvorak has some interesting crash stats...

[sphealey]

John Dvorak developed some interesting stats on XP crashes based on information given in a speech by Bill Gates. He works out that there are 25 millions blue screen crashes of XP per day. Interesting read. Also raises the question of exactly what happens to all those "crash reports".

sPh

Re:Uhm, right...

[andrewl6097]

Actually OS crashes do get sent. When you boot up, xp will recognize that it had just crashed and will offer to send the info.

Re:Uhm, right...

[JimDabell]

So they're saying that a poorly designed application can take down the entire operating system?

I suspect that they are referring to drivers and other kernel-space code. The standard Microsoft weenie excuse for instability in the past has been "it's the drivers!", blaming the video drivers is a favourite.

Remember that Microsoft don't write most Windows drivers, they don't have to because their market share is so great, any hardware manufacturer who doesn't supply Windows drivers is not competitive.

I believe this is the reason why Microsoft introduced their "Microsoft signed drivers" that are supposed to guarantee Microsoft-level stability (!).

However, I have to laugh at Microsoft when they claim 50% of crashes aren't their fault. It's like an advert for a diet pill saying "Doesn't cause death in over 90% of people!".

Re:Uhm, right...

[EnVisiCrypt]

Yup.

I've done an embedded system with QNX, and it is quite the nice RTOS.

Under QNX, the devices hang out in the device manager, which is not in the kernel space, and the drivers are handled by the process manager, also not in the kernel. Since the kernel exists just to pass messages, essentially, it is uncrashable.

Sorry, Mephisto, that's no excuse

[billstewart]

There are different kinds of crashing:

• Individual Apps crashing themselves - that can happen on any OS. It shouldn't happen in major commercial products, but that's reality, and at least most of them are better about saving their state so they fail as safely as possible. I would have said that MS Office is pretty stable about that, except my MS Office has been crashing a lot the last couple of days, and of course there's all the Word Virus and Outlook Virus crap, so maybe I won't say that.
  
• Hardware crashes - Unavoidable.
  
• Crashes related to third-party device drivers - yeah, fine, you can't escape that, but the OS should be designed to minimize the need for drivers and provide mechanisms for isolating them.
• The whole box crashing from applications - There's simply no excuse for this. That's why operating systems have kernels, and hardware has memory protection. Unix could pretty much defend itself from this by what, 1979? It wasn't rocket science like Multics or something. The 8086 memory architecture was too baroque, but the real advantage of all the segmentation stuff was that you *could* use it for memory management. Linus delayed at least one kernel release because a root user who opened a disk drive and scribbled on it _could_ cause the OS to crash. NT 3.5x was pretty safe about this, since it still looked VMS-like inside, but in NT 4 they moved a lot of the graphics capability into the kernel for "speed", and opened up the possibility of crashes again.
• Applications using up some critical resources like disk drive so the machine becomes unusable - yes, this is possible, but the resources that are that critical are very very limited, e.g. a virtual memory system lets you page out or swap out application processes to prevent it.
• Applications crashing some major subsystem that doesn't take down the OS. Unix has this risk - if you hang X Windows or the graphics system, applications that don't use X can still run fine, but you may need to telnet in to restart the subsystem. But this should also be minimized - keeping separate file systems for the OS's use vs. users' applications helps a lot.