backtop


Print E-mail del.icio.us 81 comment(s) - last by MrPoletski.. on Aug 11 at 6:40 AM


The new Windows 7 RTM bug isn't as show stopping as originally believed. It likely falls under the category of avoidable annoyance. Nonetheless, Windows 7 President Steven Sinofsky says the team is hard at work looking for a solution.  (Source: ZDNet)

Don't check the second option -- we warned you. That's the bugged chkdsk option (which is unchecked by default).  (Source: ZDNet)
Bug isn't as bad as initially believed, Microsoft is taking steps to fix it

There's a big new bug in Windows 7, a memory leak found in the Windows 7 RTM.  While it takes a somewhat specific -- though not entirely uncommon -- sequence of commands to trigger, it can hog all the system's memory and reportedly has crashed some systems -- even producing, reportedly, the infamous blue screen of death.

First a followup on the bug.  The bug is in the chkdsk.exe, a long standing Windows utility that allows you to check and repair your disks.  In order to activate the bug you must run the utility and then choose the -R option from the command line or the "Scan for and attempt recovery of bad sectors" on the GUI (not the default option).  The bug only occurs when scanning secondary disks or partitions -- something a lot of users don't even have.

While this is a bit of a problem for system administrators, it now appears that the bug isn't as bad as was initially believed.  Microsoft's newly appointed Windows President Steven Sinofsky took the unusual step of responding to one blog discussing the problem, Chris123NT.  As Mr. Sinofsky points out, "While we appreciate the drama of 'critical bug' and then the pickup of 'showstopper' that I’ve seen, we might take a step back and realize that this might not have that defcon level. Bugs that are so severe as to require immediate patches and attention would have to have no workarounds and would generally be such that a large set of people would run across them in the normal course of using their PC."

This is definitely a valid point.  There have been such bugs in past Windows OS's -- such as the Windows Home Server bug that corrupted data occasionally on a variety of normal reads and writes.  However, this is a utility that most users rarely run, and requires the user to specially select the second option.  Lastly, it appears that the severity of the bug varies -- on some computers it takes up only 90 percent of the memory, on others it crashes entirely.

Furthermore, while the biggest danger is likely that the flaw could be exploited by malicious parties who gained user level access to quickly swamp a  system, again this isn't necessarily of show stopping variety.  A hacker could just as easily open 200 copies of Microsoft Paint, which would also likely kill your RAM (with the nice addition of causing more visual annoyances).

Mr. Sinofsky says the Windows team is hard at work trying to track it down.  He states, "Some have reported (as above) that this specific issue repros and then goes away with updated drivers. We haven’t yet confirmed that either but continue to try. We just kicked off overnight stress testing of 40 machines of variants as reported by FireRx. We’ll see."

It looks like the RTM bug may be an example of an out of control feature.  Microsoft looked to give chkdsk more RAM, reportedly to help it run faster on modern systems with a lot of RAM.  Some are speculating that this feature broke and it now takes more RAM than it should.  What's interesting is that if true, this means that Microsoft is taking the opposite approach with disk checking as it is with Antivirus -- the free beta of Microsoft Antivirus had a smaller-than-average memory footprint.

A fair prediction seems that Microsoft has a patch on Windows Update for the utility by launch time and the users are minimally inconvenienced.  In the meantime, try not to select those specific options in chkdsk.exe, no matter how tempting they seemed. 



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

So you admit it...
By psypher on 8/7/2009 9:31:19 AM , Rating: 5
So you admit that your post yesterday was utter trash and that you are less informed than 90% of your readers?? This too is old news. We all new this before you posted your article yesterday.

Learn to be up to date. Check the dates of your sources. If they are more than a day old, check for updates before you post utter shit and prove once again that you are not very good at what you do.




RE: So you admit it...
By JasonMick (blog) on 8/7/09, Rating: 0
RE: So you admit it...
By InternetGeek on 8/7/2009 10:01:55 AM , Rating: 5
Jason, Your first post marked the issue as 'Catatrophic' which was not the way the original blogger called it. Bloggers with as much or more experience on Windows testing were describing the issue in detail, with screenshots and everything, on how to reproduce it.

From a tech site you would expect a much deeper understanding of this issue before sounding the alarms the way you did. It hadn't been 5 hours when your piece was being aggregated through many sites.

Though I understand you wanted to break the news first, you should do the same effort to correct the crazyness that ensued.

This current piece doesn't match quite well to what other bloggers are posting about it. ZD Net, as noted before, are not even labelling it important.

Even then Microsoft is doing all they can to prove their product is good. You could at least cover that and keep everyone informed.


RE: So you admit it...
By JasonMick (blog) on 8/7/09, Rating: -1
RE: So you admit it...
By Lifted on 8/7/2009 11:20:48 AM , Rating: 5
quote:
though the bug is non-critical


MS said it's NOT A BUG. Are you a reporter or a drama queen?


RE: So you admit it...
By Yawgm0th on 8/7/09, Rating: -1
RE: So you admit it...
By ggordonliddy on 8/9/2009 8:34:54 PM , Rating: 2
How the hell is it not a bug if it crashes some systems?


RE: So you admit it...
By mikefarinha on 8/10/2009 11:05:11 AM , Rating: 2
If it were a 'bug' in the OS it would crash on all systems.

As it stands now the few people that reported BSODs were most likely using bad/old device drivers or had faulty memory. The BSODs were NOT reproducible.

Neither of those meet the qualification as a bug in Win7.


RE: So you admit it...
By MrPickins on 8/7/2009 11:39:08 AM , Rating: 5
Who are you to decide how much ram utilization counts as a buggy?

As MS has already stated, the chkdsk repairs are most often done when there is a problem with the computer, so the process needs to complete as fast as possible. In this situation using 80-90% of available RAM is perfectly acceptable.

It's not like you're going to be running this while playing games...


RE: So you admit it...
By MrPickins on 8/7/2009 11:52:09 AM , Rating: 2
Err, I meant "as a bug"

I wasn't talking about a beach vehicle. :-p


RE: So you admit it...
By Yawgm0th on 8/7/09, Rating: -1
RE: So you admit it...
By clovell on 8/7/2009 11:42:03 AM , Rating: 5
No excuse?

Have you read Sinofsky's full response? The program is designed to take full advantage of as much RAM as possible, while leaving enough for only essential services, so that it can run more quickly. Most of the time, it does so without issue. It behaves this way because the assumption is that if you use the /r option, you suspect the drive is bad, and so you want the check and auto-fix to run through before you move on to other things. You may disagree with the tactic, but it's hardly 'inexcusable'.

What's inexcusable here is the entire concept that you would like to multitask while resolving hardware issues. That being said, it is worth reporting on, but maybe not in the manner that it was. I can handle the flair that you add to articles insofar as you can put up with the flames they generate.


RE: So you admit it...
By Yawgm0th on 8/7/09, Rating: -1
RE: So you admit it...
By MrPickins on 8/7/2009 1:06:20 PM , Rating: 1
quote:
Besides, I'd like to see some benchmarks. I really doubt letting Chkdsk pull 4GB or 6GB or 8GB of RAM is going to amount to a substantial speed increase. The drive's sequential and random read speeds are going to be a much bigger bottleneck.


Unless you have access to the source code, or at very least some documentation of the exact algorithm used, you really can't say that with any certainty.


RE: So you admit it...
By Yawgm0th on 8/7/2009 1:20:05 PM , Rating: 1
Only scientific real-world testing would confirm it either way, not the source code.

That said, anyone with a solid computer science background can infer as much as I have. Still, I'm not claiming with any certainty that this change in Chkdsk programming doesn't have a substantial performance benefit -- I just highly doubt it.


RE: So you admit it...
By Digimonkey on 8/7/2009 4:22:48 PM , Rating: 2
You're kind of inferring that the devs at Microsoft who work on chkdsk don't know that a hard drive is slower than memory. I doubt that is the case and there is more than likely a logical reason why using more memory speeds up the process of error checking.

And something you mentioned earlier about a bug is a bug rather by design or not is silly. Something that works as it should is not a bug. It is not the fault of the program if it can crash your system due to the faultiness of either your drivers or hardware. In fact, it now has a bonus feature of possibly detecting bad memory.


RE: So you admit it...
By Yawgm0th on 8/7/09, Rating: -1
RE: So you admit it...
By Hieyeck on 8/8/2009 2:04:24 AM , Rating: 4
There's some VERY simple logic.

It takes time to check for errors, alot of time (at least in computer time). Instead of having the checks choke at the relatively slow HDD, you dump as much data into RAM as possible, speeding up access times. As data is checked, it can then be dumped and replaced with other data that remains to be checked, while the process moves on to check other data waiting to be checked in other addresses.

In short, WHAT RAM IS SUPPOSED TO DO. Basic computer skills? Go back to Hardware 101.

Microsoft PR != Microsoft Engineering. Microsoft is still a company, I'm sure their PR department is just like any other and has a script to follow, and typically, PR has NO friggin clue what's actually going on. If you believed the first words out of everyone's mouth without doing some research of your own, my name's Vince and I have some ShamWOWs to sell you. Anyone not in IT - PR for IT companies included (hell even some of our tools for managers), isn't used to dealing with nit-picking nerds with the knowledge of the world at their fingertips. They'll spew generic bull and chalk up any resulting blinding errors to 'miscommunication'.


RE: So you admit it...
By DOSGuy on 8/7/2009 8:33:57 PM , Rating: 3
quote:
A runtime utility should not be taking 80-90 percent of the RAM. That is notable and important, though the bug is non-critical and certainly not catastrophic. There's just no excuse for using that much memory, even to fix a possibly damaged USB drive or other secondary disk.


Once again, this isn't a bug. When the -r option is used, chkdsk is allowed to use as much RAM as it can find.

A handful of people had their system crash when they did that. But here's the thing: most people don't realize that their system is unstable. Unless you've stress tested it with Memtest86, Prime95, etc, your computer just works and you assume that it's 100% stable. For people who have 4 GB of RAM, chkdsk may have been the first program that ever tried to use all of it, and their unstable system was finally pushed hard enough that it crashed. The fact that many people were unable to crash their own systems seems to bear out the fact that a 100% stable computer will not be affected. This isn't a bug, but rather a stress test.

That said, knowing that chkdsk -r can crash an unstable system, Microsoft will probably want to dial the program back a bit to prevent that from happening. But really, how many people was this going to affect anyway? I've been using chkdsk since MS-DOS, but I'm not sure if I've used it more than once in the last 5 years. I don't think I've used the -r argument for 10 to 15 years. Have you?

This is a non-story! There was never any possibility of Windows 7 being delayed. It isn't even a bug! And on top of everything else, even though chkdsk probably won't crash a stable system, Microsoft is going to make changes to the program anyway for the benefit of customers using unstable systems. That will be the end of it. We can move on now.


RE: So you admit it...
By crystal clear on 8/8/2009 5:52:54 AM , Rating: 3
quote:
I believe this a worthwhile topic to discuss.


The topic worthwhile discussing here for the commentators is Jason Mick.

They all out to get you !

You blew it !

You are the showstopper bug thats under discussion....


RE: So you admit it...
By Kougar on 8/8/2009 8:18:31 PM , Rating: 3
I think the issue at hand is that it sounds like you are ignoring the RAM usage is by design. Since this got missed, I'll quote Steven Sinofsky's first half of his comment that you quoted from:

quote:
In this case, we haven’t reproduced the crash…. [T]he design was to use more memory on purpose to speed things up, but never unbounded — we requset [sic] the available memory and operate within that leaving at least 50M of physical memory. Our assumption was that using /r means your disk is such that you would prefer to get the repair done and over with rather than keep working.


Furthermore the crashing issue seems to be impossible for the majority (Everyone I've read, as a matter of fact) of sites to reproduce. So, so far just one user can reproduce crashes, and the memory usage is by design. With both of those points in mind I see your articles as the "extreme" reaction here.


RE: So you admit it...
By SiN on 8/7/2009 10:20:45 AM , Rating: 4
i was sure the article had some sensationalized title like "Catastrophic Bug Found In W7 RTM Build", but after checking it again today, it appears i was wrong... or it had changed ;)


RE: So you admit it...
By johnsonx on 8/7/2009 12:06:29 PM , Rating: 5
Yes, he went back and changed it. Mick does that alot. Journalistic integrity doesn't have much sway with Mick.


RE: So you admit it...
By Spivonious on 8/7/2009 10:03:32 AM , Rating: 5
So by your logic, any app that uses 80-90% of resources is classified as a bug? That's ridiculous.

If the app truly needs all of that memory to run at its fastest, and the memory is available, then by all means, use it! I will never understand the argument that free memory should be maximized. I bought 6GB of it, I want it used!


RE: So you admit it...
By JasonMick (blog) on 8/7/09, Rating: -1
RE: So you admit it...
By Sazar on 8/7/2009 10:58:02 AM , Rating: 3
I guess a psuedo mea-culpa is better than burying your head in the sand Mick.

Getting hits for an article is well and good and I applaud you for sticking your neck out on a trumped up piece, but at least you have somewhat addressed it.

No need to ruin it by continuing to stick to your 'CATASTROPHIC BUG, OMGZ... FEAR" and the showstopper connotations. Obviously, the show was not stopped.

And, fwiw, as with disk defragment, chkdsk typically should not be running in the background, especially with the R flag, in a normal user environment where the user continues to use apps.

This would be an issue with Win2k8 R2, but not with Windows 7.


RE: So you admit it...
By omnicronx on 8/7/2009 11:09:14 AM , Rating: 4
What sane person runs chkdsk /r during the day? It can take hours.. On a disk that actually has errors, I've gone to bed and woken up the next day to see it had still not completed. Checking every single sector takes time, so if using all your resources helps speed this up then I am all for it.


RE: So you admit it...
By mcnabney on 8/7/09, Rating: -1
RE: So you admit it...
By vanka on 8/7/2009 1:12:45 PM , Rating: 5
You seem to have missed something; Microsoft has designed CHKDSK to use the maximum amount of RAM to speed up the check. In these days of multiple terabyte drives, I think that is a good thing.


RE: So you admit it...
By mcnabney on 8/7/2009 1:23:08 PM , Rating: 4
The simple function of what CHKDSK does eliminates the need to cache data in RAM. The processor will handle any amount of data that can get across a SATA connection without the need to waste space in system memory. Unlike normal applications that take large chunks of RAM, CHKDSK doesn't need to hold much in memory. It just doesn't work that way.


RE: So you admit it...
By MrPickins on 8/7/2009 11:42:28 AM , Rating: 3
With each article/comment you post, I question more and more how you are considered qualified to report on tech news.


RE: So you admit it...
By clovell on 8/7/2009 11:43:39 AM , Rating: 3
Again, as I said above, I completely disagree. The idea that you want to multitask while diagnosing and fixing hardware problems is the only thing unacceptable here.


RE: So you admit it...
By gstrickler on 8/7/2009 3:14:04 PM , Rating: 3
First, ChkDsk (even when run with /r) is not just to diagnose and fix hardware problems. It's most frequently run to rule out the possibility that a hardware problem is the source of some problem/symptom the user has observed, or to validate that a drive is working properly before putting important data on that drive. Therefore, most of the time it's used, it's running on properly functioning hardware, and it's used as a precautionary tool.

Second, if you discover early in the day that a secondary drive (perhaps an external you use for backups) is having trouble being accessed, you would indeed want to run ChkDsk /r on it WHILE you're using the computer to accomplish your other daily tasks. You do NOT want to have to stop using the computer for several hours while you run ChkDsk on a drive that you don't need to use at that moment, nor would you want to wait until that evening because you may need the data on it before the end of the day/first thing in the morning.

Finally, since using all/nearly all the resources (especially memory) on any system increases the chances of a failure, have a diagnostic/repair utility that stresses a system's resources to the point that failure is more likely is foolish. You ABSOLUTELY do not want a system to fail while it's trying to repair/update volume information, because a failure during updating that info significantly increases the chances of data corruption and data loss.

If it were a problem on the boot/system volume that caused the computer to be unusable anyway, then you would definitely want the program to complete as fast as possible, even if that meant allocating all available resources, but that's not the situation here. In this case, the computer is perfectly capable of performing other necessary tasks while verifying and/or correcting problems on a secondary drive/volume, but because ChkDsk may allocate nearly all your RAM, the computer can be nearly unresponsive.


RE: So you admit it...
By seamonkey79 on 8/10/2009 10:27:00 PM , Rating: 2
No, I'd pull it and throw it in my test system to run a check on it there... anyone doing diagnosis on a functional machine is missing some functional operations in their head.


RE: So you admit it...
By Lifted on 8/7/2009 11:18:55 AM , Rating: 1
And on systems with more than 4GB of RAM, the system doesn't uses more than ~3GB as it's a 32-bit app, and this is by design to make chkdsk run faster. So why all the drama? These people must be running AutoCAD or Pro/ENGINEER while running chkdsk. I just don't get what all the commotion is about. I guess MS could make a slower version of chkdsk so DailyTech writers can run it while curing their busy curing cancer.


RE: So you admit it...
By overzealot on 8/8/2009 1:27:05 AM , Rating: 2
Uh, actually in 64-bit windows chkdsk.exe is a 64-bit app.


RE: So you admit it...
By SavagePotato on 8/7/2009 10:07:56 PM , Rating: 2
Crysis is the worst bug ever.

Seriously though this is funny as hell.

Watching all the same would be techs that made up stupid shit about Vista coming out of the woodwork to try and harpoon 7 before it's even out the door with their "expert" opinions.

It's like 2007 all over again.


RE: So you admit it...
By spartan014 on 8/7/2009 10:24:47 AM , Rating: 3
Two things....

1. How do you know it is a feature getting out of control?

2. Whoever said about data corruption?


RE: So you admit it...
By JasonMick (blog) on 8/7/09, Rating: -1
RE: So you admit it...
By Lifted on 8/7/2009 11:25:32 AM , Rating: 3
The average user is running Firefox and MS Office while running chkdsk? Do you also complain that your computer is slow when running a full scan with your AV software?


RE: So you admit it...
By Spivonious on 8/7/2009 11:34:15 AM , Rating: 2
The average user will only have one hard drive. If they want to run a surface scan on that drive they will have to reboot to do it, as Windows can't scan drives that are currently mounted and in use.


RE: So you admit it...
By clovell on 8/7/2009 11:46:18 AM , Rating: 2
An average user shouldn't be trying to update their myspace while they suspect a drive is bad enough to warrant a chkdsk /r run.


RE: So you admit it...
By KingViper on 8/7/2009 11:56:41 AM , Rating: 5
I want to reboot, but I want to play minesweeper at the same time!!! BUG!!!


RE: So you admit it...
By mikefarinha on 8/7/2009 2:57:49 PM , Rating: 4
Mick... Mick... Mick...
Please see the highlighted portions of these quotes.

You said:
quote:
I think it is important to discuss when an system util is using 80-90 of the available memory.


Sinofsky elaborated
quote:
In this case, we haven’t reproduced the crash and we’re not seeing any crashes with chkdsk on teh stack reported in any measurable number that we could find. We had one beta report on the memory usage, but that was resolved by design since we actually did design it to use more memory. But the design was to use more memory on purpose to speed things up, but never unbounded — we requset the available memory and operate within that leaving at least 50M of physical memory. Our assumption was that using /r means your disk is such that you would prefer to get the repair done and over with rather than keep working.


It doesn't use up 90% of the system's memory... It uses up what is available - 50MB.

Are you trying to not look intelligent?

By all the comments on threads that I've read where people were testing out this problem they were saying that they could still use their computer just fine while the scan read (except for your friend Randall (woe-is-me) Kennedy).

Oh and BTW I discovered a new bug! If I change the oil in my car while it is still running it causes my engine to seize up! What kind of "engineers" does stinkin' Toyota employee?


RE: So you admit it...
By MrPoletski on 8/11/2009 6:40:24 AM , Rating: 2
Question:

why do you want to run chkdsk on your NTFS volumes anyway?

NTFS does it's OWN housekeeping.


RE: So you admit it...
By Spivonious on 8/7/2009 9:59:38 AM , Rating: 1
Totally agree. Ed Bott had an entry about the "bug" (it's really not a bug) and Sinofsky's response on August 5th. That's a whole two days ago.


WTF
By amanojaku on 8/7/2009 10:06:21 AM , Rating: 3
quote:
Some are speculating that this feature broke and it now takes more RAM than it should. What's interesting is that if true, this means that Microsoft is taking the opposite approach with disk checking as it is with Antivirus -- the free beta of Microsoft Antivirus had a smaller-than-average memory footprint.
What does anti-virus have to do with disk checking? Anti-virus runs continuously alongside other programs; we don't want that to have a large memory footprint. Disk checkers are run when we think we have problems; no other program is running at that time and we want the checker to have as much of the resources as it needs to finish as quickly as possible. I'm no coding genius, but I've written c++ code that copies files using various buffer sizes. There is an optimal window where increasing the RAM increases the disk write performance. I was surprised, as I expected the cluster size to be a limiting factor. When performing sequential reads and writes (as a disk checker would do) buffers in the GB range (not exceeding physical RAM) are the fastest. Just think of a power band graph.




RE: WTF
By JasonMick (blog) on 8/7/09, Rating: -1
RE: WTF
By psypher on 8/7/2009 10:56:21 AM , Rating: 5
quote:
on 2 GB systems, maybe throw 1.5 GB at it


So 75% of available memory is totally okay by your own recommendation, but 80% is a catastrophic programming failure... You are the greatest source of comedy...


RE: WTF
By amanojaku on 8/7/2009 11:00:11 AM , Rating: 2
quote:
Often disk checks are suggested by Windows when you plug in USB drives or secondary hard drives.
WHAT? Are you trying to tell me Windows performs a surface scan when I plug in my USB drive? Are you trying to tell me I can use my disk without a performance penalty if Windows is performing a surface scan? Because that's what you just said. The "memory leak" is related to surface scans only.
quote:
In order to activate the bug you must run the utility and then choose the -R option from the command line or the "Scan for and attempt recovery of bad sectors" on the GUI (not the default option).


RE: WTF
By JasonMick (blog) on 8/7/09, Rating: -1
RE: WTF
By JasonMick (blog) on 8/7/09, Rating: -1
RE: WTF
By Spivonious on 8/7/2009 11:29:47 AM , Rating: 3
I may be mistaken here, but I believe Windows unmounts the drive while it's doing a surface scan. That's why you can't scan the main system drive while Windows is running.

Therefore, the disk will always be locked when running a surface scan.

Jason, just admit that you blew things out of proportion and that this "bug" really isn't one.


RE: WTF
By VaultDweller on 8/7/2009 11:07:26 AM , Rating: 2
quote:
Often disk checks are suggested by Windows when you plug in USB drives or secondary hard drives.


Windows does not use the /R option for these scans, and so this will not produce excessive memory usage.

Also, I saw it pointed out earlier that the /R option can't be used in Windows 7 without administrative privileges. I'm at work without access to a Windows 7 machine right now, so I cannot verify at this time.


RE: WTF
By Sazar on 8/7/2009 11:20:15 AM , Rating: 2
I just checked, you are correct, it cannot be run without admin.

"Access Denied as you do not have sufficient privileges.

You have to invoke this utility running in elevated mode".

That is the message generated when running through the command prompt.


RE: WTF
By Spivonious on 8/7/2009 11:32:48 AM , Rating: 2
Surface scans are ALWAYS user-initiated. If a user is running a surface scan, they suspect there are errors on the disk. They won't be running anything else.

Letting the scan use all but 50MB of the available memory (that's right, if something is already running, the memory won't be stolen away from it) so it can complete faster is totally acceptable in my book.


New article...
By Rinadien on 8/7/2009 9:55:03 AM , Rating: 5
quote:
A hacker could just as easily open 200 copies of Microsoft Paint, which would also likely kill your RAM (with the nice addition of causing more visual annoyances).


Nasty memory leak found in Windows 7 RTM build...

A new showstopper bug was discovered in the latest Windows 7 build!! Users were able to replicate a bug where by opening 201 instances of Microsoft Paint, the memory usage would inexplicably spike to over 90% rendering the computer useless.

Hackers everywhere are overjoyed by the news. States one hacker: "I was waiting in line at the local unemployment office sobbing uncontrollably that I was out of work, when I got a phone call about the bug. This is the opening we were looking for, now we can finally take over the world."

Microsoft prepared a short statement about the bug, in which they claim that it's actually the Monitor vendors that are causing the crash: "If the monitors would only display 16 colors, this issue would never happen", states one Microsoft executive.




RE: New article...
By VaultDweller on 8/7/2009 11:10:25 AM , Rating: 2
200 copies of Paint for a denial of service attack? Learn to be lazy, dude. The attacker can run commands on the system. What's wrong with the 'shutdown' command?


RE: New article...
By Rinadien on 8/7/2009 12:54:03 PM , Rating: 2
The shutdown command is currently under official review, expect it to be disabled within 72 hours.


RE: New article...
By gmyx on 8/7/2009 1:23:33 PM , Rating: 2
Very true. I've done that one in a test application by accidentally opening hundreds of windows in a matter of seconds.

You don't event need admin for this!


Jason, Still trying to make everything alright?
By vanka on 8/7/2009 12:28:19 PM , Rating: 5
Jason, is this the "more level-headed" article you promised in the comments to George's post?

quote:
There's a big new bug in Windows 7, a memory leak found in the Windows 7 RTM.
Throwing around the scary B-word again, are we? To repeat what I asked in my response to your comment in George's post, since when does a feature (or aspect of a feature) that you personally don't like (or think should have been implemented better) constitute a bug? Especially when 90%+ of all the other users have no issue with the way it was implemented.

quote:
While it takes a somewhat specific -- though not entirely uncommon -- sequence of commands to trigger
Not uncommon? Think back Jason, how often did you run CHKDSK in the past 6 months? How about with the /r switch? On a secondary drive? Now think of the average Windows user, how often do you think your grandma runs CHKDSK?

quote:
The bug only occurs when scanning secondary disks or partitions -- something a lot of users don't even have.
Oh, oh Jason. Looks like you shot yourself in the head there, looks like it is in fact "uncommon".

quote:
Furthermore, while the biggest danger is likely that the flaw could be exploited by malicious parties who gained user level access to quickly swamp a system, again this isn't necessarily of show stopping variety. A hacker could just as easily open 200 copies of Microsoft Paint, which would also likely kill your RAM (with the nice addition of causing more visual annoyances).
It just wouldn't be a Jason Mick article without more FUD being liberally spread like manure. First of all, if a hacker gained user level access - I doubt he'd go for this crude "hack" to disable your system. Second, CHKDSK requires Administrator level access to run.

quote:
It looks like the RTM bug may be an example of an out of control feature.
Only according to you, Microsoft maintains that the feature is working as expected. At present, Microsoft has a better track record than you so I am inclined to believe them.

quote:
Some are speculating that this feature broke and it now takes more RAM than it should.
Who's the one speculating? So far it's only been people known for their FUD and sensationalism. As for taking more RAM than it should, Microsoft makes a very valid point that most people (systems admins mostly) run CHKDSK as a troubleshooting/repair tool; thus they are more concerned with how fast it completes than how much resources it consumes. This isn't a tool that an average user will be running while watching a DVD or surfing the web.

quote:
Lastly, it appears that the severity of the bug varies -- on some computers it takes up only 90 percent of the memory, on others it crashes entirely.
In view of Microsoft's response that the high resource usage is by design; the crashes experienced by an extremely small percentage of users points to there being another issue with the computer. This could be anything from bad driver to old firmware to hardware problems.

quote:
In the meantime, try not to select those specific options in chkdsk.exe, no matter how tempting they seemed.
Just needed to get a parting shot in didn't you.

I'd like to repeat what I posted in the comments of George's post: At this point Jason you're like the kid at the city pool who gets caught with his shorts down while in the pool. He try's to be cool and pretend that he's not embarrassed and not cry; but we all know he is. With this "article", all you're trying to do is minimize the whispering, laughter, and finger pointing; but it won't work - we all see you're naked. Your rationalizations, explanations, and half-sincere apologies won't change any of that.

Right now it's interesting to watch how long (maybe never) it will take you to decide that sticking to your guns will embarrass you more (and do more damage to what's left of your reputation) than admitting you were way off base.




By Yawgm0th on 8/7/2009 1:38:21 PM , Rating: 2
I really hate to be siding with Jason on this, and he was definitely in the wrong in his reaction to this. But here goes...

quote:
Throwing around the scary B-word again, are we? To repeat what I asked in my response to your comment in George's post, since when does a feature (or aspect of a feature) that you personally don't like (or think should have been implemented better) constitute a bug? Especially when 90%+ of all the other users have no issue with the way it was implemented.
When a feature causes potentially serious issues and unintended consequences. Since when did we all start falling for the "it's a feature, not a bug" line from software developers?
quote:
Not uncommon? Think back Jason, how often did you run CHKDSK in the past 6 months? How about with the /r switch? On a secondary drive? Now think of the average Windows user, how often do you think your grandma runs CHKDSK?
I can't speak for Jason, but I've run it at least 20 times in the past six months. Obviously not on the same computer, but I work with enough computers that running chkdsk is not a uncommon task for me. Take 10000 users and in one month they will run chkdsk more than I do in six. Some of them are bound to run into this if it's not fixed by release (which it probably will be).

quote:
Oh, oh Jason. Looks like you shot yourself in the head there, looks like it is in fact "uncommon".
While I won't deny that Jason contradicts himself once in a while ( ;) ), secondary partitions or drives are more common in PCs than one would imagine. Also, this problem has been reproduced on USB flash drives, which is a very good example of a potential application of chkdsk /r for the average user. After an unsafe removal of the drive, running chkdsk on it could be needed.

quote:
It just wouldn't be a Jason Mick article without more FUD being liberally spread like manure. First of all, if a hacker gained user level access - I doubt he'd go for this crude "hack" to disable your system. Second, CHKDSK requires Administrator level access to run.
No disagreement here. Jason has repeatedly proven he doesn't even have a basic understanding of technical security concepts.

quote:
Only according to you, Microsoft maintains that the feature is working as expected. At present, Microsoft has a better track record than you so I am inclined to believe them.
Sweet. Let me get back to installing Firewire cards in all of our computers, just in case we need that direct memory access feature.

quote:
In view of Microsoft's response that the high resource usage is by design; the crashes experienced by an extremely small percentage of users points to there being another issue with the computer. This could be anything from bad driver to old firmware to hardware problems.
Chicken, meet egg. Crashes caused by Chkdsk are not acceptable, period. If chkdsk outside of 7 (say, Server 2008 or Vista) works on the same hardware without the same crashes, that is a problem caused by 7. Even if a driver or firmware is at fault, arguably, Microsoft shouldn't shrug and point fingers, especially when it is a problem Microsoft can alleviate. But I'm skeptical of this viewpoint anyway, especially after Home Server.


By vanka on 8/7/2009 6:35:38 PM , Rating: 2
quote:
When a feature causes potentially serious issues and unintended consequences. Since when did we all start falling for the "it's a feature, not a bug" line from software developers?
That is the whole point, it has not been proven that CHKDSK with the /r switch on a secondary drive causes blue screens. what has been proven is that this very specific combination consumes most of the system resources while the scan is running and then releases them afterward. This does not sound like a memory leak to me. Microsoft's rational for this design makes sense and I'm inclined to believe them. The scattered reports of blue screens at this point are anecdotal.

quote:
I can't speak for Jason, but I've run it at least 20 times in the past six months. Obviously not on the same computer, but I work with enough computers that running chkdsk is not a uncommon task for me.
You actually just proved my point; roughly 3 times a month is not that common. You also did not specify which options you used when running CHKDSK; but the second sentence puts it in even better context. From it I gather that ran CHKDSK on computers that you were charged with repairing; that these weren't your daily computers on which you decided to scan a secondary drive with the /r switch while catching up on tech blogs and email. I don't know about you, but when I'm troubleshooting or repairing a computer, I usually have a laptop handy where I can look up KBs, download drivers/updates, etc. I do this because I know that I will be running scans that will require me to reboot frequently or are run from a minimal OS environment (Memtest, etc).

If you, a computer repair person (I'm reading between the lines here) run it so rarely, my point stands about average users needing it even less (hence not running into this issue as often or ever) stands.

quote:
Also, this problem has been reproduced on USB flash drives, which is a very good example of a potential application of chkdsk /r for the average user. After an unsafe removal of the drive, running chkdsk on it could be needed.
This is a very valid point, one that I agree with you on; but it is not as problematic as it would appear at first glance. For one, Vista and Windows 7 play much nicer with USB drives than XP ever did. I never use the "safely remove hardware" dialogs when unplugging my USB drives when in Vista or 7 - I just unplug them - and was never prompted to run a scan when plugging it back in. When I unplugged it the same way on XP and then plugged in back in, I was usually prompted by that computer (whether it was running XP, Vista, or 7) to run CHKDSK. Second, when prompted to run CHKDSK in this manner on a USB drive, the default is to run the scan without the /r switch. Thus most users (even techs) will run the default. Third, even if the user decides to run it with the /r option; most people's USB drives are in the 2-8 GB range - it will be at most a minutes inconvenience.

quote:
quote:
Only according to you, Microsoft maintains that the feature is working as expected. At present, Microsoft has a better track record than you so I am inclined to believe them.
Sweet. Let me get back to installing Firewire cards in all of our computers, just in case we need that direct memory access feature.
This was written in half-jest, in reference to Jason's tendency to write over-the-top, sensational, and very inaccurate articles then try to defend them and to contrast that with Microsoft's pretty fair record of admitting and fixing bugs. (Not in all cases, I admit.)

quote:
Chicken, meet egg. Crashes caused by Chkdsk are not acceptable, period. If chkdsk outside of 7 (say, Server 2008 or Vista) works on the same hardware without the same crashes, that is a problem caused by 7. Even if a driver or firmware is at fault, arguably, Microsoft shouldn't shrug and point fingers, especially when it is a problem Microsoft can alleviate.
I hate to repeat myself, but that the point - there's no proof at this time that the blue screens are being caused by CHKDSK. Microsoft has, as of right now not been able to replicate the issue, and the reports online are very few and anecdotal. It is entirely possible that CHKDSK was the first to stress the drivers or hardware in this way; just because a rooster crows before the sunrises - it does not necessarily follow that the sun rises because he crows. The blue screens may or may not be caused by CHKDSK.

If either case, you're right - Microsoft should work to fix the issue; and that's exactly what they are doing. They are working on trying to reproduce the crashes; and if it turns out that they are being caused by driver issues, then I'm sure they will work the manufactures/OEM to get it taken care of. They still have almost 3 months to take care of it.

quote:
But I'm skeptical of this viewpoint anyway, especially after Home Server.
I agree that they dropped the ball with the Home Server issue; but this is nowhere near that level of severity - even if we grant that this is a bug.


Drama Drama Drama
By StevoLincolnite on 8/7/2009 9:45:09 AM , Rating: 3
If the bug was a "Show stopper" as DailyTech so kindly inclined to inform everyone in the last article, then why after 6+ months haven't I ever experienced it?

Because the "Show Stopper bug" isn't a show stopper at all, it's a small inconvenience at best, that will be repaired fairly quickly, it's a feature that isn't commonly used, heck there are much better -free- alternatives out there anyway (That goes for a defragger as well).

However I can give a little when it comes to Windows, MacOS and Linux, they are all highly complicated pieces of software with millions if not more lines of code, and the complicated task of debugging that for a perfectly smooth experience before launch would indeed be a rather daunting task, you are bound to be left with a small issue here or there, no company is immune to this.

However, I didn't comment in the last sensationalist article, because frankly, the issue was known before the Dailytech posting for a fair while, and the spin thrown on it really did bring the issue out of proportion, regardless of Dailytech's beliefs, Windows 7 will run perfectly fine 24/7 without issue, despite that "show stopper" bug being present.

Just my 2 cents.




RE: Drama Drama Drama
By spread on 8/7/2009 9:59:36 AM , Rating: 2
Thank you for your message Mick. Everyone knows that Apple would never release unperfect software like Microsoft does.

Let's all take a minute and pray to Jobs.


RE: Drama Drama Drama
By Sazar on 8/7/2009 11:00:09 AM , Rating: 2
A show-stopper in this case would have been stopping the RTM release of Win 7 on MSDN and Technet yesterday.

Given that I not only downloaded Win 7 last night, but also installed and have been running it since about 11 PM CST last night, I can vouch for the fact that, in fact, there was no stopping of the show :)


Bug you say?
By smackababy on 8/7/2009 10:20:34 AM , Rating: 2
How is a program, designed to not be run along side other things, that uses the amount of resources available to be done in a timely manner a flaw? Oh no! I have 8GB of RAM, no way I want to ever have anything use all of that! Damn you Microsoft and your forcing efficency on me!




RE: Bug you say?
By Yawgm0th on 8/7/2009 12:48:27 PM , Rating: 1
quote:
How is a program, designed to not be run along side other things
What program are you talking about? Chkdsk has always been specifically designed to fix volumes without affecting workflow on other volumes or the computer in general. Only when it is the system volume must one cease using the computer.

quote:
Oh no! I have 8GB of RAM, no way I want to ever have anything use all of that! Damn you Microsoft and your forcing efficency on me!
No way you would want to use it for other programs? Also, how much help do you think 8GB of RAM capable of transferring data at, say, 6,400MB/s is going to help run chkdsk on a hard drive that can only read at, generously, 350MB/s?


RE: Bug you say?
By smackababy on 8/7/2009 3:27:53 PM , Rating: 2
Clearly you didn't read what Sinofsky said concerning the new chkdsk in Windows 7.

And you're right. I shouldn't want any programs using my over capable RAM because the data transfer is just way too much for anything else to keep up with...


RE: Bug you say?
By Yawgm0th on 8/7/2009 4:38:02 PM , Rating: 2
quote:
Clearly you didn't read what Sinofsky said concerning the new chkdsk in Windows 7.
I read it yesterday. I just thought it was a cop-out.

quote:

And you're right. I shouldn't want any programs using my over capable RAM because the data transfer is just way too much for anything else to keep up with...
They should use what they need, not ten times what they need.


worse than the original article
By johnsonx on 8/7/2009 12:16:57 PM , Rating: 2
In many ways this quasi-sorta-kinda-but-not-really-retraction is worse than the original article. Mick is still contradicting his own sources and interjecting his own opinion into what is supposedly a news story. Caught with his pants down and dick out, you'd think he'd button up and act rational rather than continuing to assure us that he had good reason to twirl it around like that.

Silly me, thinking my opinion of Mick could go no lower.




By johnsonx on 8/7/2009 12:18:45 PM , Rating: 3
oh, dear, the auto-mod bot got me; naturally I meant to say "weenie".


Bug or improvement?
By croc on 8/8/2009 3:32:55 AM , Rating: 2
There is quite a bit of anecdotal evidence now being released to show that using this much RAM does not improve the performance of chkdsk in any significant fashion over say, ~500MB to 1 GB. If I had a copy of RTM, I'd try to do a serious bench test of this, but alas, I don't. To anyone that does have MSDN or Technet, here's a simple test: time a chkdsk /r in XP, Vista, Win7 RC and Win7 RTM while running taskmanager. Obviously, on the same drive...

From information that I have seen, the RTM version is not any faster, and in some reports slower, while using significantly more memory resource.

This is a small, but significant change in the RTM version vs. the RC version. Personally, it looks as if MS really dropped the ball here, assuming that memory utilization was the answer to any process but not properly testing that theory on real-world systems... The fact that it crashed some systems is incidental to the main issue, which is that MS made a change to a system utility without proper internal validation or testing as to the effects, and the performance gains that those changes gave




RE: Bug or improvement?
By BikeDude on 8/10/2009 10:09:02 AM , Rating: 2
Gobbling up available memory (-50MB) sounds like a very crude first attempt at an optimization.

But finding/demonstrating a smarter/faster algorithm is irrelevant to prove that the original implementation is a "bug".

Allocating a huge memory buffer does not in any way meet the definition of a "memory leak". Not releasing it again is a leak.

I think it has been satisfactory shown that the observed behaviour was not a "bug" and there were never any "memory leaks".

The story as reported was plainly wrong.

Personally, I am interested in stories about badly optimized code. Actually more so than stories about "bugs". I see absolutely no reason to spread FUD the way this story did.

That some guy out there had a BSOD is of course disturbing for the person involved, but given that most BSODs are caused by third-party device drivers, let us start the investigation there rather than try to pin it on MS. Until a memory dump is provided or more people report success in reproducing it, I think it is safe to ignore that one for now.


Sadly enough
By Howard on 8/9/2009 4:40:49 PM , Rating: 2
Jason Mick is more than anyone else the face of DailyTech, for better or for worse.




RE: Sadly enough
By Woobagong on 8/10/2009 4:28:41 AM , Rating: 2
[pragmatic]
On the other hand I was able to check what my other tech feeds were reporting. If something like this happens, there's a good chance to separate the wheat from the chaff.
[/pragmatic]


Incredibly bad journalism
By teriba on 8/7/2009 11:50:04 AM , Rating: 3
This, and the previous article, are probably the two worst written articles I have ever had the mispleasure of reading.

You completely forgot to quote the part where Sinofsky says it's normal for the app to use that much RAM. You say it's a memory leak, when it was by design. There is no memory leak here. Running a chkdsk /r is a blocking task, and as such it should use as many resources as possible to speed it up. This is not something you have running while you play games or surf porn.

Man up and admit your useless attempts at pot stirring. This is garbage on top of garbage.




By jls2691 on 8/7/2009 11:36:21 AM , Rating: 2
A runtime utility should not be taking 80-90 percent of the RAM. That is notable and important, though the bug is non-critical and certainly not catastrophic. There's just no excuse for using that much memory, even to fix a possibly damaged USB drive or other secondary disk.

This statement is just patently ridiculous. The utility should take as much memory as it needs to take to do the work. This is a "virtual memory" system after all, it is DESIGNED to have more memory "allocated" to processes than it actually has available - you know about paging files, right?

Could they design it differently, maybe even allow you to specify how much of the system resources you will allow it to consume? Sure. But if you don't like how it runs, don't run the thing.

The simple fact is that it runs as it was designed to run. You may disagree with the design, but that's only your opinion, and it is not based on any kind of objective set of criteria.

You overstepped on this one.




Biggest Danger?
By adiposity on 8/7/2009 11:52:03 AM , Rating: 2
quote:
Furthermore, while the biggest danger is likely that the flaw could be exploited by malicious parties who gained user level access to quickly swamp a system, again this isn't necessarily of show stopping variety.


Some how I doubt the first thing a hacker will do is try to BSOD a computer / make it run slowly with a chkdsk. I mean, really...if you have access to run a program like chkdsk (which requires ADMIN priveleges), there are a lot more interesting things you could do besides trying to crash the computer you just spent time hacking into. And yes, if you want to ruin the computer, you don't need chkdsk to do it! You can delete critical files and install trojans, you can alter the boot.ini so the computer won't boot, you can f*ck the registry! I mean, really, this chkdsk thing is the most boring and last thing you would do!

Another point, made by others...nobody really runs chkdsk while the computer is fully booted. You can run scandisk if you want to check the disk while you are logged in. Otherwise, chkdsk usually only runs on a reboot where a disk issue was detected. You might run it on server, but not win7, unless you really don't know what you're doing.

-Dan




Comment Jason style
By crystal clear on 8/8/2009 5:03:47 AM , Rating: 2
A fair prediction seems that Jason mick is on his way out....sorry too many complaints about shoddy work.

"Lacking fair amount of research,levelheadedness & writing skills your services at D.T. are hereby terminated."




Simple Solution
By mixpix on 8/8/2009 12:08:31 PM , Rating: 2
scan, restart, gtg. Heh, not really a bug at all, not a major one at all.

If the program needs lots of ram it should have it. What is the point of getting 4GB if your system only lets you utilize 2GB.

But how does bringing data from the hard drive to "more" RAM make the scan at all faster... the hard drive is still slower than the RAM, so it wont be able to keep up. Pointless? haha




"If a man really wants to make a million dollars, the best way would be to start his own religion." -- Scientology founder L. Ron. Hubbard

DailyTech Poll
Which web browser do you use on your primary personal machine? 






44 Comments












botimage
Copyright 2009 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki