Print 164 comment(s) - last by Smilin.. on Aug 11 at 6:17 PM

Just when it looked like Windows 7 was clear to sail to market, a catastrophic bug has been found. The bug reported can blue screen the OS and may result in a delay of the release date. Thus far Microsoft reportedly claims it to be a chipset drivers issue, but testers have found the bug also occurs in VMWare.
Microsoft insists its not to blame

Aside from a minor squabble about the User Account Control's security settings, that it later relented on, Microsoft's Windows 7 beta and release candidate builds have met with little criticism and plenty of praise.  The builds have offered performance surpassing Windows Vista noticeably, while at the same time improving further on Vista's level of graphical polish.  And notably they have been seemingly free of almost any show-stopping bugs.

However, Microsoft is now in code-red panic mode as a major bug has been found in Windows 7's RTM build, one which threatens to kill the OS's release party.  The RTM build -- 7600.16385  -- thus far only received by a handful, features a reportedly massive memory leak in the unassuming, but frequently used program chkdsk.exe.

When scanning a second hard disk (a non-boot partition or second physical drive) using the "/r" (read and verify all file data) parameter the utility starts to leak memory like its a monsoon and quickly runs up a high enough memory debt that it blue screens and crashes the system, according to some (others merely report a memory usage of around 98 percent within seconds, but without the legendary "blue screen of death").

The bug has been confirmed on many different hardware setups --it's been verified to occur on everything from a Intel Atom-based netbook running the 32-bit version, to a Intel Core 2 Duo notebook running the 64-bit version, and a VMware Workstation 6.5.2 virtual machine running the 32-bit version.

Explorer.exe, which runs the utility does not release the excessively large amounts of memory it gobbles up, compounding the problem. 

Microsoft is reportedly trying to avoid claiming responsibility, blaming the problem on chipset driver issues and telling users to upgrade their firmware.  Yes, that makes absolutely no sense, considering the bug has been verified to exist in VMware.  However, that's the current stance Microsoft is reportedly taking.

One painful option for Microsoft is likely to delay the release of Windows 7.  Given that Vista doesn't have the bug and it seems to be an underlying file system issue it could take a substantial amount of time to fix -- file system corruption issues in Windows Home Server went unresolved for months.  A delay of Windows 7 could help give competitors like Apple and Google steam, but it would at least spare users of the dangers of this critical error.

The other main alternative is to release Windows 7 broken in hopes of fixing it in the near future.  However, this would essentially kill any prospects for IT adoption.  Further, the new OS would have an easily exploitable security hole -- just gain access to a Windows 7 system as a standard user and run the utility to crash the system with ease.

A final rather unlikely possibility is that Microsoft will be able quickly (within the next week or two) find and fix the problem, without having to delay its release or ship broken code.  However, this seems rather unlikely, especially considering Microsoft reportedly says that it has been unable to duplicate the problem and is stick to its belief that faulty hardware is to blame.  The longer it sticks with this line of thinking, the longer the OS will likely be delayed.

Comments     Threshold

This article is over a month old, voting and posting comments is disabled

Too Late To Delay
By TomZ on 8/6/2009 11:09:49 AM , Rating: 2
I can't believe they would delay the release - it is literally all done and ready to release to MSDN.

RE: Too Late To Delay
By TomZ on 8/6/2009 11:19:16 AM , Rating: 5
RE: Too Late To Delay
By mikefarinha on 8/6/2009 11:27:17 AM , Rating: 5
Wow, and I thought this non-news item was relegated to the bowls of tech journalism. Why did it get repeated here on DT?!?!

This is a non-issue at best, a bad Intel driver at worst.

RE: Too Late To Delay
By mikecel79 on 8/6/2009 11:34:39 AM , Rating: 5
Because DT loves to take a day old story slap a sensational headline on it and call it news.

This was just sloppy journalism. If Mick did any research on this he would have seen the comment from Sinofsky already. And let's get a reality check, this isn't a showstopping bug. The amount of people this will affect is miniscule.

If anything a hotfix can be pushed out through Windows Update and OEMs can apply the fix before Windows 7 PCs go on sale on Oct 22nd.

RE: Too Late To Delay
By JasonMick on 8/6/09, Rating: -1
RE: Too Late To Delay
By TomZ on 8/6/2009 11:47:45 AM , Rating: 4
However, there is a possibility. And any time one of your common programs essentially kills your OS, I would say you have a critical error.
As long as Windows Update is working, there's no such thing as a critical show-stopper error.

RE: Too Late To Delay
By CollegeTechGuy on 8/6/2009 2:21:08 PM , Rating: 5
Where is the Article Not Worth Reading button???

RE: Too Late To Delay
By TomZ on 8/6/2009 2:29:53 PM , Rating: 5
Unfortunately the merit of an article to the site owner is the number of page views, not the quality of the article. And so both good and bad articles "succeed" from that perspective.

RE: Too Late To Delay
By DOSGuy on 8/6/2009 6:57:57 PM , Rating: 5

RE: Too Late To Delay
By Omega215D on 8/7/2009 3:28:17 AM , Rating: 4
If this were slashdot Mick would be considered a hero and a "defective by design" tag will be assigned to it. And those at slashdot claim themselves to be geeks...

RE: Too Late To Delay
By DigitalFreak on 8/6/2009 11:49:24 AM , Rating: 5
You are becoming a laughing stock, Mick. First you post entirely bogus graphics in one of your global warming articles, then change them without any acknowledgment when posters call you out on it. Now you're posting this crap without doing any research. I sincerely hope you don't call yourself a journalist.

RE: Too Late To Delay
By bubbastrangelove on 8/6/2009 12:50:31 PM , Rating: 5

RE: Too Late To Delay
By niva on 8/6/09, Rating: 0
RE: Too Late To Delay
By TomZ on 8/6/2009 2:09:02 PM , Rating: 5
It speaks to the credibility - or lack thereof - of the author.

RE: Too Late To Delay
By mckinney on 8/6/2009 9:07:35 PM , Rating: 3
To me, the problem with Daily Tech is that your dont know who writes what until you click the link.
Why doesn't Daily Tech just put the name of the author in the title on the main page?
That way, wouldn't you know which author (or articles) you didn't want to read?

RE: Too Late To Delay
By clovell on 8/6/2009 11:50:35 AM , Rating: 5
You hope, Jason? FFS, dude - they already said they're working on it. no need to hope - it's being taken care of.

Everybody chill.

RE: Too Late To Delay
By Sazar on 8/6/2009 2:01:43 PM , Rating: 5
Considering that Windows 7 has already been released to MSDN (it's in my updates list and is marked 08/04 for the updated date), I think Mick should probably update the article and say "NO DELAY, ALREADY RELEASED" so there is a lesser semblance of fear-mongering :)

RE: Too Late To Delay
By Pirks on 8/6/2009 4:50:15 PM , Rating: 2
Mick should probably update the article and say "NO DELAY, ALREADY RELEASED" so there is a lesser semblance of fear-mongering
Yeah? And less clicks generated because of normal not crazy-Mick title? FOR.GET.IT. Mick also wants to eat, you know.

RE: Too Late To Delay
By B3an on 8/6/2009 6:57:25 PM , Rating: 4
I think Mick should just get another job. Or go work for so called "tech news" sites that pump out this kind of cr*p daily, like TheInquirer.

RE: Too Late To Delay
By crystal clear on 8/6/2009 8:36:13 PM , Rating: 4
A good day for Apple - No Apple bashing today as che readers are busy bashing Jason !

An apple a day keeps the pink slip away !

RE: Too Late To Delay
By Akrovah on 8/6/2009 12:04:10 PM , Rating: 3
While I'm not sure I believe MS's line about it being hardware or driver related, how does the fact the it happens on VMWare disprove the claim? VMWare uses emulated hardware, which introduces a whole different set of problems from real hardware in addition to the problems of real hardware itself, and drivers to run this emulated hardware. It seems you are implying that VMWare's software is perfect.

If this is a hardware/driver issue, then the emulated hardware and driver for it may very well have whatever bug or fault that causes it.

RE: Too Late To Delay
By omnicronx on 8/6/2009 12:42:07 PM , Rating: 3
I agree, I still don't see what VMware proves in the slightest. VM's Chipset driver emulation could have the exact same issue as the host drivers.

RE: Too Late To Delay
By BaronMatrix on 8/6/2009 12:42:16 PM , Rating: 3
But if you look closely at the DevMgr in VMWare it uses generic drivers, not the Windows drivers. It was usually S3 graphics, Intel NIC, Standard HDD CTRLR.

Not saying it's not a bug, but I worked in the Windows division and know how bad A LOT of 3rd party drivers were.

That's one of the main reasons for User Mode drivers in Vista.

RE: Too Late To Delay
By mikefarinha on 8/6/2009 12:55:18 PM , Rating: 5
There are two things going on here.

1. The new chkdsk /r function consumes extra ram to complete the task faster.

2. A few people have had BSODs when doing this.

The problem with Randall's article is that he says these two issues are one in the same. That the high memory usage is something that eventually leads to BSOD, however he also admits that he wasn't able to BSOD any of his machines.

Then Sinofsky chimes in and says that the high RAM usage is by design to speed up the scan and reduce disk thrashing.

So if you remove the high memory usage as being an issue then only a few users are actually having a BSOD problem.

The BSOD problem could be a number of things. Some people have mentioned Intel drivers to blame, however some people have postulated that it is bad RAM to blame. If you have faulty RAM problems might not show up until you put a big enough load on it.

The actual number of people that have had the BSOD is too small to use to pinpoint any specific problem.

RE: Too Late To Delay
By segerstein on 8/6/2009 4:48:46 PM , Rating: 2
Come on! Chkdsk.exe is a small userspace command line utility. It would be dangerous if it corrupted data. But it doesn't. Furthermore, I cannot recall when I last used it with /r parameter.

RE: Too Late To Delay
By mindless1 on 8/7/2009 2:20:08 AM , Rating: 3
1. There is obviously a flaw, it should never consume THAT much. It was terribly coded to not have built-in memory limits as that should always be at the forefront of any design change. I am not jumping on the "show stopper" bandwagon though, it is simply one of many bugs that any new OS will need to have fixed as quickly as reasonably possible.

2. That Explorer doesn't release the memory is troubling. It is fortunate most don't seem to BSOD, and I don't know that it is so necessarily important whether both issues are the same. If excess memory is taken, and especially if explorer won't release it, that is almost as bad from my perspective on a client system (not counting server 2008 which seems effected too) as the system still has to be locally rebooted to regain the memory to continue use of the system.

If on the other hand it had bluescreened, who starts a chkdsk in the middle of a critical operation on the system that would be disrupted? I can accept some people might but I don't feel whether it bluescreens is necessarily important, either way it substantially effects the system use, regardless of who is at fault.

I've never liked hard release dates and do think the OS should be held back, consider why this bug was found, that finally more and more people are poking all the buttons and finding the bugs which we can have fixed by a delayed release date instead of some of the more major things as added on patches.

Patches are inevitable but until there is a userbase reasonably "needing" to keep using a system running an OS they had a reasonable expectation of depending on (which category Win7 does not yet fall into), the rush to get it to market should be tempered by the benefits of it being as tested as possible and quite simply, having it out in the wild for millions of geeks is a great way to test and improve the final shipping product.

RE: Too Late To Delay
By mikefarinha on 8/6/2009 12:56:16 PM , Rating: 3
There are two things going on here.

1. The new chkdsk /r function consumes extra ram to complete the task faster.

2. A few people have had BSODs when doing this.

The problem with Randall's article is that he says these two issues are one in the same. That the high memory usage is something that eventually leads to BSOD, however he also admits that he wasn't able to BSOD any of his machines.

Then Sinofsky chimes in and says that the high RAM usage is by design to speed up the scan and reduce disk thrashing.

So if you remove the high memory usage as being an issue then only a few users are actually having a BSOD problem.

The BSOD problem could be a number of things. Some people have mentioned Intel drivers to blame, however some people have postulated that it is bad RAM to blame. If you have faulty RAM problems might not show up until you put a big enough load on it.

The actual number of people that have had the BSOD is too small to use to pinpoint any specific problem.

RE: Too Late To Delay
By Bender 123 on 8/6/2009 2:41:17 PM , Rating: 2
I agree, the only BSODs I have gotten from 7 have been my own doing, a weird software induced BSOD from Handbrake and AnyDVD, or specifically inducing one. I cant get this one to work...I got it once, by pure random chance, out of about 20 attempts.

RE: Too Late To Delay
By mikefarinha on 8/6/2009 12:14:25 PM , Rating: 4
Yes I'm calling Randall Kennedy a liar... if by liar you mean someone that spouts off half-truths to create misinformation for his readers.

And I'd say the same thing about Dvorak.

RE: Too Late To Delay
By Smilin on 8/6/2009 2:02:27 PM , Rating: 3

If someone is wrong I don't care what their name or title is.

RE: Too Late To Delay
By Hieyeck on 8/6/2009 5:27:05 PM , Rating: 2
There's NO WAY in hell this will even slow down Microsoft in the least bit. Or anyone else for that matter. Let's take a look at the seriousness of this issue:

a) Half the time, it BSODs. Restart, problem fixed.
b) The other half, it chews up memory. CAD and end process, problem fixed.

Operation of the computer can continue, and the users learns to not use said function until patched. Hardly serious at all.

But wait, it's a problem that:
1. is limited to a command used only by power users 99% of the time (the 1% whilst being instructed by a power user).
2. is limited to a particular function/switch of a command
3. is limited to a particular quirk of said function/switch

The average user won't even touch this, and power users will RARELY touch this.

And as power users all around (for the most part) let's be honest here: hard drives are much better than they were in the past and aren't exactly valuable pieces of equipment anymore. Data on a bad sector is lost anyways, and once you encounter problems with a harddrive, you're more likely to first try formatting and when that fails, replace it. And if that drive was really that important that you HAVE to chkdsk to try and fix it, it's ENTIRELY your fault for not backing up or putting it on a RAID (drives are are dirt cheap these days) - and if you do, you chuck the bad drive anyways and swap in a new one.

The only thing this will turn out to be is another Mickism.

RE: Too Late To Delay
By Alexvrb on 8/6/2009 10:39:58 PM , Rating: 2
They should add the headline for this article to the quotes at the bottom.

RE: Too Late To Delay
By Samus on 8/6/09, Rating: 0
RE: Too Late To Delay
By Motley on 8/7/2009 1:35:10 PM , Rating: 2
Running chkdsk with the /r parameter isn't common. All IDE drives remap bad sectors on their own transparent to the OS, most of the time. Only in extremely rare circumstances would the drive not be able to (correctly) detect a bad sector and not be able to correct it and remap it. In the vast majority of cases where that could/would happen, you are dealing with a hardware issue in which the drive should be replaced immediately, not chkdsk /r'ed and put back into use again.

I've been using PC's before hard disks were even available for them, a don't recall ever using chkdsk with the /r parameter. Way back in the day we had utilities to deal with bad sectors on floppies and the first hard disks though. I believe I even stopped that practice with the first IDE drives (or shortly after) at which time I was using spinrite for those types of things -- not chkdsk.

Lastly, chkdsk /r works just fine under my tests. Took a large part of memory then stabilized, which is not indicative of a true memory leak. It was obviously a controlled allocation, and when the memory was all allocated, the speed of stage 4 significantly slowed down. I did it on a non-boot partition, so I wasn't required to reboot and do it at start-up, so in the rare case that I would actually want to run chkdsk with the r parameter on a non-boot partition that wasn't in use (No files can be open on it, nor can you access it while chkdsk is running on it), then it might have been nice to be able to limit chkdsk's memory usage so I can continue to use the computer in a degraded state. I wouldn't call any of these scenarios a show stopper or even critical. More like a small nuisance when an extremely unlikely event occurs, or you have a serious hardware problem (bad ram/bad drive).

RE: Too Late To Delay
By Entropy42 on 8/6/2009 4:26:46 PM , Rating: 2
A non-issue? This bug will ruin my morning /r chkdsk routine!

RE: Too Late To Delay
By Alarchy on 8/6/2009 11:30:19 AM , Rating: 4
Wow, what an incredibly inflamed (and untrue) article on DT.

RE: Too Late To Delay
By crystal clear on 8/6/2009 11:34:17 AM , Rating: 5
Blowing it out of proportions with statements like

Microsoft is reportedly trying to abscond with the responsibility

shows other motives rather than simple reporting.

Hey whats the problem simply patch it ...this is not a showstopper,the SHOW goes on.....

RE: Too Late To Delay
By bhieb on 8/6/2009 1:36:45 PM , Rating: 5
easily exploitable security hole -- just gain access to a Windows 7 system as a standard user and run the utility to crash the system with ease

I really liked that one too. Easily exploitable...oh as long as you have users rights on the system. LMAO if you can get access with enough rights to run chkdsk then chances are you can do far more damage that just a crash.

Anything that has to be quantified with "just gain access as a standard user", is by definition not EASY!

RE: Too Late To Delay
By Donkeyshins on 8/6/2009 3:58:54 PM , Rating: 5
easily exploitable security hole -- just gain access to a Windows 7 system as a standard user and run the utility to crash the system with ease

In addition, you can't even run CHKDSK /R as a standard user in Win7 . You have to elevate privileges to Administrator in order to even perform that function.

Bad form, Jason.

RE: Too Late To Delay
By Smilin on 8/11/2009 6:17:53 PM , Rating: 2
Crash windows box to cause grief.

You're in front of a locked PC.

Do you:
A) Hack into the box from the logon screen using some as yet undiscovered vulnerability then run a chkdsk to crash the system.
B) Use social engineering to obtain the user's password. Run chkdsk to crash the system.
C) Unplug the power cord.

If you answered C then you're bright enough to go work at McDonalds. Congratulations! If you answered A or B then the line for jobs at infoworld is over there...don't bother applying at McD's.

RE: Too Late To Delay
By crystal clear on 8/6/2009 11:47:27 AM , Rating: 4
The source of this news item-

A critical show stopper bug has been found in the Final Windows 7 RTM 7600.16385 and in the updated 7600.16399 builds! Thanks to mikerolsonw7c of Windows7Center for informing us of the critical bug. The issue is related to the "chkdsk /r" command on a drive other than the system drive. For example if you have drive C: and drive D: with C: being Windows 7. If you open "cmd" and run "chkdsk /r D:" on "Stage 4" of chkdsk it will have a very critical memory leak and max out the system memory then BSOD due to lack of memory available. This issue is present on non-Patched 7600.16385 and Patched 7600.16399 RTM builds. This is a very critical bug that Microsoft should have caught before sending 7600.16385 to OEMs. Sadly, now Microsoft will have to fix this and then re-distribute RTM code to OEMs or patch it. I would not doubt myself when Microsoft gets word of this Show Stopper bug if the TechNet/MSDN releases on Thursday the 6th get pushed back to re-implement new code into the RTM build.

RE: Too Late To Delay
By gstrickler on 8/6/2009 3:10:30 PM , Rating: 2
At this point, I would not call this a show-stopper. Yes, the BSODs are a significant concern, but they don't occur on all configurations, so MS MIGHT be correct about them being driver or hardware issues. That's a plausible explanation based upon the available information.

However, designing a single program (even a utility such as ChkDsk.exe) to use all except 50MB of available RAM in a system that is designed to be multi-tasking is a foolish design choice. Unless the speed increase can be demonstrated to exceed 30%, you should never design software for use in a multi-tasking system to use more than 50% of physical (not virtual) memory. A 10% speed increase is not worth consuming nearly all of any resource. Whenever possible, you should cap memory usage to the lower of:
- available physical memory (i.e. usable physical memory - a reasonable amount for the OS)
- maximum memory that is beneficial (i.e. provides additional capacity and/or notable speed improvements) to the application. For most apps, this can be estimated fairly easily, but for others it's very difficult.

Memory, disk, and CPU are shared resources, don't design your applications to hog them unless it's intended that no other processes will be running concurrently.

Guidelines for memory allocation:
Don't request significantly more memory than needed for good performance with the current workload. You can allow the software to request more memory if it's needed, but don't request it unless and until it's needed and release it when it's no longer required.

If there is any reasonable way to avoid it, don't request more than about 75% of physical RAM. While it's simpler to write for an (effectively) unlimited amount of RAM and let the OS manage virtual memory, you'll generally get better performance by writing your application to do it's own swapping and stay within physical RAM.

Make sure some of your QA testers are testing on a machine with the slowest CPU and least RAM you expect your target users to have, and make that configuration the minimum requirements that you officially support. If it's too slow to be usable there, either increase the minimum requirements or make the developers improve the code to work better in that environment. You should also do QA testing on the biggest/fastest machine you can to make sure it's usable there also.

RE: Too Late To Delay
By epobirs on 8/6/2009 7:07:44 PM , Rating: 2
I disagree. Running the utility, especially in repair mode, generally reduces the system to an effectively single tasking state if you want it to finish sooner than later. For the main system volume it is usually necessary to schedule it as a startup task, in which case you have no use of the system and allocating all resources to completing the disk repair ASAP is entirely sensible.

If I'm going to lose the use of my PC for an hour to disk repair, using the whole system towards reducing that time cost me nothing and gains me much.

RE: Too Late To Delay
By gstrickler on 8/7/2009 3:27:06 PM , Rating: 2
It reduces it to effectively single user mode only because it's using all the RAM, not because it's actually taxing the capabilities of the system.

I can run ChkDsk (even with /r) on a secondary drive (internal or external) on XP with only a minor impact on system usability. It's only a problem if I'm running ChkDsk on a second volume that's on the same drive as my boot/system volume (or when the second drive is a "slave" drive using a PATA connection). In short, it causes a problem when it uses too much of a specific resource that I need for other purposes. Using "almost all" RAM is always going to cause a bottleneck for multi-tasking.

RE: Too Late To Delay
By Motley on 8/7/2009 1:13:10 PM , Rating: 2
The extra ram seems to speed up the process significantly (Like 10x). So I would say it's justified.

RE: Too Late To Delay
By gstrickler on 8/7/2009 3:42:03 PM , Rating: 2
Unless you've tested the new version with significantly different amounts of RAM. and with virtual memory disabled/minimized, you can't back up that claim. Comparing the speed of the new Win7 ChkDsk to Vista or XP's ChkDsk is meaningless because it's a completely redesigned program. The speed increase could all come from an improved algorithm and may or may not have any significant benefit from increased memory.

If you want to test it, find a machine with 3-4GB of RAM on which Win7 ChkDsk /r uses 90+% of the available RAM to process a given secondary volume and time it. Turn off (or set to absolute minimum) virtual memory, and time it again. Then, take out 1GB-2GB of RAM (2-3GB total now) and run ChkDsk /r on that same volume. Compare the times of those two. You're not likely to see any significant difference. If you like, take out another 512MB-1GB and repeat. As long as you've got several hundred MB Physical (not virtual) memory available after login, ChkDsk will probably perform at essentially the same speed.

RE: Too Late To Delay
By AstroCreep on 8/6/2009 3:54:36 PM , Rating: 2
Yeah, Ed Bott picked up on this one too;

Sounds reasonable to me, but would be perhaps more reasonable to leave at least 10% of your system's physical RAM available...just in case. Might appease the Chicken Littles of the tech world who said this is a "Critical Bug" and a "Show Stopper". ;)

RE: Too Late To Delay
By MatthiasF on 8/6/2009 1:04:30 PM , Rating: 5
No point delaying. The issue is only on the 64-bit version of Windows 7 and it's not a true memory leak.

The version of chkdsk.exe is the same on both 32-bit and 64-bit installations of Windows 7, but doesn't seem to be compiled for 64-bit use or being run through the 32-bit emulator properly. So, when memory is addressed it goes into a loop and never stops incrementally allocating a memory block. The issue doesn't happen when using the 32-bit version of command prompt ("C:\Windows\SysWow64\CMD.exe").

Easy solution, push out a 64-bit version of chkdsk.exe to 64-bit installations via Windows Update. It's less than 100 kbtyes in size, taking a few seconds to download and install.

Big freaking WHOOP. Stop the dramatics, Mick.

RE: Too Late To Delay
By gstrickler on 8/7/2009 3:47:48 PM , Rating: 2
At least some of the reports indicate that the memory is not freed when ChkDsk /r completes, therefore, it may be a memory leak. I don't have enough information to say that it is or is not a memory leak, only that some results point to that possibility.

What an inflammatory headline to this article...
By shoek on 8/6/2009 11:26:47 AM , Rating: 4
How can this be characterized as a "major showstopper". Who does chkdsk /r routinely? I've never done it in years of running Windows OS.
Beyond that, it cannot be routinely reproduced.

RE: What an inflammatory headline to this article...
By Lonyo on 8/6/2009 11:38:35 AM , Rating: 4
Not only that, but how many people (average users) have a second hard disk anyway?.

Also this is a bit suspect:
The bug has been confirmed on many different hardware setups --it's been verified to occur on everything from a Intel Atom-based netbook running the 32-bit version, to a Intel Core 2 Duo notebook running the 64-bit version, and a VMware Workstation 6.5.2 virtual machine running the 32-bit version.

How many Atom systems or Core 2 Duo laptops will have multiple HDDs?

And finally can't I just type "shutdown -t 0 -r" instead of "chkdsk <second hard drive letter> /r"?
I mean, this bug to try and force a crash requires a second hard drive, inputting of the correct drive letter, and then it may or may not cause a crash. My solution, "shutdown -t 0 -r", seems a lot simpler if you are trying to force a computer to shut down.

By Keeir on 8/6/2009 2:24:32 PM , Rating: 2
Not only that, but how many people (average users) have a second hard disk anyway?.

Isn't it supposedly its a non-boot partition?

I always recommend people to have a second partition for Data when running Windows, so that when they need to re-image thier boot drive they don't lose everything.

By rs1 on 8/6/2009 4:21:09 PM , Rating: 2
I have quite a few HDD's in my system, configured as two RAID volumes, one of which is partitioned into several logical volumes. However, I don't think that counts as "average". At the same time, I've never once ran a 'chkdsk /r' on any of the systems I've used. I've used chkdsk a few times, and windows has automatically used it on startup after a crash a few other times, but I've never once manually added '/r', and I'd assume that the auto-check does not use that option, as well.

It sounds like someone has managed to make a huge issue out of nothing, to me.

RE: What an inflammatory headline to this article...
By walk2k on 8/6/09, Rating: -1
RE: What an inflammatory headline to this article...
By TomZ on 8/6/2009 1:27:52 PM , Rating: 1
First of all, running scandisk regularly is not necessary. I never run it on any of my machines or servers, and I've never run into any kind of file corruption issues. Maybe back in the days of Win9x crashing many times daily, but with the OS and machines much more reliable, it is not a required maintenance item.

Second, it is not a show-stopper (RTM is actually released now) because it is a possible bug may exist under certain factors, so most people will never experience the issue. More importantly, it is something that can be easily fixed via Windows Update, so there's no net impact to customers, and hence no need to delay a release.

I think a lot of people think that an RTM release is supposed to be "perfect" with no bugs. Perfect software doesn't exist. Instead, we can only talk about "better" and "worse," and what RTM means is "good enough to release."

The reality is that even an RTM has lots of unfixed bugs that will be patched after release - with many of those bugs not having been found yet!

By Fritzr on 8/7/2009 1:42:22 PM , Rating: 2
Yep those bugfixes that missed the bus are the reason many people are in the habit of waiting for SP1 when the last minute bug fixes are bundled up with whatever changes MS thought necessary.

Then SP2 fixes the bugs that SP1 added as well as old bugs patched after SP1...SP3 fixes the SP2 bugs and this cycle continues until the next Win version is released.

Think of the RTM as SPzero for each new version since it replaces the public beta test Release Candidate

RTM is not perfect. It is eimply good enough to use. Patches will be issued as new bugs are found until MS EOLs the version. Every version of Windows was released buggy and remained buggy even after retirement.

If perfection was required for release there would be no Windows OS.

By omnicronx on 8/6/2009 1:35:57 PM , Rating: 1
You never run scandisk? Well you should.
Ya man you all should, I mean isnt everyone still rocking Dos and Windows 9x? Scandisk does not exist in the NT world as it is not compatible with NTFS so I assume you mean chkdsk ;) Chkdsk is really your last resort anyways, S.M.A.R.T monitoring should find bad sectors and reallocate them to a spare area, and at that point should actually lock out those bad sectors completely even after formatting. The only time I have ever had to make use of Chkdsk is when my system was unable to reallocate these bad sectors because of insufficient space, and at this point it is probably time for a new HD anyways as it is probably on its last leg.

So to say everyone should use Chkdisk on a regular basis shows that you don't know how current hard drive monitoring really works, we are not still in 1995.

One last thing, I would have to say that on the systems that do run chkdisk, it is probably after a critical failure in which it starts the next time you load windows. Nobody has said anything about this problem occuring at this point, so once again I think you are taking this issue out of context.

RE: What an inflammatory headline to this article...
By walk2k on 8/6/09, Rating: -1
RE: What an inflammatory headline to this article...
By TomZ on 8/6/09, Rating: -1
RE: What an inflammatory headline to this article...
By Pirks on 8/6/2009 3:55:56 PM , Rating: 2
And, uh I run defrag to ... gosh, DEFRAG the HD
Alexstarfire, is that you? ;)))

By Alexstarfire on 8/7/2009 2:40:42 AM , Rating: 2
No. Why would you think that?

RE: What an inflammatory headline to this article...
By Pirks on 8/7/2009 3:08:58 PM , Rating: 2
MS-DOS lovers still manually defrag and scandisk their drives, don't they? ;) Cmon Alex, don't hide it, we all know you silently defrag your MS-DOS when nobody's looking

By Alexstarfire on 8/9/2009 3:25:26 PM , Rating: 2
I haven't done a defrag in years. Haven't had the need to. Only time I'd even consider it is when the OS boots up slow. Got my OS on a separate partition so it'd only take like 5 minutes to do the most intense defrag. But like I said, haven't done it in years. Don't even have ANYTHING defraging my drives period. Not even while idle.

And who the hell uses scandisk regularly? I've used it when my HDD was malfunctioning, but that's it. Didn't even help. Kinda funny that it was a Seagate that messed up, what with the recent article on the Macbook drives and all. That drive was quite old. Used it in 3 different computers. Ma it rest in peace. Too bad it took all my damn photos with it.

Every post you make makes you look stupider. So please, for the sake of everyone here, STFU.

By omnicronx on 8/6/2009 4:06:02 PM , Rating: 2
It's a program that maniuplates file system data at a very low level...
Uh no.. that is very doubtful. it is not tied to file system data in any way or form, just bad blocks which could possibly contain file system data. And as I pointed out in my other post, crashing in the middle of this process probably wont make this data unreadable as it will never reach the point where it marks the bad blocks as unusable. (if it did reach that point the data from that block would have been moved and repointed already)

By omnicronx on 8/6/2009 4:13:08 PM , Rating: 2
To be more clear, chkdsk /r works on 4 passes(Well its really 5, but pass 4-5 is pretty much the same, one checks used blocks one checks unused blocks) (instead of the normal 3), and the part where it actually looks for bad blocks is the very last pass, i.e everything that is in a normal chkdsk has already happened before it ever tries to recover bad blocks so any of the low level processing done before hand (checking indexes, security descriptors) will have been completed before the last pass where it actually checks for bad sectors.

I would say that the chance of crashing is more of a problem, as there really is no chance of losing data unless it is already passed the point of no return anyways. (i.e blocks are not recoverable)

By PhoenixKnight on 8/6/2009 7:44:48 PM , Rating: 2
You do realize that the fixing of errors is done with the /f command line switch, not /r, right? /r is used to run a full surface test of the drive to search for bad sectors, which is only a last resort if you are having data corruption issues. As many times as I have run chkdsk, I have maybe used /r once in the past decade.

Also, corruption occurs when there are errors writing to blocks, not when simply reading from them, as chkdsk mostly does. And even if it did crash and corrupt data, a simple chkdsk /f would probably fix it.

By omnicronx on 8/6/2009 3:12:18 PM , Rating: 2
You seriously think a horrific crash bug that has the potential to corrupt massive amounts of data is all hunky-dory as long as it only happens "occasionally"? Good luck with your OS product I'm sure it will be a smashing sucess.
Please explain how any data could be lost, especially considering the only writing going on is when you are moving bad blocks in which chkdsk does not wipe the bad blocks but marks them as unusable. This can only happen once the operation is complete, meaning if you were to BSOD in the middle of that process this would not happen, i.e it is very unlikely you would lose any data.
But for example I always run a scandisk before a defrag, and I that at least a couple times a year.
And this used to be a common practice, but is really not needed anymore. Chances are the bad blocks will be marked as unusable and moved before you ever get to run defrag.

As other posters have noted, there is no use listening to any of the sources until they figure out what the underlying problem is. Chipset drivers or problems with running a 32bit chkdsk in a 64 bit environment are not showstoppers and can easily be fixed via windows/driver update.

By omnicronx on 8/6/2009 3:13:54 PM , Rating: 2
P.S Scandisk died with 9x/FAT, so please stop saying you run it as you quite obviously do not.

By walk2k on 8/6/2009 3:41:52 PM , Rating: 1
Yeah ok settle down there Nerdlinger. Scandisk, checkdisk, whatever... it's the same thing.

By Smilin on 8/6/2009 2:05:05 PM , Rating: 2


Get off the f'n thread noob.

RE: What an inflammatory headline to this article...
By Pirks on 8/6/2009 3:52:50 PM , Rating: 1
Alexstarfire, Alexstarfire! It's him, it's him! The Famous MS-DOS Noob, hahaha

By Alexstarfire on 8/7/2009 2:44:44 AM , Rating: 2
Ohh, I see the pattern here. I'm your favorite person to hate. I'm slightly honored that I could get under your skin that much.

By Smilin on 8/7/2009 12:38:23 PM , Rating: 2
If Priks hates you then you're probably OK.

RE: What an inflammatory headline to this article...
By Pirks on 8/7/2009 3:27:24 PM , Rating: 1
And if Pirks likes you? Alex you're in trouble! LOLOLOL :)))

By PhoenixKnight on 8/8/2009 1:14:38 AM , Rating: 2
Watch out Alex! I think Pirks has a man-crush on you.

RE: What an inflammatory headline to this article...
By Pirks on 8/8/2009 2:14:42 AM , Rating: 1
How do you know Alex is a man??!!! :))) OMG!!! :))) lolololzzz

By Alexstarfire on 8/9/2009 3:27:44 PM , Rating: 2
How do you know I'm a woman? He must be spying on me. Sorry to disappoint you Pirks, but I'm a dude. Can you take your spy cam out of my shower now?

By Belard on 8/6/2009 1:22:26 PM , Rating: 2
WHile it maybe an issue with Windows 7 and Intel chipsets, its a driver issue.

I ran the test on an AMD 64 computer with 2GB RAM, in seconds memory free went from 1.5GB to 0.

The scan continued. I canceled the scan and the memory came back.

This is a non issue

By 91TTZ on 8/6/2009 4:03:27 PM , Rating: 2
But most people have said the same thing. The increased memory usage is a feature and not a bug. This is not an issue.

By Belard on 8/6/2009 8:02:11 PM , Rating: 2
No, there is a difference between a specific driver issue and a SEVERE software bug in the OS.

If the OS had such a bug, it would effect everyone - AS the article/blog says.

By Breathless on 8/6/2009 11:15:01 AM , Rating: 5
RE: Meh..
By Master Kenobi on 8/6/2009 11:25:59 AM , Rating: 5
Ditto. I can cause it but it's not a show stopper at all. No BSOD here either. I wonder if the systems bluescreening are systems where a portion of the RAM is reserved for the video card? That might cause an issue if Windows attempts to seize it for the purpose of a CHKDSK /R.

RE: Meh..
By sinclaj1 on 8/6/2009 11:24:45 AM , Rating: 2
Thanks for the link, that certainly puts this into better perspective.

As for the new "feature" to purposefully use more memory to speed things up, Microsoft probably could've put a checkbox (or command-line option) to do that so that it is optional. In the GUI version, there could be a small description as to what you can expect to see from your memory usage if you choose the option to "speed up" your chkdsk run.

RE: Meh..
By mikefarinha on 8/6/2009 11:29:10 AM , Rating: 3
This isn't the default option. If you run it from the command line you have to use the /r option. If you do it from the GUI you have to intentionally check the option.

RE: Meh..
By Sazar on 8/6/2009 12:20:37 PM , Rating: 2
Did you read the link?

You basically have to check, select or click several steps through to even run this with the /r flag. It's not a one-click option accessible by a shortcut.

RE: Meh..
By Akrovah on 8/6/2009 11:30:03 AM , Rating: 3
Kinda figured this was an inflated claim, especially as some people (such as me) have been running Win 7 since January or even sooner for technet people and this bug is just now being found? Plus it has to be activated manually on a specific type of setup (multiple drives/partitions, which most people don't have) and is inconsistent even then? Not exactly what I would call a show stopper or a reason to delay launch. I think this is just being inflated by the people who absolutely MUST find something wrong with it since it is an MS product.

Not a bug, but by design
By bpt8056 on 8/6/2009 11:46:54 AM , Rating: 5
RE: Not a bug, but by design
By Spivonious on 8/6/2009 11:57:44 AM , Rating: 4
Yep. Ed explains it very well.

Personally I'd rather have some extra memory to continue using my PC while chkdsk runs in the background, but if reserving all of this memory means the check will complete faster, then I'm willing to give up my machine for 10-15 minutes.

Also, there's absolutely no reason why this would crash the machine, unless that top section of memory is faulty.

RE: Not a bug, but by design
By Lerianis on 8/10/2009 4:13:22 PM , Rating: 2
True. There is no reason why using all the memory on the machine, even if you are running a program on it that uses scads of memory, should crash the machine even if you don't have a page file enabled.

By ChronoReverse on 8/6/2009 12:27:30 PM , Rating: 4
This should be modded up so people will see it.

The "reproducible crash" is actually caused by bad RAM since using all the memory shouldn't cause a crash except when there's faulty hardware.

By vanka on 8/6/2009 12:25:48 PM , Rating: 5
Yet again we have another sensational headline and an article with dire predictions of the end-of-the-world variety from Jason Mick; as usual, all this is backed up by facts that exist only in the imagination of the author.

DailyTech should start including the authors of the articles underneath the headlines so we know which articles we should skip to avoid wasting our time.

By TomZ on 8/6/2009 1:37:52 PM , Rating: 2
Not to beat a dead horse, but where did Jason get the "Launch May Be Delayed" idea? Microsoft certainly never stated that. Did he make that up himself or was he just repeating a lot of other blog-tards?

By Donkeyshins on 8/6/2009 4:02:19 PM , Rating: 5
Not to beat a dead horse, but where did Jason get the "Launch May Be Delayed" idea?

That was a typo. Jason meant 'Lunch may be delayed' since he had to post this before going for take-out.

By Pirks on 8/6/2009 4:46:13 PM , Rating: 1
where did Jason get the "Launch May Be Delayed" idea?
From his bank account

64 bit laptop?
By postalbob on 8/6/2009 4:04:58 PM , Rating: 1
Haha, this seems like an article written just for me.

A few days ago I installed an external hard drive on my 64 bit Windows 7 notebook with a core 2 duo.

It has had constant freezing problems and blue screens since the hard drive was added. I'm thinking this memory leak explains it. I'm also thinking it's very specific circumstances causing the freeze. It's not often someone can say "My computer's testing resulted in the delay of a Microsoft Windows OS". Now I can. Hah.

RE: 64 bit laptop?
By epobirs on 8/6/2009 7:11:41 PM , Rating: 2
No, it doesn't explain your problem. Are you constantly running CHKDSK? Unless you are, your situation is not related.

Why not try actually running CHKDSK /R on your external drive with Task Manager onscreen to show what is happening before making any assumptions?

RE: 64 bit laptop?
By postalbob on 8/6/2009 7:43:25 PM , Rating: 2
Considering the laptop froze, and then constantly tried to run chkdisk automatically at start up, and then showed blue screens which is what windows 7 does...

Yes it is the problem.

Blue screens don't show up for no reason my friend. Also: This problem being a memory leak from the looks of it is a problem when you attach an external hard drive. The disk is checked when it's attached (duh). Then it has a memory leak problem and freezes. It's simple as that.

The computer crashed 10 times...Showed blue screens...It's 2 weeks old...And I can't believe you are so argumentive that you feel like striking up an argument of "No...There's no problem there".

Pardon the anger, but you my friend are one of the smart asses of this page.

RE: 64 bit laptop?
By Motley on 8/7/2009 1:58:05 PM , Rating: 2
Sorry, but epobirs is correct. What you described isn't what this article is about.

A) Chkdsk doesn't run with the /r parameter on it's own, even after a reboot. When the system is shut down improperly (like a bluescreen), it is run with the /F parameter only.

B) Chkdsk isn't run with the /r parameter when you plug in an external USB drive. If it did, you wouldn't be able to access that drive for 5-10 hours until it completed.

C) No one said "No...There's no problem there", so it shouldn't be quoted. Quotes are for repeating someone's exact words, which you didn't. Also, no one said you didn't have a problem, because you obviously do in many ways, but this article isn't about those.

D) epobirs was pretty nice in his response to you, and you respond with a childish and inflammatory rebuttal. I'd suggest what your problem is, but you are an ass, so you can go fix it yourself.

RE: 64 bit laptop?
By postalbob on 8/7/2009 3:06:49 PM , Rating: 2
Epobirs is incorrect and so are you.

It is childish to make an assumption in an attempt to disect and attack either an article or a person's point.

He was childish in his arrogance.

My reply was perfectly meritted.

Would you please explain the 10 freezes while using the hard drive while running starcraft? How about while running Crises? It is clear that the problem is not just the one checkdisk memory leak.

You are making assumptions on the error, and on the article. They stated a massive memory leak has been detected, and that they are looking into the extent. Memory leaks are VERY rarely limited to a specific search. That's why they are a memory leak, it's not specific enough.

So please, diagnose my computer would you?

Make an arrogant remark in the article would you?

These daily tech guys make good articles, idiots like him and you pick it and other people's information apart with no knowledge whatsoever.

Ass, is what you and him are. I'm just a pilar of integrity and geniune interest into finding problems, rather than trying to point them out like a 10 year old. Why don't you and your friend get some ingeniouty like the poster of these articles?

RE: 64 bit laptop?
By DominionSeraph on 8/9/2009 1:13:09 AM , Rating: 2
It's not often someone can say "My computer's testing resulted in the delay of a Microsoft Windows OS". Now I can.

And you'd be talking out your ass.

1. Windows 7 is released.
2. You obviously have no idea what chkdsk /r is, what a memory leak is, or the slightest idea how computers work. You can't even spell, "Crysis." So beyond the fact that it's unlikely you contacted Microsoft about this, it's incredibly doubtful that you are capable of writing a coherent bug report. So your fail rig's problems have nothing to do with anything at Microsoft.

Stop trying to write yourself into the story.

By theprofessor on 8/6/2009 11:19:27 AM , Rating: 5
...being spread by Jason Mick (and many others).

Microsoft already acknowledged this issue. They said it was minor and will not hold up the the release of Windows 7.

By 3minence on 8/6/2009 12:52:26 PM , Rating: 2
Microsoft says lots of things, and I don't trust any of it until I see independent confirmation. Showstopper or not, MS will try to minimize the reaction to this until they can firmly say what it really is and the consequences. Remember how MS initially hemmed and hawed about the Home Server bug? And then how long it took to fix? This may be as MS says, or it may not. Only time will tell.

Hopefully this is as MS says and only requires a driver fix of some sort. I'm really looking forward to Win7.

By Targon on 8/7/2009 7:02:38 AM , Rating: 2
Since this only seems to affect the /r option and not the /f option, the easy workaround from Microsoft would be to disable /r until the problem is fixed. End of story, no major problems.

Seriously, who looks at the files that chkdsk makes anyway, unless critical information was lost?

Why would this delay the launch again?
By zero2dash on 8/6/2009 12:33:08 PM , Rating: 2
Is it a bug? Yeah. Will 90% of computer users ever see it? No.

Run chkdsk /r? Most people don't even scan for viruses or spyware regularly, which is why I get emails, calls, and systems brought to me by friends, coworkers, and family several times a year.

Not only that, but who runs chkdsk with Windows running?

This sounds like something the Enquirer would drum up to get a +1% gain in web traffic. FAIL.

RE: Why would this delay the launch again?
By mikefarinha on 8/6/2009 12:46:13 PM , Rating: 3

This isn't a bug. The only problem this is causing is that the way chkdsk /r is operating is different than people expectations.

People expect chkdsk /r to take up little RAM but take hours up on hours to complete.

The new method takes up any available RAM but takes a fraction of the time to complete.

This is the same response Microsoft got (but on a smaller scale) when it changed the Office interface. People feigned outrage to grab some extra clicks on their headlines.

RE: Why would this delay the launch again?
By Smilin on 8/7/2009 10:38:27 AM , Rating: 2
This isn't a bug. The only problem this is causing is that the way chkdsk /r is operating is different than people expectations.

The reported bug (it's been confirmed since yesterday) is consuming too much ram.

Consuming a lot of memory is not a bug, but doing it until the box bugchecks is.

By Smilin on 8/11/2009 6:06:08 PM , Rating: 2
OK, apparently it's not causing the bugcheck. The memory use peaks at 90% and stops. The bugcheck was likely from hitting bad ram that's infrequently used.

By rcc on 8/6/2009 11:26:11 AM , Rating: 3
Microsoft is reportedly trying to abscond with the responsibility

So, despite what the rest of the article implies, MS is keeping the responsibility to themselves?

perhaps a version of deny, pass off, etc. would be better.

RE: Huh?
By johnsonx on 8/6/2009 5:16:37 PM , Rating: 3
Mick needs to keep a dictionary next to his computer to look up the big words. Next to that, he needs a children's dictionary to look up the littler words used in the big dictionary.

He STILL hasn't fixed this one:

RE: Huh?
By Omega215D on 8/7/2009 3:45:43 AM , Rating: 2
That sounds like the Apple way of doing things...

By Rinadien on 8/6/2009 11:19:55 AM , Rating: 5
Further, the new OS would have an easily exploitable security hole -- just gain access to a Windows 7 system as a standard user and run the utility to crash the system with ease.

As opposed to just... yanking the power cable? Does the crash actually corrupt anything or is it just a nuisance that is easily solved by restarting the PC?

I don't know about you, but I'm not sure how this is such a security hole when it requires physical access, does ZERO damage to the stored data, and the system can be brought back online faster than it takes to take it down...

Tomorrow's headline, the Reset button has been outlawed because it causes a major security hole.

RE: Ummm....
By sinclaj1 on 8/6/2009 11:26:42 AM , Rating: 2
Now, as always, the biggest security hole is is ID-10-T users.

from now on...
By johnsonx on 8/6/2009 12:57:23 PM , Rating: 5
From now on, whenever I read or hear something largely false, baseless and overblown, instead of calling it "BS" as I would have in the past, I will now call it "JM"

RE: from now on...
By johnsonx on 8/6/2009 4:55:10 PM , Rating: 2
I see the masses liked that one... I don't suppose one of the DT staff will see fit to give me a 6?

Enough man.
By Smilin on 8/6/2009 1:59:51 PM , Rating: 3
I know you do this crap to generate clicks but if your site starts looking like it's run by a bunch of clowns you're going to see that click rate drop.

Catastrophic Bug Found in Windows 7 RTM Build, Launch May be Delayed

There is no bug without a repro and MS has no repro. This doesn't mean just that their engineers can't repro it, it also means no reporting customer has provided a repro either.

I'm not saying there won't ultimately turn out to be a bug but what I am saying is this:

No bug found yet so it can't very well be catastrophic.
No bug found yet also means it won't be delaying shipment.
Both of the above indicate this headline is utterly full of sh1t (for now) and YOU KNOW IT.

You are stirring up a bunch of FUD and after two years of this crap with Vista I'm tired of hearing it.

/rant off. Mod me down to hell. I don't give a fvkc.

RE: Enough man.
By Pirks on 8/6/2009 3:41:22 PM , Rating: 3
I don't give a duck too! Mode me down chikowintrolls!!!

Now, with that out of the way lemme introduce you to Randall Kennedy.

Randall Kennedy. On the other side of the coin, we have InfoWorld miscreant Randall Kennedy, a man who has made a mini-career out of bashing Windows. After being mistakenly invited to the Windows 7 reviewers workshop at PDC 2008 (he's not a reviewer) and then being uninvited, Randall tried to sneak in but was turned away at the door. When he discovered that the reviewers who did attend the workshop received loaner laptops on which to test Windows 7 on an ongoing basis, he begged Microsoft for one (both publicly and privately) but was again denied. Hypocritically, he then bashed Microsoft for trying to gain the favor of reviewers by loaning them hardware on which to test a pre-beta OS. You know, because reviewers are never loaned products for testing purposes and might be swayed by such a thing. He also proceeded to blast Windows 7 for being a warmed over version of Windows Vista. In a final bit of stupidity, his editor defended Kenney's writing as an attempt at humor. I suppose there's a fine line between farce and stupidity. So what's Kennedy's contribution to Windows 7? He proves that no matter how good this product is, there will always be people out there actively working to undermine anything Microsoft does. He's not trying to enlighten anyone. He's just a bad guy seeking to spread FUD for his own dark purposes.

As you guys can see Mick is not too far from that idiotic clown Kennedy. They both spread FUD for clicks. "Money journalists" I call them. You can call them "click whores" ;)

It's more severe than you think
By MADAOO7 on 8/7/2009 8:52:41 AM , Rating: 2
I am running the most recent build of Windows 7 RC, and I am having this problem. I have to tell you, it's a very serious issue. I'm getting blue screens every 5 minutes. It effects every known browser, as well as Windows explorer. I definitely qualify for what is known as a "power user," but the bug is so widespread that it really is a deal breaker for any kind of user. Microsoft simply can't afford to release a mainstream product with this kind of bug in it.

By Motley on 8/7/2009 1:46:07 PM , Rating: 2
You obviously aren't a power user if you are running chkdsk with the /r parameter every 5 minutes.

RE: It's more severe than you think
By Smilin on 8/11/2009 6:10:50 PM , Rating: 2
It effects every known browser, as well as Windows explorer.

Dude, WTF are you even talking about??

We're talking about chkdsk here. You and the scandisk guy should go get a room together and work on fixing your obviously broken PC.

catastrophic bug - ROFL
By jinx101 on 8/6/2009 11:54:01 AM , Rating: 3
"catastrophic bug".. ease up with the dramatics.. a bug, when you run chkdsk /r on a secondary drive? ROFL. Ya, it should and will be fixed by my goodness, this is NOT a show stopper. It will affect such a small portion of people that I have to question the choice of words used in this article (it leads me to believe this is just an inflamatory article). When you find a real catastrophic bug, get back to me. ;P

RE: catastrophic bug - ROFL
By Smilin on 8/6/2009 2:07:38 PM , Rating: 2
Not sure why you got modded down.

By Pilltron on 8/6/2009 2:35:57 PM , Rating: 3
Oh no! Testing did it's job of finding bugs! quick everyone panic.

RE: Really?
By Omega215D on 8/7/2009 3:48:00 AM , Rating: 2
*runs around in a circle* fire fire fire fire fire

The Only Catastrophic Thing I See
By clovell on 8/6/2009 3:15:57 PM , Rating: 5
... is the amount of Fail in this article.

Killer bug?
By GreenEnvt on 8/6/2009 11:24:14 AM , Rating: 2
Yes I'm sure the tens of millions of users out there that run chkdsk /r will be affected.

This isn't something people do on a daily basis.
I can't see any reason they would not just continue on schedule and release a hotfix for it.

RE: Killer bug?
By jabber on 8/8/2009 1:48:33 PM , Rating: 2
Yes, I can see this affecting 0% of the average joe user group.

Most of the customers I meet still havent a clue about what defragamentation means let alone them typing something into a command prompt to check the state of their HDD.

Only today had a call out to see that a customer had plugged their printer into the USB adaptor for the PS2 mouseport. Chkdsk? hahahaha dont make me laugh.

Definately a case of 'nothing to see here!'

I can wait....and wait for a patch for this one.

W7 RTM - Not Yet Posted
By ivanr on 8/6/2009 12:32:30 PM , Rating: 2
The W7 RTM is not yet posted on the Technet and MSDN networks sites and there is no mention of why not

RE: W7 RTM - Not Yet Posted
By wempa on 8/6/2009 1:02:43 PM , Rating: 2
It's finally available. I was just getting ready to reply in agreement with you, but I just checked and it's there.

Windows 7 RTM on MSDN
By TomZ on 8/6/2009 1:08:55 PM , Rating: 4
They just released Windows 7 onto MSDN @ 1pm Eastern, so I guess the possibility of it being delayed is now a moot point.

you guys are sad
By Nekrik on 8/6/2009 1:34:20 PM , Rating: 4
can you try to embarrass yourself anymore than this. FFS pull this crap and stop stealing stories from Mac fueled blogs.

The bug does exist!!
By evolucion8 on 8/6/2009 1:22:04 PM , Rating: 2
I plugged a USB Hard Drive in one of my PCs, which has a Via P4M800, Pentium 4 2.80C, 1GB DDR 400 and 40GB hard drive, and when I used chkdsk /F /R on my USB drive, the chkdsk utility started to eat RAM gradually reaching 640MB of RAM usage and 720MB of page file usage, but strangely enough the PC never crashed. The funny thing is that the issue also happens when you use the Check Disk Utility with the two checkmarks On (Fix File System and Bad Sectors)in Tools option in the Hard Disk properties.

RE: The bug does exist!!
By MatthiasF on 8/6/2009 1:29:37 PM , Rating: 1
Are you using the 64-bit version of Windows 7?

By evolucion8 on 8/6/2009 1:27:26 PM , Rating: 3
Update* In my case, when CHKDSK /F /R is used and then you close the Command Window, CHKDSK will close and the RAM will be released, but when you use the Hard Drive Tools option to access CHKDSK, Explorer won't release the RAM.

By harmaton on 8/6/09, Rating: 0
RE: nice
By crazyblackman on 8/6/09, Rating: -1
RE: nice
By Omega215D on 8/7/2009 3:53:02 AM , Rating: 1
Get ready for more overpriced, buggy shit to hit the store shelves.

Why? Is another Apple store opening up nearby? (I own a MacBook and take no sides)

RE: nice
By Omega215D on 8/7/2009 3:54:37 AM , Rating: 2
DT needs to fix their stupid ratings system. replying to a -1 doesn't always mean feeding a troll. Sometimes we like to make fun of certain posts or shine more light on why they're wrong.

goldfish memory...
By William Gaatjes on 8/6/2009 12:15:24 PM , Rating: 2

By Belard on 8/6/2009 1:29:15 PM , Rating: 2
I ran the test on an AMD 64 X2 2.0ghz with 2GB RAM, in seconds memory free went from 1.5GB to 0mb. Kind of fun to watch too....

The scan continued. I canceled the scan and the memory came back.

No crash
No blue screen
No system performance problems

This is a non issue. An incompatibility with intel chipset drivers that is easy to fix.

Better Article
By damianrobertjones on 8/6/2009 4:10:56 PM , Rating: 2

Not much bios in the above articl :)

ran just fine here
By jamesvz on 8/6/2009 4:31:01 PM , Rating: 2
Build 7100 on an AMD machine running the 64 bit version, ran chkdsk on a slave drive and finished without any problems. I aggree the memory ramped up but nothing crashed.

unless they changed something between the RC and the RTM that has to do with chkdsk, this issue will not effect my system.

Lies, errors, hyberbole
By adiposity on 8/6/2009 6:07:38 PM , Rating: 2
This is ridiculous, and no showstopper. A small, infrequently used, command line utility (which I admittedly use from time to time, but only to fix broken XP boxes), with an even more infrequently used command line switch, can use a lot of memory, and possibly BSOD. Ok, this is not a big deal, but it should obviously be fixed.

Second, the theory that such a problem would not affect VMWare shows the ignorance of the author. VMWare uses hardware drivers, period. Just because they emulate hardware, does not mean they don't use drivers for the emulated hardware! So this does not prove it is Microsoft's fault.

How about we stick to the story and stop editorializing?


DT Alternatives
By ActorMW on 8/6/2009 6:59:56 PM , Rating: 2
Most of us are incredibly tired of reading the garbage that is routinely posted to DT so let's move on. I don't want to waste my time facilitating the flow of advertising dollars to the jokers here at DT.

So, anyone know of some good alternative sites that have better quality reporting?

By TechJunko on 8/6/2009 8:32:37 PM , Rating: 2
Its Microsoft, they don't want another Vista incident again, they will do whatever it takes with windows 7, I don't know if I could blame them either. They really need a win with this one.


By SiliconAddict on 8/7/2009 12:27:11 AM , Rating: 2
I have a technet acct. Started the download this morning...And installed it after work on my tablet. Just tried running chkdsk /r from the command line on an external USB drive. Nothing. Tried it on the Partition that I have my Ghost image on. Nothing.

I think the Apple fanboi FUD machine is in full swing at this time. Steve probably sent out e-mail to key iTards to begin operation Bad Apple. Since there is NO indication that MS is "code-red panic mode". This is nothing more then a rehash of another article on the net with a more sensationalistic fanboi overtones.

Grow up.

By Zensen on 8/7/2009 3:46:51 AM , Rating: 2
+ it needs more salt.

By meepstone on 8/7/2009 12:48:30 PM , Rating: 2
He changed the title of article cus he realized he is a moron.

By Old Man Dotes on 8/7/2009 1:18:41 PM , Rating: 2
CHKDSK /r should be run during the reboot process to be most effective; it's outside of Windows and so there's no reason that it, as the only process running, should not use all available resources. Even when running inside Windows, it's not a process that you should be running while you're trying to do something else; the "/r" means "repair" or "recover," and if you're changing data on the disk while you're trying to fix it, well, surely you can see that's a bad idea, can't you?

For the record, I am NOT a fan of Microsoft (nor Apple), but I don't think they are wrong on this score.

memory leak
By shukree on 8/7/2009 2:33:43 PM , Rating: 2
first i am sorry that i submitted this post wrongly on George Ou Blog.
i read this article here first,then i submitted a reply on Chris123NT's Blog.
i have a system with Quad Q6600 CPU=2.4 GHZ, with 8 GB of Ram and i kept only one testing hard drive a Samsung tera Byte with 32 MB Cache.I ran the CHKDSK/r command on a logical partition with 261 GB,and the used space is 173 GB
and it has tens of big files (mostly big ISO files and Back-Up images for my systems).
I ran the utilty two times, one on Windows7 RTM x64 Bit, it took around 70 minutes to complete successfully, but the RAM usage was 7 GB and total memore usage was 7.5 GB.
the second time A Windows XPSP2 x64 Bit used, the check took 68 minutes and only maximum RAM of 13.5 MB and most of the time was about 9 MB.
so there was no crash at all, but there was no meaning for a utility like this to consume this much of RAM without speeding the process.

Windows 7
By 2bdetermine on 8/6/2009 6:14:22 PM , Rating: 1
The bug has been confirmed on many different hardware setups --it's been verified to occur on everything from a Intel Atom-based netbook running the 32-bit version, to a Intel Core 2 Duo notebook running the 64-bit version, and a VMware Workstation 6.5.2 virtual machine running the 32-bit version.

So AMD systems/hardwares are in the clear. Woo hoo ;-)

Major Bug
By Uncle on 8/6/2009 6:51:16 PM , Rating: 1
Maybe MS needs time to fix the rtm hack, if their is any delay at all. The rtm activation hack should have come out after the official release, not 3 months advanced.Now their is plenty of time to really figure out the major bugs.

Ha Ha!
By msheredy on 8/6/09, Rating: -1
RE: Ha Ha!
By zero2dash on 8/6/2009 2:50:24 PM , Rating: 5
Does Microsoft's ads say Windows has no bugs, crashes, glitches, or viruses? No.

Do Apples? Yes. kthxbye

RE: Ha Ha!
By DarkElfa on 8/6/2009 4:23:21 PM , Rating: 2
I just ran chkdsk to try and duplicate it on a Windows 7 64 bit machine with 8 GB of DDR2 and on the 4th stage the memory began rising quickly until it got to nearly 98% usage and then very slowly started to go down again. Of course at the rate the stage is progressing, its gonna take the next 6 hours to finish. For reference, my PC only uses around 21% of its memory 99% of the time.

RE: Ha Ha!
By Maxima2k2se on 8/6/2009 4:40:00 PM , Rating: 1
LMAO you act as if the OS has been released and millions around the world are getting the BSoD. This is unreleased software still being polished. Keep digging....

RE: Ha Ha!
By SiliconAddict on 8/7/2009 12:43:22 AM , Rating: 1
When I first got my MBP with Intel Tiger I migrated my photos over to the photo directory. There were a bigillion pspbrwse.jbf from Paint Shop Pro. So I went into Spotlight. Typed that in. It brought up everything in the directories that ended up being several MB worth of files. I then dragged it into the trash. It started deleting. 10 seconds later the system KPed. I could do this again and again and again. Apple being the retards that they are allowed you to search in your trash. So before the system was done moving the files to the trash items in the trash would show up in Spotlight and cause an infinite loop.

So please do the world a favor and shove your iPhone down your throat and choke. No OS is perfect and I hate to break this to you but the migration from Vista to 7 is about 100x better then Apple's retarded move from 10.0 to 10.1 Vista to Win7 took a couple years were it took Apple something like 6 to get to the same damn point. Meanwhile you iTards had to deal with 10.0, 10.1 and 10.2. It wasn't until the Third iteration when Apple finally got their crap together and even then. Apple themselves have admitted that 10.5 is more then anything else an under the hood cleanup of the OS. But you will never admit that Apple was more focused on adding pretty feature to their OS then creating a good OS. Its why I sold my MBP last fall and will NEVER go back. Apple is about flashy stuff. Not about really making a solid foundation. Which for good or ill is what Vista was.
Watch. Snow Leopard is going to have a massive set of bug fixes within 2 month of release.

RE: Ha Ha!
By gstrickler on 8/7/2009 4:29:21 PM , Rating: 2
Apple's retarded move from 10.0 to 10.1 Vista to Win7 took a couple years were it took Apple something like 6 to get to the same damn point
Mac OS X has had 10.0, 10.1 (free upgrade), 10.2, 10.3, 10.4, 10.5, and 10.6. WinNT and descendants has had NT 3.1, 3.5, & 4.0, Win2k, XP, Vista, and Win7. 7 versions of each.

Mac OS X 10.0 is roughly comparable to NT 3.1, each was the first release of a completely new operating system, both were primarily for developers.

Mac OS X 10.1 and NT 3.5 were notable improvements, but still largely for developers and technology fans, not mainstream users or production environments.

Mac OS X 10.2 and NT 4 were the first versions well suited to a production environment. These had fairly stable servers and were heavily used by IT pros and power users.

Mac OS X 10.3 and Win2k were the first versions well suited for mainstream users.

Mac OS X 10.4 and WinXP had significant improvements in security, managability, and user interface. These were widely adopted by mainstream users.

Mac OS X 10.5 is much like Vista, lots of new features and a revamped UI. Both have significantly higher system requirements than their predecessors.

Mac OS X 10.6 is roughly equivalent to Win7, mostly tuning the infrastructure, not as many new features or UI updates.

Both have gone through significant changes in user interface, API, infrastructure, and security in the intervening versions. Both moved from 32-bit to 64-bit. Both originally ran on CPU architectures other than what the now reguire (Mac OS X was originally PPC only, NT originally supported x86, Alpha, Sparc, and MIPS), and both supported multiple processor architectures in some versions. Both provided a compatibility layer for older software.

Mac OS X 10.0 came out in March 2001, 10.6 is due in September 2009. NT 3.1 came out in July 1993, Win7 is due in October 2009. You need to reconsider the timeline.

i went back
By harmaton on 8/6/09, Rating: -1
About fricken time
By scrapsma54 on 8/6/09, Rating: -1
RE: About fricken time
By Smilin on 8/7/2009 12:37:03 PM , Rating: 1
Run the built in memory diagnostics. See if you're getting errors in the upper range.

Be smart, Delay it!
By Nik00117 on 8/6/09, Rating: -1
Nasty to Catastrophic
By XZerg on 8/6/09, Rating: -1
"We are going to continue to work with them to make sure they understand the reality of the Internet.  A lot of these people don't have Ph.Ds, and they don't have a degree in computer science." -- RIM co-CEO Michael Lazaridis

Copyright 2016 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki