Please read our Community Guidelines before posting in this forum.
POLITE NOTE: Please be courteous to all members. We are here to help. Flaming, Spamming, Advertising, and unnecessary signatures will NOT be tolerated. Graphic Material/Content, Swearing/Cursing, Verbal Abuse, and Warez will NOT be tolerated.
Group: Members
Posts: 2
Joined: 12-June 04
Member No.: 25,409
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.
Confirmed. And yes this should be considered a showstopper. chkdsk killing a machine is not cool as there are real world uses for that tool.
I definantly 2nd that Chris123NT. Also, if "chkdsk" can crash a computer by BSODing it during a fix that "chkdsk" might be performing it can perminantly delete or render data unusable on the drive it is running on. This is 100% a Critical Show Stopper bug that IMO needs to have the RTM recalled and recompiled before the TechNet/MSDN copies go live and at least a Hotfix for the OEMs to impliment in System Recovery.
This post has been edited by pilot76103: Aug 4 2009, 12:08 PM
Group: Members
Posts: 2
Joined: 17-January 04
From: Redmond, WA
Member No.: 14,822
You've got to be kidding. Showstopper?
If you open up a command-line utility, direct it to check a secondary disk (a primary disk will wait until boot time to get exclusive access) only to have it suck all memory and crash!?!
I'm not saying this isn't a clear bug, but tell me how many non-geek people are in the command-line in Win7, have a second disk and choose to run CHKDSK on their secondary drive while in the Windows interface and I'll show you 0.006% of the customer base.
Embarrassing bug, yes. Showstopper, no.
This post has been edited by dugn: Aug 4 2009, 08:50 AM
Group: Members
Posts: 2
Joined: 12-June 04
Member No.: 25,409
Updated main post in regards to "chkdsk" memory leak being present when booting directly from Windows 7 DVD into WinPE. Yes, I still consider this show stopper. The ISOs for TechNet, MSDN, and GA need to be patched so this issue is not present in WinPE!
Group: Members
Posts: 2
Joined: 12-June 04
Member No.: 25,409
From the Microsoft Connect forums for Office 2010 in regards to the "chkdsk" bug.
QUOTE
Try reproducing this bug before complaining. I haven't been able to and neither has Microsoft. Keep in mind Neowin gets news very quickly but that comes at a downside. News postings can be modified and rectified as more information comes out. The "more information that came out" indicates that this bug is not a showstopper. It's is not critical because first it doesn't happen very often, even MIcrosoft cannot reproduce the bug, and second, no data is being corrupted or lost. If you need to chkdsk, do it from the recovery CD, not from windows. I mean it'll be so much easier doing from the recovery environment because you don't have to dismount the drive you want to check. It's a non-issue that isn't urgent. Let me ask you, have you tried reproducing this bug? You'll help the windows engineering team more by reproducing it and providing instructions on how to reproduce it rather than ranting about it on here. I'm sure they already know about it.