Microsoft Code at Fault for Half of all Windows Crashes 819
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'. "
Uhm, right... (Score:5, Insightful)
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.
Headline should be: Microsoft Admits to Testing (Score:3, Insightful)
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.
Uh huh. (Score:4, Insightful)
Re:Uhm, right... (Score:5, Insightful)
A model of closed source (Score:5, Insightful)
Re:Uhm, right... (Score:2, Insightful)
Exactly.
It's nonsense to say that someone elses code is responsible for your OS crashing - if your OS wasn't at fault it wouldn't crash no matter what the third party code did.
Re:Uhm, right... (Score:5, Insightful)
Geez, what a two-sided statement... (Score:5, Insightful)
MS responsible for 100% of crashes (Score:4, Insightful)
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)
Re:John Dvorak has some interesting crash stats... (Score:2, Insightful)
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.
Take your own medicine? (Score:5, Insightful)
Being Picky (Score:3, Insightful)
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.
Re:Uhm, right... (Score:5, Insightful)
Re:Uhm, right... (Score:5, Insightful)
Also, while looking over bugs in the database they keep, there were vastly more bugs filed as a result of a poorly behaving 3rd party application than because of the windows code itself. Also, most of these didn't cause crashes. XP does a pretty nice job of handling application crashes gracefully. All of this is from inside professional experience.
My personal expericence (e.g., outside the MS environment) has been than XP is as stable as any other machine I've got at home (Gentoo Linux, OpenBSD). In 2 years time, I've only seen 1 blue screen of death, and I've been using many different computers using with XP on them and I've installed in many times over that two years.
MS does do a good job of testing their windows code (can't speak for office --- those nerds need to learn a thing or two about threads and finally put clippy out of his pathetic misery). They test their code far more thoroughly than ANYONE who does open source including Red Hat, IBM and others.
Of course, all of this is not to be a MS zealot because that's not what I am. I'm much more of an OpenBSD guy. It is, however, to make this discussion a little more fair by sharing my inside experience and knowledge.
Re:Uhm, right... (Score:5, Insightful)
Unfortunatley for Microsoft, they allow 3rd party drivers into kernel space, even if that driver has never been seen by a Microsoft employee. That is likely what he's saying - "We provide the means to have your code not fuck up our OS, and half of you don't do it!".
The hardware/system drivers are allowed into kernel space after a user clicks a window that basically says "Microsoft has never seen this driver before - it could blow up your system. Want me to install it anyway?" and the user usually says "Yup, no problem. Them programmers are sooo smart...". It's very much a parallel argument to Windows Security - expecting everyone to know how to be a sysadmin without being a sysadmin.
If MS should learn anything from Linux development, it's that free, on-line and open collaboration breeds better drivers and a more stable OS.
Soko
Would you name this OS? (Score:5, Insightful)
Only Half? (Score:3, Insightful)
Nice headline (Score:2, Insightful)
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.
Re:Uhm, right... (Score:5, Insightful)
Windows' Problems run deep, very deep, and they won't be fixed w/o a complete rewrite. Drivers should not be able to take down the OS, but in Windows they can because of the Windows Paradigm.
Typical /. (Score:1, Insightful)
Re:Clarification of 'test' (Score:3, Insightful)
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.
Re:Uhm, right... (Score:2, Insightful)
A load of BS (Score:3, Insightful)
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.
Re:MS responsible for 100% of crashes (Score:2, Insightful)
Hmmm...lets see.. (Score:3, Insightful)
So what were we saying again...
Re:John Dvorak has some interesting crash stats... (Score:3, Insightful)
The user (Score:2, Insightful)
Win9x or WinNT? (Score:2, Insightful)
Get a Mac! (Score:1, Insightful)
Re:Well, it's the same in Linux (Score:4, Insightful)
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?
Interesting article (Score:4, Insightful)
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.
Re:John Dvorak has some interesting crash stats... (Score:2, Insightful)
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.
Re:Uhm, right... (Score:5, Insightful)
Every OS can be crashed, and Linux is not significantly harder or easier. It is just that with Open Source, world+dog will see what a tremendous asshole you have been, writing buggy code like that. Now, when coding proprietary stuff at work, you can probably get away with it, shifting the blame on your sacked co-worker, or coming up with a rather technical explanation of the situation to a boss that is probably clueless anyhow. With open source coding however, there are no excuses, and people will just start laughing every time you log on to IRC. You nerd-chick will stop writing you sexy emails and naughty, compromising emoticons, and you'll basically be branded a wannabe MCSD. Nobody would want that to happen, so the motivation to write good code is clearly present and persuasive with open source code...
Reality Check... (Score:5, Insightful)
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.
Re:Uhm, right... (Score:1, Insightful)
As well, what about all the CNE's? Or CCIE's? Slam them all down if that's the case? Oh, and what about Train Engineers? Those guys that drive the trains?
From Dictionary.com
*One who is trained or professionally engaged in a branch of engineering.
*One who operates an engine.
*One who skillfully or shrewdly manages an enterprise.
What about Genetic Engieers? According to the PEO site you will be CRUSHED for the impudence!
Now, that said, I'm not saying that MCSE's should use the term Professional Engineer. But then should the PEO (and other bodies) call up websters and say to them, 'Oh! You need to change your definition of the word to include this?'
I'm an MCSE, and worked my ass off for it. Spent a year in class TCP/IP DNS (protocol list up the wazzo) fundamentals and then working specifically with the OS to earn my Cert. I didn't braindump and hate all the buggers who do so. But the fact is, Until I get a letter from the PEO or M$ saying that I can't put on my resume that I am a Microsoft Certified Systems Engineer, I will continue to do so. Then if the PEO decides to take me to court, then perhaps we'll see if M$ is going to stick by the people who worked for their Certs.
This is my first post on Slashdot, (long time Reader) and I know that I'll probably be flamed by those who know better than I. But this was something that I Felt strongly enough about to say something about.
~DU
If it's ATI, it *is* the video drivers! (Score:4, Insightful)
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.
Re:Well, it's the same in Linux (Score:4, Insightful)
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.
Re:Uhm, right... (Score:5, Insightful)
Out of all the professions, engineers have the ability to kill the most people in the least amount of time through incompetence. A doctor can only kill one patient at a time, a lawyer can only get a handful of co-defendants on death row at once, and an accountant can only kill people if they jump out their window because of his bad advice. But, a guy who is an "engineer" and doesn't know hiw head from his ass can design a house/dam/building/bridge/etc. that can kill rather a lot of people. And those people probably weren't the ones who hired the engineer, so they don't really have any way of knowing what his credentials are when they decide if they want to use the bridge, live near the dam, etc.
Speaking of Which (Score:4, Insightful)
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.
Re:A model of closed source (Score:3, Insightful)
Comment removed (Score:5, Insightful)
app crashes ARE the OS's fault (Score:4, Insightful)
What scares me here... (Score:2, Insightful)
Re:You Mean The Glass Is Half Full? (Score:1, Insightful)
Re:Uhm, right... (Score:3, Insightful)
Besides, good code is an art form. It requires flashes of inspiration, attention to detail, insight, a willingness to think outside the box, etc.
A better term for what most MCSEs are would be "technician", not "engineer", but that just doesn't have the same oomph to it, and M$ wouldn't be able to sell it for as much coin.
Re:Uhm, right... (Score:3, Insightful)
You may have worked for MS and known what kind of testing they do, but nowhere in your post do you claim to have done the same at RedHat or IBM. How, then, can you make such a claim?
In all fairness to Microsoft, I am fairly certain that Microsoft employs more test engineers directly then Red Hat employees engineers total. It is not completely logically rigorous to therefore conclude Microsoft necessarily does more testing in terms of man-hours (need a few more statements), but it's a fairly safe conclusion.
But the compairision is not "fair" because the Linux folk share testing, while Microsoft is responsible for their own. A bug found by a Red Hat engineer or user is frequently in the "upstream package" (at least, that's the term Gentoo uses; I don't know how universal it is), that, when fixed, will propogate back down to all Linux distributions sooner or later.
In truth, I'd submit there's no way to "fairly" compare the testing the two groups do; it's just too different. All I can say is while it is again not necessarily a logically rigorous thing to say, it's safe to say that Open Source is indeed tested quite thoroughly on the ground that all insufficiently tested software is basically a seething mass of bugs, quite a bit of Open Source software is not a seething mass of bugs, therefore, quite a bit of Open Source software is sufficiently tested. Through what means, in the end, doesn't matter to the end user terribly much.
Asking for justification of the claim is a fair challenge, though; this message is not meant to imply otherwise.
Re:Uhm, right... (Score:3, Insightful)
Re:Uhm, right... (Score:5, Insightful)
It would have taken only a small team of Microsoft programmers to develop a useful bundle of fundamental hardware tests for their beloved operating system. How hard is it to have the OS test basic functions, like RAM, the PCI bus, the IDE bus, etc.? For Solaris, Sun puts a CD with their VTS software in the box set. Does Microsoft have fewer resources than Sun?
Re:Uhm, right... (Score:3, Insightful)
Re:Uhm, right... (Score:5, Insightful)
They're also the ones who can either sit back an do nothing about environmental degradation, which will end up killing us all, or pass sometimes-unpopular laws and/or try to educate the public.
Re:Uhm, right... (Score:2, Insightful)
Re:Uhm, right... (Score:1, Insightful)
If Windows NT-derived operating systems were designed right, the only thing that should crash them is faulty device drivers or other kernel-level code. But it's applications that are crashing Windows. This doesn't happen with Macs. This doesn't happen with Linux.
Re:Uhm, right... (Score:3, Insightful)
Second the worm that is out there has a lot of flaws itself and causes machines to crash and reboot, mitigating the damage.
Third, it has no malicious payload. If it did the general populace would be in a world of hurt.
Yes, Windows is more stable than it has been in the past. Yes, MS is also making some improvements in security. But this worm is no barometer of either.
Re:Open Source, Closed Source, Not the Problem (Score:3, Insightful)
One fundamental design flaw in Windows is that it decides if a file is executable based on its name. If it ends in
Unstable! (Score:3, Insightful)
--grendel drago
Re:Would you name this OS? (Score:1, Insightful)
Re:Reality Check... (Score:2, Insightful)
Did he have Automatic Updates enabled? Did he allow the updates to install or did he ignore them as I've seen so many people do?
Consider: If (and it's a big IF) most of the world were running various distributions of Linux, and users were faced with a remote exploit, Red Hat, Debian, SUSE, et al would have to quickly develop, test and distribute patches. Would the uptake of these patches be better than Windows Update? I doubt it. Note that even the FSF was not able to patch in time to avoid an exploit -- and it took them over 4 months to discover they had been compromised: http://ftp.gnu.org/MISSING-FILES.README [gnu.org]
Is that clear enough for YOU
Re:Uhm, right... (Score:3, Insightful)
The funny thing is, the first models sold would be to hackers trying to port it to BSD or Linux. Just the very IDEA that MS would try to make a box "MS only" would force them to port it: Like moths to a candle. There is no reason to make a MS ONLY box unless it is cheaper, which is another reason the hackers would be trying to port it. The other, of course, is because it would irritate bgates.
Don't think so? Ever heard of X-box? A MS only box, with all the Palladin etc. you want, would create yet another "$10,000 to the first person who can boot linux and document it to be recreated" contest.
Show us the Source then (Score:2, Insightful)
Re:Uhm, right... (Score:2, Insightful)
It's really just silly... Yes, the KERNEL may be (essentially) uncrashable... But, who really cares? The system, as a whole, is most definitely NOT... I've written lots of code for QNX, and I assure you I've seen it crash (and, caused it to crash) on many occasions... People who tout the supposed benefits of this microkernel approach are really beeing pretty obtuse... You're not solving the problem: you're just shifting it elsewhere... There's still some core set of services which are vitally important to the continued functioning of the system, and if you manage to crash those (be they in user space or kernel space), the system becomes unusable... Sure, putting SOME things into user space may make a lot of sense... Drivers for crap you can easily do without, and still carry on... But, important stuff (like QNX's "Proc", "Dev", etc.), it doesn't make a whole lot of difference whether they're in kernel space or user space; lose them, and you're dead, either way...