Chkdsk bug in Windows 7 RTM Build 7600.16385/16399


Recommended Posts

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.

windows7bug.th.png

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.

win7pebug1.th.jpg

win7pebug2.th.jpg

win7pebug3.th.jpg

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

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.

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.

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

post-286512-1249353407_thumb.png

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.

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!

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.

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)

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).

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:)

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.