lee31 Posted August 6, 2009 Share Posted August 6, 2009 (edited) On neowin member chris123NT website Steven Sinofsky states the so called memory bug in windows 7 when running the chkdsk /r command on a secondary disk is by design in an attempt by Microsoft to speed things up. In the quote as highlighted you can see he also states that they assumed that most users would prefer to run the command and basically let it do its job quickly and that most users wouldn't carry on working during the process. He also states as you can see that any system crashes caused maybe a chipset controller issue that can in most circumstances could be resolved by updating the chipset driver. This has yet to be confirmed however. Hi there?sorry to get dragged into this. Of course always want to investigate each and every report of any unexpected behavior. 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 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.ing. 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. We appreciate the kind words that such a bug as above is ?out of place? with Windows 7?we?re working hard. We are certainly going to continue to look for, monitor, and address issues as they arise if required. So far this is not one of those issues. 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. Let?s see if we can work on this one and future issues together. Deep breath ?Steven Edited August 6, 2009 by lee26 Link to comment Share on other sites More sharing options...
Comic Book Guy Posted August 6, 2009 Share Posted August 6, 2009 He also states as you can see that any system crashes caused maybe a chipset controller issue Here we go, MS blaming everyone else but themselves. Link to comment Share on other sites More sharing options...
etempest Posted August 6, 2009 Share Posted August 6, 2009 Didn't MS respond siting a bug in some hard drive controller drivers? Link to comment Share on other sites More sharing options...
Chris123NT Posted August 6, 2009 Share Posted August 6, 2009 I did some more testing last night and was noticing that there was no crashing this time around, BUT the high memory usage was causing both systems to grind to a halt, and disk I/O was low which makes no sense as chkdsk is supposed to be hitting the disk every second it's running. If high memory usage is supposed to speed up the process then fine, but in this case I have observed high memory usage and decreased performance, which is definitely not right. Link to comment Share on other sites More sharing options...
Skyfrog Posted August 6, 2009 Share Posted August 6, 2009 Really? They are going with the old "It's not a bug, it's a feature" excuse? :laugh: Link to comment Share on other sites More sharing options...
BajiRav Posted August 6, 2009 Share Posted August 6, 2009 Really? They are going with the old "It's not a bug, it's a feature" excuse? :laugh: It might be a bug but certainly not a showstopper one. :/ Those calling it "showstopper" or "derail product launch" don't know **** about how those words are used. This might be Microsoft's way of controlling bad PR (even if it is a legitimate bug). The anti-MS trolls (the infoworld article), apple etc. will have a field day blowing a non-issue out of proportion. Win7 RTM is not bug-free but I'd hate to see it going the Vista way (PR wise) because of a low-risk bug. Link to comment Share on other sites More sharing options...
kheldorin Posted August 6, 2009 Share Posted August 6, 2009 I did some more testing last night and was noticing that there was no crashing this time around, BUT the high memory usage was causing both systems to grind to a halt, and disk I/O was low which makes no sense as chkdsk is supposed to be hitting the disk every second it's running. If high memory usage is supposed to speed up the process then fine, but in this case I have observed high memory usage and decreased performance, which is definitely not right. Do you have Vista? Maybe you can compare the time taken to really confirm the decrease in performance. They could have just transferred the hard disk data to memory and do the work there. Link to comment Share on other sites More sharing options...
Skyfrog Posted August 6, 2009 Share Posted August 6, 2009 No it's not that serious, and it can be patched after release. Now if it were corrupting data or something that would different. Link to comment Share on other sites More sharing options...
tomwarren Veteran Posted August 6, 2009 Veteran Share Posted August 6, 2009 No need for a duplicate thread. What Sinofsky said was already covered in https://www.neowin.net/news/main/09/08/05/w...asty-chkdsk-bug and there is a thread for the issue here: https://www.neowin.net/forum/index.php?showtopic=806282 Link to comment Share on other sites More sharing options...
Recommended Posts