11-13-2009 11:00 AM
I've been running Win 7 (x64 Ultimate, fresh install, free format) on my T400 (model 2767AG8, 4 GB RAM with BIOS ver3.09) for two weeks. Ever since I've installed, a file system check is running every now and then when I reboot the computer. To be precise: It happened 5 times since 2009-10-26). I've the feeling that it is related to standby/suspend/resume but I've nothing to make a good case. But somehow, Windows repeatedly flags the disk as "inconsistent".
Error 11.11.2009 22:41:31 Ntfs 55 (2)
Error 05.11.2009 20:01:15 Disk 11
Does anyone know what's going on?
Solved! Go to Solution.
11-13-2009 07:53 PM - edited 11-13-2009 07:54 PM
Both my W500 and my self-built desktop run checkdisk on almost every other boot. I don't really know why, but I suppose that running chkdsk every now and then can't be a bad thing so I haven't put any effort into figuring out how to stop it.
Both machines run Win7 x64.
11-14-2009 12:37 AM
Too bad to hear that you are also affected. Do you use a dock? Which BIOS do you use? Do you use standby or hibernate? Have you activated write cache on your system disk? have you disabled flushing the write cache on your system disk?
In my case, I use an advanced mini dock. I use both standby and hibernate. I have activated the write cache on my system disk but not disabled flushing it.
It's strange that there seems to be no clear pattern! And disk errors make me extremely nervous. Last night I let my T400 hibernate. Luckily, there weren't really open documents. This morning, on boot, Windows warned me that it has not been shutdown properly. A normal start with a chkdsk was the consequence, thereby loosing the hibernation data.
Hopefully, some Lenovo employee reads this. This should be escalated to the highest level.
11-14-2009 01:51 AM - edited 11-14-2009 12:11 PM
Mind you. This is most likely not the alleged "Windows 7 showstopper bug" related to chkdsk.
Here some more reports. A synopsis follows.
Synopsis: There is no clear pattern. Likely, there are multiple causes. It seems to me that there are three interesting hypotheses (and associated remedies) so far:
Thanks to help in the German ThinkPad forum, hypothesis 3 got some support. Apparently, Avira is aware that there anti-virus product has issues with Win 7 (see here). According to a Avira forum mod, a possible workaround for x64 is this:
For Windows 7 on 64 bits, please go to Avira's configuration, tick Expert Mode, Guard, in the "Scan mode" section please check only the "Scan when reading" option and click Apply. Monitor the situation until Monday and tell me if the chkdsk issue persists or not. Thank you in advance.
Update: The workaround does *not* solve the issue. But virus scanners might, of course, still be a cause of the filesystem state.
11-28-2009 12:51 AM
It turns out that there seems to be a change in the Win 7 kernel / NTFS driver which leads to problems with virus scanners. The good news is that your data is not at risk as Avira reports:
We got some reports of an issue where using Avira in Windows 7 leads to regular chkdsk-runs upon reboot. Our developers are analysing the problem and now succeeded to reproduce it. We are also in close contact with Microsoft to get to the bottom of this issue. It is not just affecting Avira in Windows 7 though, many other Antivirus products seem to trigger this behavior occasionally too as we learned during the investigation of the problem.
Microsoft introduced a slight change in the NTFS driver in Windows 7. Anyhow, even Microsoft can not pinpoint the problem (which by the way occurs seldom) yet. Update: Meanwhile, we could reproduce the issue and track it down together with Microsoft.
As far as we can tell from the current state of investigation, the problem occurs in special conditions, when an operation is performed upon an already deleted file. This leads to the situation that the NTFS driver / the windows 7 kernel deems the file system as corrupted (which it is not) and sets the dirty-flag of the NTFS partition. This in turn leads to the chkdsk-run on the next start of the system. In previous versions of the windows kernel, the operating system just returned an error.
We found a workaround for this issue. A hotfix is currently being tested and gets hopefully shipped next week as update, if there are no issues showing up in Quality Assurance. The driver avgntflt.sys in version 18.104.22.168 will fix this issue then. We will continue to analyse this issue together with Microsoft as we need to understand the problem correctly in-depth to come up with a better solution; maybe even a Windows Update will be necessary.