Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft Code at Fault for Half of all Windows Crashes

Posted by ryuzaki0 on from the thats-a-lotta-crashes dept.

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'. "

10 of 819 comments (clear)

  1. Uhm, right... by mjmalone · · Score: 5, Insightful

    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
    1. Re:Uhm, right... by TheSunborn · · Score: 5, Insightful

      I think they are talking about drivers. With the current windows design any driver that crash have a good change of taking the os down with it.

    2. Re:Uhm, right... by EnigmaticSource · · Score: 5, Insightful

      ...As with most other 'Modern' OS's... Hell, driver changes on my RSTS/E 10 [PDP-11/79] box would take down the whole system. [[Still having DECNET Nightmares]] Drivers just happen to be one of those things that must be 'just right' otherwise it'll probably take down the entire system for [[what seem to me]] to be obvious reasons.

      --
      The Geek in Black
      I know my BCD's (when I'm Sober)
    3. Re:Uhm, right... by aggieben · · Score: 5, Insightful

      I can attest to this; I was a MS developer in the windows division for a while. I had to do stress testing all the time, and I found it quite common for XP to go days at a time during the stress tests, which I thought was pretty impressive. These tests make the system unusable, as it would with any system, but it didn't crash until it just couldn't allocate one more drop of memory or the disk controller just gave up or what have you.

      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.

      --
      Don't become a regular here, you will become retarded. -- Yoda the Retard
    4. Re:Uhm, right... by Soko · · Score: 5, Insightful

      True enough.

      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

      --
      "Depression is merely anger without enthusiasm." - Anonymous
    5. Re:Uhm, right... by buffer-overflowed · · Score: 5, Insightful

      I've had linux modules fail to load or screw up while loading (custom hardware drivers I wrote for something) and they locked a single terminal/process, w/o affecting the OS. You'd basically have to try to crash the OS to get a module to do so and even then it'd be tough.

      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.

      --
      The key to the enjoyment of pop music is to replace any instance of "love" with "C.H.U.D."
    6. Re:Uhm, right... by passthecrackpipe · · Score: 5, Insightful

      Hrmph. Not withstanding that fact that I use linux on 90% of my machines (i have ten, and 1 is a mac), I would not state that crashing linux is hard work. I have had issues, for example, with a compaq server running KDM, and a connection from a SPARC Debian box to KDM would send the compaq machine in a stupor, with only a blowing fan and slowly blinking numlock led as signs of life. Just one example.

      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... :-)

      --
      People who think they know everything are a great annoyance to those of us who do.
    7. Re:Uhm, right... by DDX_2002 · · Score: 5, Insightful
      The "PE Ponzi scheme"? I hope you're kidding.

      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.

      --
      MHO. YMMV. Any resemblance between this post and real persons, or reality in general, was accidental.
    8. Re:Uhm, right... by danheskett · · Score: 5, Insightful

      However, there are tons of people who enjoy fixing or finding bugs, and provide hundreds of man hours of testing a day

      That isnt always the case. Code can get into the kernel that hasnt been reviewed by anyone for more than a brief few seconds. And after that it can be an indefinite time before that code is reviewed again. If it is sexy code, yeah, it will get seen. If it is mundane, or routine, chances are no one will look at it until they suspect a problem.

      The OSS world is quickly reaching a conclusion. For a long time, stability was how Linux could eat MS's lunch. But I haven't seen a single person who can straight-face deny the marked and vast improvement in MS products stability. They have for years now been systematically refining and improving Windows and including tools and using methods to improve stability and reliability. 10 years ago NT4 was properly laughed for being an instable piece of crap. Now, Win2003 is so much better it is a *rare* company who will stay away simple for reliability purposes.

      The next big battle is going to be security. MS has been working on that too. These are issues MS is working on taking from the OSS world. People ought not count MS out. They are viciously improving thier product and initiating stategies to remove the issue from the table.

      Take this latest MS worm issue. Way less severe than previous issues, much better patch distribution time, and generally a much more smooth operation.

      But back on topic: about your issues with Win2k crashing with certain apps. I have experienced none of what you talk about, but do not be fooled into thinking that other OS's don't have the same problems. Win2k crashing for legacy apps isn't a good thing, but in the end, its pretty acceptabe considering the level of emulation that must take place to run 16-bit real mode code on a 32-bit protected mode OS. I've crashed Linux with dosemu before as a point of reference. Additionally, it is hard for you to know what caused Windows to crash. In essence, an app that is allowed to write data to devices that run in the kernel could potentially crash the system. The same goes for just about all OS's who run drivers in kernel mode (including how most of the Linuxes work).

      Your experience confirms what MS is saying. The applications you consistently run cause Win2k to crash. It is obvious they simply do not function correctly. Bad apps can cause a system to crash on Windows. It is also true that a bad app can cause Linux and *BSD to panic.

  2. Reality Check... by rmpotter · · Score: 5, Insightful

    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?