Linked by Thom Holwerda on Fri 7th Aug 2009 20:10 UTC
Windows Earlier this week, we had a page 2 item about a possible showstopper bug in Windows 7 and Windows Server 2008 R2, but as I could've probably guessed by taking my time before posting said item, this bug has been way overblown and is anything but a showstopper. Steven Sinofisky himself responded to the bug by commenting on the blog.
Order by: Score:
Yup
by mrhasbean on Fri 7th Aug 2009 22:06 UTC
mrhasbean
Member since:
2006-04-03

...but as I could've probably guessed by taking my time before posting said item...


Nice to see the corrections posted over the past few days too...

Reply Score: 2

No not a show stopper
by OSGuy on Sat 8th Aug 2009 03:11 UTC
OSGuy
Member since:
2006-01-01

/R Locates bad sectors and recovers readable information (implies /F).

But an unsuspecting technician can run chkdsk with this option. Has anyone tried if this produces a similar effect when you run it of the Windows CD when you boot from it as a recovery tool?

Edited 2009-08-08 03:17 UTC

Reply Score: 3

RE:
by malxau on Sun 9th Aug 2009 02:12 UTC in reply to "No not a show stopper"
malxau Member since:
2005-12-04

As I indicated in the previous story, the bug here is a bugcheck, not memory consumption. Upon further investigation, we have identified multiple chipset drivers that can cause bugchecks, but this is rare (affecting around 1% of the install base of drivers.)

This may affect a WinPE boot if the driver is installed in WinPE (which it probably isn't.) If it is, you may need to generate a patched WinPE with a patched driver in order to run chkdsk /r on an affected machine.

But the point to stress is the probability of having bad chipset drivers is still quite low. Hopefully one outcome of this debacle will be manufacturers testing the error paths of chipset drivers more thoroughly.

(Another outcome may be to remove/disable/hide/scale back caching to satisfy some of the less educated elements of the Internet by ensuring memory consumption is not overly visible. This will hurt the majority of users who currently benefit from the aforementioned caches. It is sad that such engineering tradeoffs are being made/influenced by uneducated opinions.)

Reply Score: 1

Memory usage monitoring
by gustl on Sun 9th Aug 2009 17:49 UTC in reply to "RE: "
gustl Member since:
2006-01-19

In Linux (actually KDE3), if you open the system monitor, you get a memory usage graph which shows how much memory is in use by the system (in red), undiscardable user memory (in blue) and cache memory (in yellow).

On low-memory machines (500 MB RAM) you can see the memory being utilized fully after some time of usage, most of it being cached.
In this way the user gets the feedback "all is well", the memory monitor not lying to the user (by displaying only system + user memory), and the system taking full usage of the memory.

On windows XP it always made me nervous, when I saw Windows starting to swap out memory when the physical memory was not yet full.

Memory should be used, that is what it's here for, Microsoft should NOT slow down the machine to needlessly save memory.

Reply Score: 2

One show stopper....
by leech on Sat 8th Aug 2009 23:20 UTC
leech
Member since:
2006-01-10

Should be the problem with sound.

I don't know if it's the way the sound initializes and de-initializes, but I never had this issue before Windows 7.

Basically when you first load up Windows 7, then you try to play a game in 5.1 sound, the center and surround channels have no output.

So every time I boot up, I have to go into the sound hardware configuration, change it back to Stereo, run the test, then change it back to 5.1 and then run the test again. Then it works properly (well most of the time).

But then the other day, the exact same thing happened to Linux, though at first I thought it was because I still have two sound cards in my computer (I have an Audigy 2 Platinum and the onboard sound) only because of having these weird sound issues in Windows 7.

I can only think that it somehow is initializing the sound wrongly when it first loads up, but then it does that same initializing when it is rebooted.

This SHOULD be a show stopper, especially since it affects the multimedia capabilities of the OS.

Granted I've only tested it why my hardware, but it does do it with both sound cards.

The only other issue I've had with it, is that I have it installed on my Touchsmart with the multi-touch. For whatever reason it keeps randomly making the sound of hardware being removed. The only thing I can think of is that somehow the touchscreen is being initialized differently than it expects. The reason I am thinking that, is because depending on if you run Vista or Windows 7, the pci bus location of the touchscreen is different! (2:1:0 if I recall for vista, and 2:1:1 for 7) Only know this because I dual-boot Ubuntu on it.

These are things that people will notice. I don't know who would be running Chkdsk from within Windows anyhow, I always run it from a boot disk.

Reply Score: 4

RE:
by OSGuy on Sun 9th Aug 2009 00:52 UTC in reply to "One show stopper...."
OSGuy Member since:
2006-01-01

I don't know who would be running Chkdsk from within Windows anyhow, I always run it from a boot disk.

Yeah same, hence my question above. Will that not explain than if it is a chipset incompatibility issue? If it is than we should get the same issue even when running it of the boot CD. This means it would be wise to keep your old Vista CD since it would be the only way to run chkdsk properly. Well you can do it with XP too but with Vista you get full NTFS support through the command shell + utilities such as bootrec that would fix your booting should a foreign boot loader corrupt your Windows boot loader. I used bootrec /rebuild (I think) or something like that to fix my laptop's Vista/7 loader.

Edited 2009-08-09 00:59 UTC

Reply Score: 2

RE:
by Karitku on Sun 9th Aug 2009 08:23 UTC in reply to "RE: "
Karitku Member since:
2006-01-12

Sigh did you guys read the article? They improved chkdsk to USE memory to gain SPEED. Only bug is in those rare cases where this causes BSOD, AGAIN in all cases highly increased memory usage is INTENDED behavior.

And yes it happens in recorvery mode also because it's the same chkdsk.

Why would you want to run older tools that are slower if you wont be using machine anyway since you are suspecting it has HDD failure, there is no other reason to run chkdsk with /r.

If you have ever run chkdsk in server you know how much time it takes (days not hours) so I cheer Microsoft for improving such a rarely used tool.

Reply Score: 1

RE:
by Karitku on Sun 9th Aug 2009 18:36 UTC in reply to "One show stopper...."
Karitku Member since:
2006-01-12

Leech: OMG someone call Randall Kennedy there is another bug! And it's infesting like 0,1% users, call the Obama, call the Greenpeace. Also Puppet Walt Mossberg is reporting some other problems. http://www.youtube.com/watch?v=Xdn0AmdXsGg

Reply Score: 1

RE[2]:
by leech on Mon 10th Aug 2009 02:20 UTC in reply to "RE: "
leech Member since:
2006-01-10

Yeah, and I'm sure that there is only .1% of all people that use more than just stereo speakers....

Or for that matter there is only .1% people that use their computers as media centers. If that were the case, then I'm sure Microsoft would have never bothered developing the Windows Media Center.

Reply Score: 2

Mr Windows has more on the Win7 blog
by griffinme on Mon 10th Aug 2009 17:41 UTC
griffinme
Member since:
2005-11-09

http://blogs.msdn.com/e7/archive/2009/08/10/what-we-do-with-a-bug-r...

He talks about the process of bug tracking and how surprised he was at the reaction to his comments on a blog being news.

Reply Score: 1