Slashdot Mirror
Gates Provides Windows Crash Statistic
cybercuzco writes "In an otherwise innocuous article at they NYT (FRRYYY) Bill Gates says that according to error reporting software in windows, 5% of all windows installations crash two or more times every day. Gates goes on to state that Microsoft is looking at charging for some of its software updates that it now distributes for free."
doesn't that give MS an incentive to leave bugs in?
Whenever I close my VB 6 IDE it crashes on my WinXP system, followed by this annoying Bug Report dialog. So, yes, this might have skewed the numbers a bit, but then again it's a MS product :-)
P.S This never happens on my Win2K workstation.
The numbers they quote are system crashes, not application crashes. An operating system that allows a user-level app to cause a system crash is poorly designed. It doesn't matter if the fault originated in the OS itself or not.
Trust the Computer. The Computer is your friend.
And those Macs are running on adverage 24 hours a day whereas the PC's are shutdown every night since they seem to crash less than when we did leave them on everyday.
"Slashdot, where telling the truth is overrated but lying is insightful."
More importantly, how the hell do they keep THAT machine up and running? is it one of the 5%? Bet it ain't 200/0!
It also does not take into account businesses like ours that reboot ALL the NT Webservers once a day to keep them from falling over.
FWIW, they are being replace by a clump of SUN's.
Never answer an anonymous letter. - Yogi Berra
The "10" part is mostly marketing. 10.1 to 10.2 was in no way a mere "point release". Substantial portions of the OS we're rewritten and optimized, plus added a ton of features. Apple doesn't have an obvious page describing just what's new anymore since they're pushing 10.3 now, but the main OS X is loaded with goodies^gpropaganda [1]
Think of Jaguar as OS X v2.0 and Panther as OS X v3.0 and you'll be all right. That makes the current OS version 2.6.
WinXP was only a point release to the "kernel" but XP's userland is (supposedly) significantly differnet. Sadly, Win2K's userland was only really needed a point release, and the kernel needed a thorough overhaul [2]
[1] I just noticed (pause for laughter) that the current technologies page is now highlighting Applescript as a top-level component of the OS, on the same conceptual level as Aqua. Imagine that, an OS that considers scripting and automation to be equally as important as the GUI. That's a nice balance.
[2] Admittedly only in comparison to operating systems which I'd consider well-designed, which would be almost anything.
Veteran, Bermuda Triangle Expeditionary Force, 1992-1951
By the wording of the quote it seems it's talking about "computer crashes" (which I read as "needs rebooting"):
Mr. Gates acknowledged today that the company's error reporting service indicated that 5 percent of all Windows-based computers now crash more than twice each day.
Anyways, i would like to know which percent crashes "only" once each day or once every 2 days... my guess: 50%
I'm a chainsmokin' alcoholic sociopath, so-ci-o-path
Yeah... But.. in windows, the machine manages to hang on the simpliest of errors by other programs. And what probably causes those hangs in the 3rd part vendors? Some of those undocumented hooks into the api which haven't been secured/stabilized/coded correctly at MS. At least in linux/BSD/UNIX you usually know what happened, and have a chance of fixing it. I can deal with popup errors, I just want to still be able to work, damn it! It just comes down to what's best for how one works. And how much one is willing to sacrifice for security and stability. Every OS balances between these three pilars. MS can't seem to get all three legs to balance on the floor. :) And now they want us to pay for the wood filler. :)
-=fshalor
The interesting thing, of course, is that so few bugs have been found. Imagine if M$ had this policy!
for the most part it is sufficent for the average user
More like FreeBSD is WAY TOO MUCH for the average user. I'm talking somebody without a geek guardian angel installing / configuring / administering the machine. If you know a thing or two, great, but I can't see myself calling mom and saying "Yeah, Mom, just use rawrite.exe in the dos window to write the two boot floppies, boot off of them, and down 4.8 RELEASE, as I think you'd like the jail (8) command that they finally backported." My Mom knows how to use her computer now, and I am extremely proud of her (I just convinced her to start outputting in PDF instead of MS proprietary formats) but five years ago she was truly frightened of them. I know many people who are this way now. Can you see anyone but perhaps the 3% even making a boot floppy and installing FreeBSD over the net?
I love FreeBSD. It's absolutely beautiful. However, many people look at it and say "What can you DO with it?" They have to find out for themselves.
Reading the threads sparked by this article, there is quite a bit of misinformation and misunderstanding of how Windows works and what causes crashes. I would like to clear up some of this confusion.
First off, there is quite a bit of confusion about application crashes vs. operating system crashes. While I do not know what Gates was referring to when he mentioned the 5% number, I'm assuming it's an operating system crash.
Application crashes are caused when an application causes an exception and does not handle that exception. (Most frequently, an access violation, error code 0xc0000005.) Ultimately, if the OS cannot find another exception handler that the app has put into place, the operating system invokes the default debugger as the last-chance exception handler. Typically, this exception handler is Dr. Watson (drwtsn32.exe), which will dump the process' address space to the user.dmp file.
The currently installed default debugger (drwtsn32 can be replaced using the aedebug registry value) will trap all unhandled *user mode* exceptions.
Unhandled *kernel mode* exceptions cause KeBugCheckEx() to be called, which is the function that throws the blue screen of death, and writes a memory.dmp to disk (if configured) and reboots the system (if configured). The machine may also be configured to report the bugcheck by sending a 64K minidump to microsoft's OCA site when the machine reboots.
I routinely examine memory dumps to determine the causes of Windows blue screen crashes.
I can tell you with absolute certainty that >90% of the blue screens I examine are caused by non-Microsoft device drivers. When a user installs code into kernel mode, there's nothing the OS can do to prevent that code from taking down the system.
Antivirus software, remote control software, realtime disk mirroring software, and hardware device drivers all install in kernel mode. (Want a list of device drivers running on your system? Run pstat.exe from the Resource Kit and examine the last section of the output.)
Yes, there are many known blue screens caused by MSFT software. To date, Microsoft has done an excellent job of fixing these problems, in my opinion. I have personally witnessed MSFT creating fixes for newly discovered bluescreen bugs in less than a week. (That's less than a week between MSFT getting the call about a blue screen, analyzing the dump, determining the cause of the problem, and delivering a fix to the customer.)
I cannot comment on Microsoft's future plans, since I do not know what they are. But in my opinion, Microsoft has done an excellent job of fixing blue screens caused by its products. And as I've said: the vast, vast majority of blue screens on Windows are not caused by Microsoft code. You cannot blame Microsoft for a device driver written by another vendor that does something that is explicitly illegal (according to the DDK) which therefore brings down the system. (Is it the cop's fault when you're pulled over for a speeding ticket?)
Microsoft's primary problem here, in my opinion, is that MSFT is automatically blamed for all blue screens, when in fact only a tiny percentage of BSODs are actually caused by Microsoft code. If Microsoft could close the loop on OCA and report to the users the cause of their crashes more frequently, and users could begin to appreciate how few blue screens really are caused by Microsoft code, I think the collective opinion of Windows' stability would change greatly.
Just to add value to this post, here are some common bugchecks caused by software. Any kernel mode code can cause these bugchecks:
STOP 0x0000000A (0x0A)
STOP 0x1E
STOP 0x50
STOP 0x7F
STOP 0x7E
STOP 0x8E
And hardware bugchecks:
STOP 0x9C (replace your CPU)
STOP 0x1A (replace your RAM)
STOP 0x4E (replace your RAM)
STOP 0x77 (examine your hard drive system)
STOP 0x7A (examine your hard drive system)
Any STOP code that begins with 0xc....... indicates some kind of environment problem, usually you get these during bootup.