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'. "
So they're saying that a poorly designed application can take down the entire operating system? The OS should be resilient enough to handle application crashes and keep on running, who cares who causes the crash? It's the OS's responsibility to handle it.
Also I would like to see where they got these numbers? If they are using the new 'feature' that notifies microsoft of application crashes then I'd be skeptical... If the OS crashes then the notices won't be sent to Microsoft.
Also, it is likely that MORE than half of the applications run on a Windows box are non-microsoft applications, that would mean that statistically MS apps crash more often than third party apps.
Visualize the world of wine
Microsoft emphasised that products such as Yukon and Exchange Server were undergoing thorough testing -- both internally and via independent third parties -- prior to their release to the market.
Hey, they're TESTING! Wow, they really are taking this trustworthy computing thing seriously. Mr. Chase may have said a similar thing if he hadn't been comped, as reported in the diclaimer at the bottom of the article:
Brendon Chase travelled to Tech Ed as a guest of Microsoft.
Hardhitting journalism.
I'm much funnier now that I'm a subscriber.
That sure is encouraging. What a wonderful operating system you have when half the time it crashes, the crash is caused by third party code. A properly designed OS shouldn't allow third party software to crash it. No OS is perfect, but half the time is just silly.
Assuming this is true, wouldn't this be an example of how closed source can contribute to programming mistakes? If developers had more access to the OS source could wouldn't they be less likely to affect it adversly with bad code?
UNIX/Linux Consulting
What he just admitted is that HALF of ALL crashes are Microsoft OS related. Every application that runs on a account for more than let's say 5% or 6% of total crashes, but Microsoft still has their full 50% share. That's STUPID-speak on his part. Way to instill company pride by shooting yourself in the foot, and then putting it in your mouth.
-Christopher Wu
http://www.christopherwu.net/
There is only one way 3rd party software can crash an OS: If the OS is so hopelessly broken that it gives that much control to applications.
Microsoft's bad coding is responsible for 50% of their crashes, by their own admission. Their inherently flawed OS structure is responsible for allowing the other 50% to happen.
(This of course doesn't address hardware related issues--all I can say is that MS software is VERY sensitive to borderline hardware)
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Gates said that 5 percent of Windows machines crash, on average, twice daily. Put another way, this means that 10 percent of Windows machines crash every day, or any given machine will crash about three times a month. Since Bill is a math junkie, I have to assume this number is real and based on something other than a phone survey.
Nice one there, John. Bill Gates might be a math junkie, but it's obvious you're not.
"Empathise with stupidity, and you're halfway to thinking like an idiot." - Iain M. Banks
Scott Charney, chief security strategist at Microsoft, told developers at the TechEd 2003 conference in Brisbane, that information collected by Dr Watson, the company's reporting tool, revealed that "half of all crashes in Windows are caused not by Microsoft code, but third-party code".
It's worded suspiciously but I don't think necessarily means the crashes are due to windows code. Aren't hardware issues responsible for a significant amount of crashes as well? Are they being counted in the 50% that belongs to driver problems and other third party code or are they counted with the windows problems.
I stole this Sig
I'm currently using Linux, which also gives drivers such low-level access that a bad driver can crash the whole machine. I was under the impression that this was a design decision which couldn't be changed without sacrificing performance.
Ok what about the other half that they are responsible. Never mind the fact that a application should not crash the OS.
Got Code?
I know I'll get modded WAY the fuck down, but I don't care...
This whole thing is flamebait. The article title "Microsoft Code at Fault for Half of all Windows Crashes" should have been "Thrid Party Code at Fault for Half of all Windows Crashes"...or is it that only anti-MS articles get posted? So much for having any integrity, Slashdot.
The headline has been twisted to suit the audience
Having been doing software testing for about 10 years now, I can pretty much guess that Microsoft is like most other software places in that lots of things are discovered in test that still make it out the door. I'd like to hear from someone in the test organization at Microsoft to see what *they* think about the quality of the product they test, and how much pull they have in making decisions. I am betting that it is just as much as anywhere else. Most places have no problem in shipping out code that doesn't meet with QA's approval. I've seen it, I've been a part of it. That's business baby. Quality software will get trumped by some promised deadline every time.
My beliefs do not require that you agree with them.
Uhm, anytime Windows crashes, it's a problem with Windows. A bug or crash in a 3rd party application should have no bearing on the stability of Windows, at least that's how MS Marketing describes Windows capabilities, and that's the way it should be.
This looks like a big verbal foo-pa that IBM/Sun could drive a truck load of marketing through.
If we were to assume there are close to around 50,000 third party firms who develop for Windows and there are around 1 million distinct Windows core dumps per version then there would be 20 incidents per third part developer and HALF A MILLION Crashes thats still owed to Microsoft..
So what were we saying again...
Rapid Nirvana
Yes, but unfortunately John Dvorak is a fucking moron .
My only political goal is to see to it that no political party achieves its goals.
still experiences 100% of all failures.
Oh well, what the hell...
Big difference.. I would say 99.9% of all crashes in Windows 9x are Microsofts fault. NT,2k,Xp,2k3 are FAR more stable.
With the numerous posts about drivers and hardware really causing all the crashes, it makes one think that maybe the hardware maker should also make the OS. hmmm. Doesn't some other company already do that?
Because only "weenies" make excuses for their vendor. I've only ever seen the excuse as a response to somebody complaining about Windows instability - whether it's Microsoft's fault or not is irrelevent if it's stopping you from getting your work done.
I dare say it is, but what does Linux have to do with it?
I'll probably be modded off-topic, since a story like this on Slashdot is nothing more than MS-bashing flamebait, but I'll try anyone.
First of all, the article says "crashes in Windows," not "crashes of Windows." So it's not entirely clear to me if they are counting application crashes which don't impact the whole system or just the ones that bring down the OS (as most of the bashers in this thread seem to think).
Second, if this is based on error reports, it's skewed by a lot of things. For example, I send the reports when I suspect it's MS code at fault, and I don't send them when I suspect a third party app. I figure MS can't do anything about the third parties, so why bother. The point is, lots of things can skew these numbers.
But most importantly, the bulk of the article, which most Slashdotters seem to be ignoring, is about tracking root causes of bugs. There is no silver bullet in software quality, but this approach is a good place to start. It's something that should be taught in CS courses, and it's something we experienced programmers should be training our juniors to pay attention to.
When you fix a bug, do you ask yourself how it got in there? Where else in your code a similar bug may appear? How can you avoid making the same mistake in the future. How you could have detected the bug sooner? How did the test cases miss it? These are powerful questions if you take them seriously.
It's a mindset all programmers should have. Ironically, I learned it from a Microsoft book, Writing Solid Code by Steven Maguire. Buy it, read it. Pass a copy onto your peers.
What you're missing is, that Bills statement was only about Windows-installations (worldwide) that crash (averaged over their lifetime/uptime) more than twice daily. We don't learn anything about the percentage of Windows-installations that crash 1-2 times per day or less than once per day (averaged) e.g. how the other 95% of Windows installations behave. They may crash never, or they may crash (on average) just a little less than twice daily. Of the 5% we only learn that they crash at least twice daily, some of em might crash every few minutes.
.1 (10% or 2*5%, whatever) is only a lower estimate that could only result if the 5% crash twice daily (but no more) and the other 95% never crash.
So your calculation that Windows-installations times
Also note that this is a worldwide statistics over all Windows-installations. The instable systems may be badly configured or run on bad hardware, we just don't know. But some big business setting up their desktop- and server- installations carefully and on stable hardware might not have such problems, their Windows-installations might crash never or at least (on average) less than once daily. Indeed it can be expected that a bunch of similarly configured systems exhibit similar behaviour and that a good systems administration takes care of those systems that crash too often and reconfigures, repairs or replaces them.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Um... where in the article does it say 3rd party code brings down the WHOLE O/S? In my experience the robustness of Windows has improved dramatically with every version (nevermind ME :-) I see individual applications crashing -- about 2 or 3 times a month. In fact, I typically go weeks and months between reboots (generally only when applying patches). There are plenty of things not to like about Windows, but the bad days of blue screens is a fading memory. Of course there are exceptions for odd hardware configurations and out-of-date drivers, but I've seen the same or worse problems with Linux support for oddball hardware.
BTW -- you may have noticed that sometimes when an app "hangs", and displays a "not responding" message in Task Manager, it is actually still running just fine (though chewing up a ton of CPU). Depending on the problem I may wait it out until the process finishes or simply kill it. One of my gripes with MS is that sometimes I have to use a third-party tool (sysinternals.com) tool to kill runaway processes -- Task Manager is not always able to kill it. Not perfect, but it works.
I think all of this applies to Windows server configurations also. I run IIS/ASP servers with dozens of users and applications. When configured so each account runs in its own memory space, with CPU utilization limits, NOBODY is able to bring down the whole web server with bad code -- just their own site.
The fact is, most of us are so bigoted about our O/S of choice, we are unwilling to learn enough about the "enemy" to use it properly.
Is this sig nificant?
The standard Microsoft weenie excuse for instability in the past has been "it's the drivers!", blaming the video drivers is a favourite.
Unless it's an ATI product, in which case you can be 100% assured that it *is* the video drivers.
In my experience, you can bring any Windows 2000 or XP machine with any model of All in Wonder to a screeching blue HALT by simply doing such outlandish and unreasonable things as
And for those who really like fun, try an ATI All In Wonder Pro on Windows 2000. A couple of years ago, I deployed a couple of hundred of them at a Toronto TV station. A year later, they asked me to upgrade all their systems to Windows 2000. Constant random lockups of the whole system, requiring not just a reboot but a power cycle. Needless to say, they were not very pleased - you spend $300 on a video card, and you kind of expect that they'll provide drivers for at least a couple of years. ("They've been around forever. Besides, they're a good hometown company! Their headquarters are just 5 minutes from here, up the 404 in Markham."). Their news department almost did a story on crappy software but it was vetoed because news is supposed to be impartial.
As for ATI, I will never buy another ATI product ever again, for myself or for anyone else.
Fire and Meat. Yummy.
It's a weenie excuse either way, for sure. Who cares about excuses, we don't want excuses, we want the damn thing to work.
And it's perfectly true you can run into the same problem with Linux if you use proprietary drivers so in that case there's something you can do. Don't use those drivers. Don't buy hardware that requires them. Fund development of open drivers. You have lots of options to make the damn thing work. I don't use proprietary drivers in Linux, and I've never seen it crash except when hardware failed.
With windows you don't have those options. Even if you're picky about your hardware it will still crash. And, btw, the crashes the article was talking about were not limited to, and quite possibly didn't even include, those caused by drivers.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Computers are so comparatively powerful now, we can afford to trade time performance for stability.
Drivers should be moved out of kernel space where possible. Even then, with some effort it could be up to the admin whether drivers run at kernel level or at user level.
.sigs are for post^Hers.
If any non-kernel, non-driver code causes the OS to crash, then that *IS* the fault of the OS. Hands Down. A good OS should be able to survive accidentally bad (or even maliciously bad) application code.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
is it appears MS is proud of this percentage. Along the lines of "only half the total failures of our software are our fault" so look how good our product is. After this many years I really expect to hear that 90% of crashes are due to third party code and that Windows is finally what has been promised for all these years. No question XP has lived up to a lot of it's promise, but it's more than obvious security and stability have miles to go. This is just plain sad.
This likely underestimates the responsibility of MS as probably 80% of the errors of third party software are due to a lack of adequate consistant correct unambiguous documentation or operation of the software to that documentation. This is a problem of a closed system. Having tracked down many MS errors (this is the main job of a MS developer), this is a low figure. Also, many companies consider MS quality sufficient and consider schedule and dollars coming in more important anyway so they are unlikely to improve beyond this level.
One fundamental design flaw in Windows is that it decides if a file is executable based on its name. If it ends in
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Yeah, but that was an unstable release. (2.1.something.) It's equivalent to an internal beta of Windows---why on earth would you run it on a production system? The unstable series are for testing, not for running on a system you're not willing to fry!
--grendel drago
Laws do not persuade just because they threaten. --Seneca
Ah, gee. And no wonder. That would make sense that so and so a percentage of crashes is caused by third party software because MS doesn't provide the info to software developers which they need to make their software work like it's meant to on windows. That point was mentioned in 'The Court Case' and hasn't really changed, to the best of my knowledge, since.