Bug in Windows 7 RTM

jimbo45 said:

Hi all

The OP doesn't say if he / she was using X-86 or X-64, whether the processor was dual / quad core, whether RAID was involved, / SATA IDE etc etc.



Cheers
jimbo

I replicated it on 64 bit. Using a dual core, 4GB RAM. My C: drive is a RAID 0 setup, which wasn't affected with the bug. My D: drive, which I managed to replicate it on is just a single 500GB SATA drive. You can see the RAM usage shooting up from the screenshot I posted on the first page of this thread.

Antman said:

I can replicate the phenomenon - 500 GB non-RAID. The "issue" did not present until the free space, stage 5/5, was scanned. Waiting patiently for the crash. 102,nnn,nnn free clusters.

I replicated the issue as soon as the chkdsk begun. The RAM began climbing from the start, then at stage 4 was when it peaked at 89% usage.

There is nothing wrong with a process maximizing its use of available resources, memory or processor, if those resources are not needed by other processes.

In fact it is a waste if the OS does not allow a process acess to idle resources to complete its task as fast as possible. That is the purpose of the resources.

Dynamic "Working Set" allocation has been around since virtual memory OSes were created (i.e. DEC VAX/VMS was amont the earlier OSes)

It is only a problem if a poorly coded process attempts manual working set control and does not relenquish or share resources.

Google "windows working set usage" for more info.

I agree there is nothing wrong with it, but this isn't by design. They have a memory leak. No biggy, they have time to fix it...

Antman said:

The volume is locked. Lower UAC.

Thanks, But no luck. Still getting the Access Denied ?
Iv lowered UAC to 0 and ran cmd using admin

fakeasdf said:

I agree there is nothing wrong with it, but this isn't by design. They have a memory leak. No biggy, they have time to fix it...

Maybe, where is it confirmed it is memory leak?