Critical bug found in Windows 7's RTM build... details inside

Joe Average

Ad Blocker - Banned
Joined
Apr 6, 2008
Messages
15,459
Well, I don't consider it a MAJOR MAJOR earth-shattering bug as it's a specific one but, even so, it does exist on both the machines I currently have Windows 7 on. I'll say they're both running a certain version of Windows 7 x64 and leave it at that. Now, about that bug...

If you open an Admin Command Prompt, and issue the following command:

chkdsk <driveletter>: /r

it seems as if chkdsk just goes a bit bonkers in terms of memory usage but only on non-system drives - my system drive is C:, and the command works fine on it, but on non-system drives, internal, external, it doesn't matter, formatted with NTFS, it goes a bit insane. How insane? Well, here's what it looked like after just running the command for 30 seconds (then killing the process):

chkdskbug.png


So, it's worth checking out if you happen to be running a certain version of Windows 7 x64, at least. I do believe the issue exists in both x86 and x64 versions, but I can't verify that as I only use x64 versions.

It doesn't affect the system drive, as noted, and it does not affect FAT/FAT32 drives either. But I tested it on my secondary partition as well as a 160GB NTFS-formatted external USB drive and it happens regardless, just not on the system partition C:. It occurs when chkdsk hits Stage 4 - that's when you'll really see the RAM usage skyrocket fast. If the process is allowed to continue, it will consume all the RAM you've got, and finally end with a BSOD because of RAM issues.

So... just a heads up. This exists in the 16385 RTM build as well as the "patched" 16399 build patches (these will appear on Windows Update soon enough and they have a curious side effect of updating the build number for a variety of reasons and the associated files).

A lot of folks are all over this currently and calling it a "showstopper" but I wouldn't classify it as such. Yes, it can bring down the system from operation, but in my experience showstoppers are bugs/glitches that have instant "triggers" that can be replicated and cause an instant BSOD - hence it "stops the show" pretty much in the blink of an eye. I'm old, sue me... we old folks prefer the old definitions of such events... :D

Good luck, and be careful if you have some reason to run chkdsk on NTFS-formatted non-system drives with the /r option.

Edit:
Updated reports state that some users experience almost complete RAM usage but no BSODs - most of those who report BSODs are on machines with 4GB of RAM or less. Even so, watching chkdsk suck down 7GB of RAM on an 8GB machine is a bit disconcerting, and it could still cause further issues so... we'll see what happens. This may not be that important to a majority of folks, but for enthusiasts, and especially for technicians working on client or corporate machines (testing, of course) that may be required to use chkdsk on drives this could be a potential issue.
 
Last edited:
If this is a bug then Microsoft should be aware of it. It's in the RC, bet its in the beta. Of course it should be reported but I have to imagine that this isn't unkown.
 
I never had occasion to use chkdsk on my Windows 7 RC install. While I'm sure some others did, how many of those were watching their memory consumption? And how many of those filed a bug report?
 
I never had occasion to use chkdsk on my Windows 7 RC install. While I'm sure some others did, how many of those were watching their memory consumption? And how many of those filed a bug report?

I would think that EVERY feature in Windows gets automated testing. This is way too easy to reproduce to have gone unnoticed.

I've got this still running, the memory usuage has not budged from the screen shot but its slow as hell. The disk I'm checking is a USB drive. JA said it didn't effect system drives. Don't have any non-USB drives other than my system. I have a feeling that this is a USB thing as USB subsystem was rewritten in 7.
 
Well this chkdsk did complete but it took what seems to be a lot of time, over an hours, I don't know exacctly how long because I was asleep. I'll try it again and time it.
 
Yesterday I ran a checkdisk on my 120GB USB hdd. It used over 3.3GB of ram while scanning it. I didn't think anything of it. The system was still very responsive and it released the memory when it was done. I don't see the big deal.
 
Damn MS, I'm canceling my pre-order!!!!*







*If you don't understand why this is funny, sorry.
 
Yesterday I ran a checkdisk on my 120GB USB hdd. It used over 3.3GB of ram while scanning it. I didn't think anything of it. The system was still very responsive and it released the memory when it was done. I don't see the big deal.

I didn't notice any performance issues either. To me the problem was performance, its seemed very slow. I'll try this in Vista on the sig rig and compare.
 
I'll check out if it does the same on my system when I get home from work. Specs are in sig.
 
hey thanks Joe, im going to confirm it and file a bug against whoever owns chkdsk when i get to work this afternoon.

but wow chkdsk is something i have never even run in win7, i think ill check out server 08 R2 while im at it.
 
So you're running chkdsk on non system drive while Windows is running. Plus you've got Firefox and Y IM running which may be contributing to the bug.

Normally when I run chkdsk it is during a system reboot so this may not be a big issue if the problem doesn't occur during a reboot.
 
The official release isn't till October, this will be patched and thrown up onto windows update with-in a week or two most after the August 6th MSDN/Technet aviailty, It happens guys, and it will be patched before general availability.

Don't blow this out of proportion.
 
So you're running chkdsk on non system drive while Windows is running. Plus you've got Firefox and Y IM running which may be contributing to the bug.

Normally when I run chkdsk it is during a system reboot so this may not be a big issue if the problem doesn't occur during a reboot.

I'm pretty sure additional programs would NOT contribute to chkdsk eating up a TON of ram.

FYI, it's kinda hard to check chkdsk's memory usage when chkdsk is run at bootup. Since you can't do anything while it's running :rolleyes:
 
I usually run chkdsk on the next reboot, and I have not had any issues that didn't prevent the scan from finishing and the computer booting normally afterward.
 
The official release isn't till October, this will be patched and thrown up onto windows update with-in a week or two most after the August 6th MSDN/Technet aviailty, It happens guys, and it will be patched before general availability.

Don't blow this out of proportion.

This title is bad, not like JA. There may be a bug here but fdisk runs, doesn't kill system performance. It's just slow but I'm not sure just how fast it should be. The memory usage isn't a big deal.

Also, has anyone run this on a non-system drive that ISN'T attached via USB?
 
My D: drive would be perfect to test this on but it has my page file on it so Windows won't dis-mount it to run chkdsk.

My 4GB flash drive does seem to show the problem but chkdsk.exe's memory usage only jumps to around 30MB before the process finishes. I'll fill it with data and try again.

Running 16399 btw.

EDIT

O yea, its there and its a whopper.
Untitled-84.png
 
Last edited:
Critical bug? Fuck me!

I cannot even remember the last time I ran a chkdsk /r on any drive whatsoever. I suspect it might've been back in Windows 98 days!

If a hard drive begins to show signs of errors or potential errors I run hardware manufacturer diagnostics on it, and if those confirm that the drive is suspect I ditch the bloody drive.

Oh, and if there's data to be recovered/lifted off the drive I use data recovery software tools, not chkdsk.

:D
 
Well excuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuse me for passing on the info, sheesh. :D

I found it on another site and decided to share the info here, as I'm sure someone else would have gotten around to; I just happened to catch it early on, that's all. If you're not having issues, if you don't use chkdsk on a non-system partition with the /r option, then I guess you're all fine and dandy.

It is classified as a critical issue because it can cause BSODs, I suppose. I saw mention of it on some reports I read this morning from inside channels (that's in Redmond, yanno) and they're aware of it, and a hotfix/QFE will be issued probably as soon as Friday to address it because of the MSDN/TechNet release, potentially even as early as Thursday to coincide with those releases.

But I'm not the one that discovered this, I'm just the messenger... :p

I usually run chkdsk on the next reboot, and I have not had any issues that didn't prevent the scan from finishing and the computer booting normally afterward.

The "chkdsk" that runs pre-loading of the OS isn't the same as the chkdsk you execute within Windows when it's in operation, hence it doesn't suffer from this issue apparently.

chkdsk.exe = The chkdsk you run manually from a Command Prompt as required.

chkntfs.exe = The chkdsk that runs pre-loading of the OS on a reboot if necessary or scheduled.

This issue lies with the chkdsk.exe executable, it seems.
 
Well excuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuse me for passing on the info, sheesh. :D

I found it on another site and decided to share the info here, as I'm sure someone else would have gotten around to; I just happened to catch it early on, that's all. If you're not having issues, if you don't use chkdsk on a non-system partition with the /r option, then I guess you're all fine and dandy.

It is classified as a critical issue because it can cause BSODs, I suppose. I saw mention of it on some reports I read this morning from inside channels (that's in Redmond, yanno) and they're aware of it, and a hotfix/QFE will be issued probably as soon as Friday to address it because of the MSDN/TechNet release, potentially even as early as Thursday to coincide with those releases.

But I'm not the one that discovered this, I'm just the messenger... :p



The "chkdsk" that runs pre-loading of the OS isn't the same as the chkdsk you execute within Windows when it's in operation, hence it doesn't suffer from this issue apparently.

chkdsk.exe = The chkdsk you run manually from a Command Prompt as required.

chkntfs.exe = The chkdsk that runs pre-loading of the OS on a reboot if necessary or scheduled.

This issue lies with the chkdsk.exe executable, it seems.

Well I hope you know that some us appreciate the info I did!;)
 
FWIW Joe, I never saw the RAM usage go above 2.7GB while checking a 4GB flash drive that I filled with data. Its like it hit a cap.

Can someone with a larger drive to test see if this is the case with all drives or just a 4GB drive?
 
Well excuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuse me for passing on the info, sheesh. :D

heh heh...

Definitely aiming directly at the message and not at the messenger mate. Just saying that it's one of those "Shit! That's about the most pointless thing ever!" kinda things :)



(And yeah. I saw it on blogs yesterday, by the way.)
 
FWIW Joe, I never saw the RAM usage go above 2.7GB while checking a 4GB flash drive that I filled with data. Its like it hit a cap.

Can someone with a larger drive to test see if this is the case with all drives or just a 4GB drive?

If you look at my previous posts I found that the memory capped at around 1.3 GB scanning a 250GB USB portable HD.
 
A bug? Seems that way. But can it crash the system? Is it a security hole? No? Then it's not even close to "critical".

Besides, who the heck still runs CHKDSK? I haven't touched that since Win98.
 
Besides, who the heck still runs CHKDSK? I haven't touched that since Win98.

Internally reported 'drive consistency' errors can trigger chkdsk to run on startup, to determine and report on drive integrity.

Just a point of petty, pedantic detail of course, because that check runs on the system drive and is thus not relevent to this reported 'bug'. But under certain specific circumstances you can actually be firing up chkdsk simply by virtue of the act of powering up your Windows box. :)
 
System administrators, I.T. personnel, bench techs, etc etc... a lot of people use chkdsk because it's there, it's built in, it performs all the functions necessary to get the job done, and not many third-party tools can do a better job, realistically.

As noted, just because a few of you don't use chkdsk doesn't mean several million others of us don't as well. I do, on a regular basis when testing out drives suspected of some data corruption or access issues. Never found anything that works as well - and don't mention things like SpinRite, etc because those tools don't have anything to do with the file system realistically. They do their work with the raw sectors on the platters, and other tools like S.M.A.R.T. status and hardware monitoring don't have anything to do with the file systems either.

chkdsk has a purpose, and for that purpose, this is a critical bug for those of us that use chkdsk on a regular basis.
 
Internally reported 'drive consistency' errors can trigger chkdsk to run on startup, to determine and report on drive integrity.

Just a point of petty, pedantic detail of course, because that check runs on the system drive and is thus not relevent to this reported 'bug'. But under certain specific circumstances you can actually be firing up chkdsk simply by virtue of the act of powering up your Windows box. :)

And again it needs to be reiterated that the check disk functionality that happens at startup before the OS itself actually loads is NOT the chkdsk with this bug; that is chkntfs and it's specific purpose is to run at startup/pre-load of the OS/as required on a dirty volume at boot time.

Two different executables, one with the bug, the other one isn't affected at all.
 
Critical bug? Fuck me!

I cannot even remember the last time I ran a chkdsk /r on any drive whatsoever. I suspect it might've been back in Windows 98 days!

If a hard drive begins to show signs of errors or potential errors I run hardware manufacturer diagnostics on it, and if those confirm that the drive is suspect I ditch the bloody drive.

Oh, and if there's data to be recovered/lifted off the drive I use data recovery software tools, not chkdsk.

:D

Same here. I haven't run chkdsk in years. But I definitely agree this is a major bug since so many people do use it
 
I guess we just really want MS too be perceived well this time, and for us not have to deal with the "Vista sucks" crap all over again. Or maybe that's just me. :p

Pretty much the reason, its a bug, perhaps its critical one even, but its not a showstopper, nor does it need to be shouted from the rooftops.

It's a minor issue, a minor bug that affects almost no one, and will be fixed/patched LONG before general availability, most likely before the end of next week. Is it a critical bug(can cause BSOD in certain, specific cases), perhaps, but not a major bug, nor should it be turned into a PR destroying campaign.
 
I cannot even remember the last time I ran a chkdsk /r on any drive whatsoever. I suspect it might've been back in Windows 98 days!

If I remember correctly then Win98 never used chkdsk and used another HDD utility called smartdsk or something like that.

Minor issue or not. How on earth did this slip through testing? No one ran chkdsk /r until now? Wow, you beta testers are really thorough. I'm cancelling my Win7 pre-order for sure now!
 
If I remember correctly then Win98 never used chkdsk and used another HDD utility called smartdsk or something like that.

Minor issue or not. How on earth did this slip through testing? No one ran chkdsk /r until now? Wow, you beta testers are really thorough. I'm cancelling my Win7 pre-order for sure now!

I know your being sarcastic but.... with hard drive sizes being so tiny these days and network storage being used for day to day stuff, secondary partitions are scarce in my world so scanning anything other than c: didn't occur during testing. And I do use chkdsk daily on at least one of the thousand machines here.
 
My computer has 2.5 TB using 3 HDDs and there are 4 partitions (C: is kept to 100GB to make imaging OS more managable) and that is a pretty common configuration these days for gamers.
You have to get your head out of thinking the only configuration around is the typical business config.

Beta testers are supposed to try and break the system by doing all kinds of weird things that the everyday user may not do so you guys failed as beta testers IMO. If Microsoft wants a real useful beta tester that only works for money and uses a game config then PM me.
 
My computer has 2.5 TB using 3 HDDs and there are 4 partitions (C: is kept to 100GB to make imaging OS more managable) and that is a pretty common configuration these days for gamers.
You have to get your head out of thinking the only configuration around is the typical business config.

Beta testers are supposed to try and break the system by doing all kinds of weird things that the everyday user may not do so you guys failed as beta testers IMO. If Microsoft wants a real useful beta tester that only works for money and uses a game config then PM me.

How's your configuration the common one? Some people just slap in two disks and leave it at that. Some slap two discs in RAID 0 or RAID 1 or RAID 10 and leave it at that. For gamers there is NO common configuration.

More and more people use vendor tools to check their disks. I haven't touched chkdsk in years because of the vendor tools. Not to mention somebody like me with 8GB of RAM probably wouldn't have seen the problem as Joe stated earlier. Also not everybody even sees the issue.

Questions for everybody else:

Does it require two hard disks? Is this limited to the x64 version of Windows?

In my work laptop I only have 2GB of RAM. I partitioned the drive when I installed Windows 7 x86 Build 7100 a few months ago. I cap out at about 1.3GB RAM when running the chkdsk /r on the D: partition. Anybody see the same thing with a partitioned drive not having the issue?
 
System administrators, I.T. personnel, bench techs, etc etc... a lot of people use chkdsk because it's there, it's built in, it performs all the functions necessary to get the job done, and not many third-party tools can do a better job, realistically.

Exactly. i save company laptops with non-bootable hard drives on a daily basis with chkdsk /r.
 
Just tested it out on my RC install and it exist, only happens when you use the /r option. I would have to agree that this pretty critical because its doesn't take much to write a malicious script to run a background chkdsk /r and before you know it you have users PCs blue screening or ram overheating left and right and shutting down PCs.
 
Back
Top