Chkdsk bug in Windows 7 RTM Build 7600.16385/16399

By RushHour2k5
in The Fast Ring (Insider Previews)

 Share

Recommended Posts

Experienced

fishrman

Posted
Posted

Well the appropriate guys at Microsoft have been notified of the issue, so rest assured that they are looking into it. But if it really is a driver issue, well, that's going to (rightfully) be the hardware vendor's responsibility.

Link to comment
Share on other sites
Apprentice

RushHour2k5

Posted
  • Author
Posted
No, not a showstopper. Kind of like the old Marx Brothers joke: "Doc, it hurts when I do this..."

"Then don't do that!"

I'm pretty sure I can go a day or two without running chkdsk until a patch is applied.

BTW, is this present in both x86 and x64?

This issue is present on non-Patched 7600.16385 and Patched 7600.16399 builds, also on Windows Server 2008 R2, both x86 and x64. My big concern if you read the main post now it is also present when booting from the DVD in WinPE where majority of the IT/PC Repair Industry would go to fix a clients computer.

Well, the appropriate guys at Microsoft have been notified of the issue, so rest assured that they are looking into it. But, if it really is a driver issue, well, that's going to (rightfully) be the hardware vendor's responsibility.

Based on my finding that it is also present when booting directly from the DVD I would say chipset driver issue or not this should not have happened. Also, if it is a chipset drive issue... Why do all 3 of my computers that have Vista on it with the same drivers work fine using chkdsk yet Windows 7 has such a problem?

Link to comment
Share on other sites
Veteran

Deathray

Posted
Posted

This is probably only a bug if the BSOD happens, otherwise I'm sure while they were developing it they knew of the huge memory consumption.

The /r command option says the disk must be locked, so maybe you were running a programming that tried anyways and poof

Link to comment
Share on other sites
Rookie

Ashenfall

Posted
Posted

The fact it's an essential system utility that is potentially used by booting from the original DVD for recovery makes this far more tricky for Microsoft...

Link to comment
Share on other sites
Grand Master

Subject Delta

Posted
Posted
This is probably only a bug if the BSOD happens, otherwise I'm sure while they were developing it they knew of the huge memory consumption.

The /r command option says the disk must be locked, so maybe you were running a programming that tried anyways and poof

Nope, when the disk is dismounted all handles trying to access it are closed, essentially the thread is just killed off. Besides, that would cause high memory usage in the process trying to access the disk, not chkdsk itself

Link to comment
Share on other sites
Grand Master

Chicane-UK Veteran

Posted
  • Veteran
Posted
The /r command option says the disk must be locked, so maybe you were running a programming that tried anyways and poof

Yeah - as Frank Fontaine says, not applicable. I created a brand new 24GB volume in my VMware 'session', copied some random data to it (SQL Server 2008 installer) then dismounted the DVD image and ran the chkdsk. Nothing would have been using that data, but it still insisted on clearing any locks to the filesystem before it attempted to run the check.

Link to comment
Share on other sites
Enthusiast

Andrmgic

Posted
Posted

I'm not sure it is a bug.. I'm running it now and it definitely didn't cause a BSOD.

All of my ram is not being used.. I'm hovering at 80% ram usage.. so the fact that it doesn't take up all of your available memory would seem to indicate that it stops short intentionally.

Link to comment
Share on other sites
Grand Master

Chicane-UK Veteran

Posted
  • Veteran
Posted

I'm willing to lay money on it being some kind of bug. Why would the behaviour of the application change so drastically and with no discernable benefit (quite the opposite!) between Vista and Windows 7?!

Link to comment
Share on other sites
Grand Master

George P Global Moderator

Posted
  • Global Moderator
Posted

This seems kinda odd, why only with the /r command? And if it was a true memory leak you'd keep losing all your memory, I don't think it'd stop at some point/percent. And you wouldn't get it back if you close the app either would you? Don't memory leaks just take it all and never give it back even after, so you have to restart to get it free? That's how I always understood it.

Link to comment
Share on other sites
Grand Master

Subject Delta

Posted
Posted
I'm willing to lay money on it being some kind of bug. Why would the behaviour of the application change so drastically and with no discernable benefit (quite the opposite!) between Vista and Windows 7?!

I'd agree, it is definitely a bug. There is no plausible reason that I could come up with for it using so much memory. For anyone advocating it loading data into memory for performance reasons, just think about it for a second... the /r switch is used to check for bad sectors, a check which would be pointless and invalid if the data where preloaded into memory

Link to comment
Share on other sites
Grand Master

Chicane-UK Veteran

Posted
  • Veteran
Posted

Some more interesting info at another forum which, for some reason, Neowin won't let me link to (edits the url to include << spam >> tags!) - anyway, the guy posted this:

chkdsk /f seems to use 5MB of memory (at peak) for every 1GB of disk space you check (tested on a couple drives - example: a drive with 300GB of data uses 1.5GB of RAM

chkdsk /r seems to use memory equal to the amount of files on the disk. If I put 2.5GB of files on my USB flash drive and use chkdsk /r, it uses 2.5GB of memory by the end of stage 4 (though it stops increasing when you hit stage 5)

He also confirms that this only seems to occur on NTFS (not FAT) and that this appears to be a 64bit only bug...?

Link to comment
Share on other sites
Grand Master

Subject Delta

Posted
Posted

There is still something seriously wrong here. chkdsk in all other NT versions of Windows functioned perfectly without consuming stupid amounts of memory

Link to comment
Share on other sites
Enthusiast

Andrmgic

Posted
Posted

Yeah, I've changed my mind.. definitely a bug.

However, the BSOD seems to be a freak occurrence. My machine is humming along fine while running chkdsk. Definitely not a showstopper.. but weird all the same.

Link to comment
Share on other sites
Grand Master

null_

Posted
Posted

This happens on both 32-bit and 64-bit, however on 32-bit the issue is less apparent because the process can only consume 2 GB of RAM, whereas in 64-bit Windows it will use whatever is available.

Link to comment
Share on other sites
Rookie

MerChan

Posted
Posted

Surprisingly build 7600.16399 is faster than 7600.16385 on cpu operations. Confirmed with faster boot and playing a "heavy" cpu game. As for bugs, I still can drag the locked taskbar to the top by performing this: first, right click on any taskbar icon to open the jumplist then drag the taskbar up a little and it will move to the top. Another bug is when the taskbar is on top, if you do right click, the jumplist will have incorrect top position, but if you drag the jumplist, the top position limit will be the right one.

Link to comment
Share on other sites
Mentor

Salty Wagyu

Posted
Posted

Will the fix be on WU on release though? MS have always waited until a service pack to fix bugs and only used WU for security updates.

Sorry haven't read whole thread, only first page then replied.

Link to comment
Share on other sites
Grand Master

Subject Delta

Posted
Posted

A fix for a bug this big won't be delayed until a service pack, but unfortunately it will still exist on the DVD until slipstreamed SP1 images come out

Link to comment
Share on other sites
Community Regular

vladmphoto

Posted
Posted

This is a pretty serious bug, however, in my opinion not serious enough to cause a re-packaging of the RTM code. It can easily be fixed through windows update.

Link to comment
Share on other sites
Mentor

Klownicle

Posted
Posted

Heres a couple things I found sad.

1. Those 399 build updates are not official, unless its on Microsoft update or a official announcement is made, I'm not touching them.

2. Microsoft hasn't even mentioned anything about this officially yet.

3. According to Microsoft the RTM build is still coming to MSDNAA today, no mention of a show stopper or recompile etc.

4. This is not a chipset issue, chkdsk uses too much memory. And the 399 unofficial fixes do not fix it. When something is broken on all versions of different hardware, its not the hardware's fault, its the software.

Link to comment
Share on other sites
Experienced

Panda X

Posted
Posted
Heres a couple things I found sad.

1. Those 399 build updates are not official, unless its on Microsoft update or a official announcement is made, I'm not touching them.

2. Microsoft hasn't even mentioned anything about this officially yet.

3. According to Microsoft the RTM build is still coming to MSDNAA today, no mention of a show stopper or recompile etc.

4. This is not a chipset issue, chkdsk uses too much memory. And the 399 unofficial fixes do not fix it. When something is broken on all versions of different hardware, its not the hardware's fault, its the software.

1. They are. Never heard of an unofficial hotfix from MS.

2. Not publicly. Why would they? They could potentially harm their sales by going "There's a big bug in our final product."

3. Of course not. Again, why would they? Not everyone has the issue.

4. It has been proven.

Link to comment
Share on other sites
Grand Master

neufuse Veteran

Posted
  • Veteran
Posted
Has anyone been able to post this on Microsoft Connect? They dont have a public channel for Windows 7? This should be resolved as soon as possible!

Connect is closed to bug submissions now for Windows 7.... have to get to MS other ways now, anything that goes to connect wil get to no one

Link to comment
Share on other sites
This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.