Software Catastrophic Bug Found in Windows 7 RTM Build, Launch May be Delayed

[Daniel ~]

Written by Daniel
Thursday, 06 August 2009

Just when it looked like Windows 7 was clear to sail to market, a catastrophic bug has been found

Jason Mick (Blog) - August 6, 2009 11:05 AM

The bug reported can blue screen the OS and may result in a delay of the release date. Thus far Microsoft reportedly claims it to be a chipset drivers issue, but testers have found the bug also occurs in VMWare.
Microsoft insists its not to blame.... [Front page...]

[MUff1N]

Yea, I read about that & in the lastest Springboard newsletter I just got they said they are NOT going to delay the launch of W7 at all.
They said that this is a HW dependent problem & has nothing to do with W7 at all.

This I believe as well because of the problems people encounter with this OS.
One has problems while the next works perfectly fine doing the same thing... So...

[Gizmo]

That doesn't prove it's not a W7 problem, only that W7 behaves differently on different hardware.

[skool h8r]

Can confirm that it is actually a really huge leak. Having 4 HDD's, i tested this just now on the smallest drive (160Gb, around 90% full), and within 3 minutes, it was chewing up 1.5Gb of the 4Gb RAM i have installed. At this point, i exited out of it.

[dsio]

0_o

*keeps mouth shut*

[MUff1N]

Originally Posted by skool h8r

Can confirm that it is actually a really huge leak. Having 4 HDD's, i tested this just now on the smallest drive (160Gb, around 90% full), and within 3 minutes, it was chewing up 1.5Gb of the 4Gb RAM i have installed. At this point, i exited out of it.

Then if this bad memory leak is in fact true on RTM build 7600.16835 then this is something I will avoid doing.
I very rarely if ever use checkdisk because I use Acronis True Image instead which works better anyways.

[Gizmo]

Originally Posted by skool h8r

Can confirm that it is actually a really huge leak. Having 4 HDD's, i tested this just now on the smallest drive (160Gb, around 90% full), and within 3 minutes, it was chewing up 1.5Gb of the 4Gb RAM i have installed. At this point, i exited out of it.

According to what I've read, it will actually chew memory up to an amount equivalent to all FREE physical memory at the time of lauch, minus 50 megabytes, but only if you use the /r option.

According to a post by Steven Sinofsky on a user blog, this is by design in order to speed up the repair process. The underlying assumption is that if you've selected the /r option, you'd rather have the chkdsk completed quickly than to wait for it to work in the background (using /r means that you want to repair the disk and recover data from bad sectors; continuing to work on a disk that is being repaired could be not only counter-productive but dangerous).

In other words, chkdsk using a lot of RAM with the /r option is by design (there are also some reports of it occuring with /f, which is like /r but without the bad sector recovery). However, under NO conditions will memory usage grow without bounds. As stated above by Steven Sinofsky, it will use all of available physical memory at the time it is launched, minus 50 MB).

As I don't have Windows 7 and have no plans to get it, I can't report as to the veracity of the above. All I can point out is that, according to Microsoft, it will NOT bring the system to its knees or cause a BSOD.

Now, I think that the whole 'use all available memory' strategy really ought to have a switch to turn it off, but even if the bug is as described, I'd have a hard time calling it a 'show-stopper' because of the circumstances under which it is said to occur.

Just my $0.02.

[Daniel ~]

Thanks for your insight Gizmo!

[ShawnP]

Windows 7 64-bit does like memory if it has it. Just running OCCT it is using 47% of my physical memory. I have 8 GBs.