Chkdsk bug in Windows 7 RTM Build 7600.16385/16399

[RushHour2k5]

A critical show stopper bug has been found in the Final Windows 7 RTM 7600.16385 and in the updated 7600.16399 builds on both 32-bit (x86) and 64-bit (x64) installs! Thanks to mikerolsonw7c of Windows7Center for informing us of the critical bug. The issue is related to the "chkdsk /r" command on a NTFS drive other than the system drive (Issue not present for FAT32 Drives). 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.

UPDATE: This issue is also present if you boot from the Windows 7 RTM 7600.16385 DVD and run "chkdsk /r" from WinPE. Also, reported that this issue is present on Windows Server 2008 R2.

Edited August 4, 2009 by pilot76103
Title edited, please do not use all caps

[Simon Veteran]

Is that really a showstopper? Surely could be fixed very quickly by a patch through Windows Update.

Can anyone else even verify that this is true?

[cpressland2]

Source?

CHKDSK /R *any drive* on build 6.1.7600.16384 works fine without any memory leaks.

[bryonhowley]

Have tried on several of my drives no problems at all.

[neufuse Veteran]

you sure you dont just have hardware problems? works fine here with no problems on a multi terrabyte array

[cpressland2]

Yeah, I think it's pretty safe to say that if this IS a real issue, Microsoft will patch it with Windows Update.

Odd, I think I read somewhere that people are already getting Windows Updates coming through, I've only had Windows Defender updates so far.

[fhpuqrgrpgvirzhpujbj]

This guy is just looking for attention. I just tried on an external drive and another partition on my main drive, no problems.

[Argi]

Sounds like all that's required in a rather small patch. :sleep: (if it's even broken, and not just a specific issue)

[RushHour2k5]

This guy is just looking for attention. I just tried on an external drive and another partition on my main drive, no problems.

Believe me I just tested on x86 and x64 it is present. It is only for NTFS drives not FAT32.

[Lord Ba'al]

Nasty... they should've fixed that before sending it off.

[fhpuqrgrpgvirzhpujbj]

Believe me I just tested on x86 and x64 it is present. It is only for NTFS drives not FAT32.

You really think I would have any FAT Drives? They're both NTFS, and I had no problems.

Also, from a programmer's standpoint, this would make no sense. What variable or resource would need to be created/looped completely separately from that of doing this to your C:\ drive? Enumerations of files and drives would be the same in both. This is either fake, or specific to you.

[Subject Delta]

Confirmed. Memory usage also rises alarmingly quickly, climbed to the level shown in the screenshot in about 45 seconds (I have 8GB of ram).

Pretty serious bug this, amazed it skipped through quality control, although when you close chkdisk memory usage returns to normal

[mike.r.olson]

I can assure you that I am not attempting to gain attention by posting a legitimate bug I have found and verified on 2 of my personal machines, both running 7600.16385 x64.

[sanctified Veteran]

I can assure you that I am not attempting to gain attention by posting a legitimate bug I have found and verified on 2 of my personal machines, both running 7600.16385 x64.

Dont worry, it has been confirmed by more than one.

[Kalint]

You really think I would have any FAT Drives? They're both NTFS, and I had no problems.

Also, from a programmer's standpoint, this would make no sense. What variable or resource would need to be created/looped completely separately from that of doing this to your C:\ drive? Enumerations of files and drives would be the same in both. This is either fake, or specific to you.

lol really! IDK anyone who uses fat anyone Except that guy!

[ManMountain]

I can duplicate this bug as well.

Edited August 4, 2009 by ManMountain

[RushHour2k5]

UPDATED main post with screenshot for proof.

[mike.r.olson]

This guy is just looking for attention. I just tried on an external drive and another partition on my main drive, no problems.

Wow, look at the screenshots. Amazing that somebody who is only "looking for attention" can manage to get proof of his claims and not be the only one finding the bug. I guess we're all just looking for attention.

Seriously though, does anybody have any ideas as to a possible workaround for fix until we get an official hotfix from Microsoft? One person I spoke with attempted to copy chkdsk.exe from Vista x64 to 7 x64 and chkdsk would crash immediately.

[cpressland2]

Well, again, no sign of it on my rig. How odd, I wonder if this would also apply if scanning the drive during boot?

[Kalint]

Okay instead of information us. GET on Microsoft Connect and report it!!!!!!!

[+Elі Subscriber²]

Yeap, confirmed here too, though I wouldn't necessarily call it a showstopper bug :p

[powerade01]

Confirmed. Memory usage also rises alarmingly quickly, climbed to the level shown in the screenshot in about 45 seconds (I have 8GB of ram).

Pretty serious bug this, amazed it skipped through quality control, although when you close chkdisk memory usage returns to normal

I can assure you that I am not attempting to gain attention by posting a legitimate bug I have found and verified on 2 of my personal machines, both running 7600.16385 x64.

First, both of you post exact hardware specs. Lets see if we can find something in common.

Second, I dont believe this bug at all. I think it has to do with certain HW/SW configs. Note that the first guy (with screenshots) gets a BSOD and the second does not.

(My opinion)

[mike.r.olson]

Machine 1 is a Dell Inspiron 1521 Laptop (AMD X2 TL-58, 4GB DDR2 RAM, WD Scorpio Black Hard Drive, ATI x1200 series graphics).

Machine 2 is a Dell XPS 420 (Intel Q6600 OC'd to 3.0GHz, 8GB DDR2 RAM, WD Caviar Blue Hard Drives 640GB & 1TB, ATI HD2400 Pro graphics).

[ManMountain]

My machine specs in sig.

[Nagisan]

Well, again, no sign of it on my rig. How odd, I wonder if this would also apply if scanning the drive during boot?

You are not running the exact builds that its happening on. Despite your theory of "nothing major happening between 84 and 85", something major enough happened to draw out this bug.

I can confirm it happens on 16399 x64 as well on my system.

EDIT: Specs:

Q6700 @ 3.8Ghz

4890 Toxic @ 1000Mhz core/1125Mhz mem

4GB DDR2 Ram @950Mhz (rated to handle up to 1000Mhz)

120GB SSD System Drive (C:)

500GB 7200RPM HDD (D:)