Chkdsk bug in Windows 7 RTM Build 7600.16385/16399

By RushHour2k5
in The Fast Ring (Insider Previews)

 Share

Recommended Posts

Apprentice

RushHour2k5

Posted
Posted (edited)

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
Collaborator

cpressland2

Posted
Posted

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.

Grand Master

fhpuqrgrpgvirzhpujbj

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

Grand Master

Subject Delta

Posted
Posted

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

Grand Master

sanctified Veteran

Posted
  • Veteran
Posted
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.

Mentor

Kalint

Posted
Posted
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!

Neowinian

mike.r.olson

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

Experienced

powerade01

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

Neowinian

mike.r.olson

Posted
Posted

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

Grand Master

Nagisan

Posted
Posted
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.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.