• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Catastrophic Bug Found in Windows 7

evolucion8

evolucion8

Platinum Member
http://www.dailytech.com/Catas...layed/article15901.htm

"The RTM build -- 7600.16385 -- thus far only received by a handful, features a reportedly massive memory leak in the unassuming, but frequently used program chkdsk.exe.

When scanning a second hard disk (a non-boot partition or second physical drive) using the "/r" (read and verify all file data) parameter the utility starts to leak memory like its a monsoon and quickly runs up a high enough memory debt that it blue screens and crashes the system, according to some (others merely report a memory usage of around 98 percent within seconds, but without the legendary "blue screen of death").

The bug has been confirmed on many different hardware setups --it's been verified to occur on everything from a Intel Atom-based netbook running the 32-bit version, to a Intel Core 2 Duo notebook running the 64-bit version, and a VMware Workstation 6.5.2 virtual machine running the 32-bit version.

Explorer.exe, which runs the utility does not release the excessively large amounts of memory it gobbles up, compounding the problem.

Microsoft is reportedly trying to avoid claiming responsibility, blaming the problem on chipset driver issues and telling users to upgrade their firmware. Yes, that makes absolutely no sense, considering the bug has been verified to exist in VMware. However, that's the current stance Microsoft is reportedly taking."

Interesting...


I experimented the bug myself to see if the issue was true; I plugged a USB Hard Drive in one of my PCs, which has a Via P4M800 chipset, Pentium 4 2.80C, 1GB DDR 400 and 40GB hard drive, and when I used chkdsk /F /R on my USB drive, the chkdsk utility started to eat RAM gradually reaching 640MB of RAM usage and 720MB of page file usage, but strangely enough the PC never crashed. The funny thing is that the issue also happens when you use the Check Disk Utility with the two checkmarks On (Fix File System and Bad Sectors)in Tools option in the Hard Disk properties.

When CHKDSK /F /R is used and then you close the Command Window, CHKDSK will close and the RAM will be released, but when you use the Hard Drive Tools option to access CHKDSK, Explorer won't release the RAM. The only way to release it is killing the Explorer process and turn it back on, that fixed the issue.

There's any other person who can replicate this? Use Non primary hard drives preferably, (secondary, backups, USB etc )

 
Some people say that this doesn't affect most people. Well, I work as a tech and we often pull clients' drives out of their computers and connect it to our benches and run CHKDSK with the /f /r flags and have to be multitasking at the same time. I normally on average do several CHKDSKs per week so that would be a big deal to me. I hope they fix it.
 
It's also a HUGE deal on a server running Server 2008 R2 (assuming the problem exists there, but you'd think so since Win7 and Server 2008 R2 share their code). Imagine the server crashing just because you ran a chkdsk /r on a new hard drive.

And, yeah, I run "chkdsk /r" frequently on both desktops and servers.
 
It isn't a terrible or catastrophic issue like DailyTech believes. I think of that like; MMmm, checkdisk? Nah, checkRAM.
 
It's not good but it's nowhere near catastrophic. For most people running a bad block check via chkdsk is something that they never do. For the few people that do use the bad block checks in chkdsk frequently, yes they might have to find workarounds for a bit but so what?
 
I'd say this is pretty bad if it's easily reproducible as some report. Today non-techie average persons have a more than one drive on a system (counting external stuff), and the possibility of running into Chkdsk message is quite high (compared to other administrative operations). The fact that Chkdsk is readily visible to users in GUI form itself is another example. And remember that these folks run Chkdsk not because they feel like to but because the OS asks them to. It's strange that something like this wasn't caught in the beta testing unless it's really by design.

 
It's not easily reproducible. Tons of people all over the web have been trying and haven't been able to. This only happens on very specific setups. I think it's utterly ridiculous to blame MS in this scenario. Dailytech just posted a sensationalistic article that is way over-reacting.
 
the possibility of running into Chkdsk message is quite high (compared to other administrative operations). The fact that Chkdsk is readily visible to users in GUI form itself is another example. And remember that these folks run Chkdsk not because they feel like to but because the OS asks them to. It's strange that something like this wasn't caught in the beta testing unless it's really by design.
Click to expand...

Bad block checks are disabled by default in all of those cases. The user would have to check the box, which is unlikely as most don't even read dialogs that popup, or run "chkdsk /r" to even have a chance of triggering the bug.
 
Bug is a bug however no reason why Microsoft can't fix it sooner or later via Windows Updates ,hopefully fixed by Oct,also remember Win7 is a brand new OS so we expect there to be a few issues/bugs in the early days.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top