Showstopper chkdsk bug set to derail Windows 7 launch? Hardly.

Earlier today, reports were flying all around the blogosphere about a critical, holy-crap-its-the-apocalypse bug that had been uncovered in the Windows 7 RTM.

The bug happens when running chkdsk - which becomes RAM-hungry under certain specific circumstances, gets all crazy-like, then causes a BSOD (which I argue is more like a feature of Windows than a bug). Chris123NT posted the news yesterday on his blog, but it took a few hours for the sensationalism to begin. A post at InfoWorld said the bug "risks derailing the Windows 7 product launch."

Oh, crap! We're all in trouble! Or are we?

As it turns out, the only way this really qualifies as a "showstopper" is by virtue of the fact that Ed Bott had to stop what he was doing to show people why it's not. Here's a brief summary:

• The bug only occurs when running chkdsk /R on a non-system drive. The /R? That's to recover data from damaged sectors and relocate it.
• That being the case, single-drive, single partition systems (like 90% of those I repair on a daily basis) are immune to the bug.
• To pull off the chkdsk /r you first have to run an elevated command prompt (which most users won't know how to do), then ignore the warning about the drive being locked, then allow the entire check to complete.
• The InfoWorld post admits that the author "did not succeed in causing the systems to "blue screen" as others have reported." System did slow to a crawl due to lack of available RAM, but there was no Earth-shattering kaboom.
• Reports of this happening when a removable drive is inserted have been greatly exaggerated. When Windows asks if you want to scan and fix? Nothing bad happens.

As Ed concludes in his post, "It's alarming behavior if you're unaware of what's happening. But when you look more carefully, it's arguably a feature, not a bug, and the likelihood that you'll ever crash a system this way is very, very small and completely avoidable."

Well put.

Then, Microsoft's own Steven Sinofsky chimed in on the original post with his take:

"In this case, we haven't reproduced the crash.... [T]he design was to use more memory on purpose to speed things up, but never unbounded - we requset [sic] the available memory and operate within that leaving at least 50M of physical memory. Our assumption was that using /r means your disk is such that you would prefer to get the repair done and over with rather than keep working."

What's the bottom line? This an definitely an issue, but one that we'll likely see patched via Windows Update. It's just not the "who forgot to guard the exhaust port" kind of gaff that would cause Microsoft to postpone things at this stage.

Tags: blue-screen-of-death, bsod, bug, bugs, chkdsk, errors, osupdates, windows-7-rtm