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.

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?

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

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

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.

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.

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

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.

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

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

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.

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.

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.

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

This topic is now closed to further replies.
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.