Jump to content


  • Content Count

  • Joined

  • Last visited

About Frode

  • Rank
  1. I for one experienced it making chkdsk fail to complete at all (crashed out with error message after a few minutes). The issue also made Acronis TrueImage hang on its analysis phase and thus prevented me from performing backups. Chkdsk might not be the holy grail, but there are times you might need it and having it crash on you is the last thing you'll want to have to worry about at that point. If you uninstall and chkdsk runs ok you can almost certainly rest easy. With KAV no longer there to add data there's no reason to believe it will ever become a problem for you.
  2. I fail to see drdos post relevance to the topic, even if ignoring the factual errors and logical bloopers in the post. This issue isn't even remotely related to bad block handling. It's not related to particular harddrives. It's related to a feature of NTFS that was not designed to be used in the way KL is using it, though KL had no way of knowing that. If blame is to be placed it would technically be on Microsoft for not documenting properly. I don't see that as any excuse for KL taking over a year to start responding though. Either way, KL has acknowledged the issue. Cases where chkdsk fails completely are rare enough to not warrant mention. And KAV8 will solve it. Case closed.
  3. I wish you'd asked a year ago when I started this thread. I offered to help you isolate it using debug builds etc at that time. Unfortunately, as far as I can recall, the only machine KAV has made chkdsk break completely on is my main box. While I was originally willing to spend the time on testing/restoring/testing again, I am no longer interested in volunteering that kind of time. If you can make do with reproduceable slowdown issue, I still have a vmware image that exhibits that issue. At least it still did last I tested back in april. Rolling that back to a previous snapshot is a matter of seconds, so I don't mind doing a bit of testing there for you. If only machines where chkdsk fails completely is of interest, I have nothing to offer I'm afraid.
  4. I ran across this thread again for the first time in a very long time. While I am glad a logical explanation has been found, does the above imply there are no plans to change the behaviour? While it may not technically corrupt anything, the fact remains that it confuses chkdsk. In some cases to the point of chkdsk being unable to complete, and that again impacts other applications and the user's ability to correct any and all potential filesystem issues via chkdsk. I checked the KAV7 beta and it's still causing this issue, so it's safe to assume it's here to stay?
  5. This has already been addressed (in this thread I do believe). 1) Chkdsk slowdown occurs preboot as well. 2) In my case, after a day or two chkdsk started failing to complete at all (it crashed). 3) Acronis True Image became unable to analyze the drive for backup. It is not just a cosmetic issue, even though it appears KL doesn't feel it dignifies any action. I guess it's not costing them enough sales.
  6. After three months with no sign of the issue being identified, let alone fixed, I've given up waiting and bought nod, so I'm taking this thread off my watchlist now. If KL needs someone to test a build specifically aimed at fixing or isolating this issue, feel free to get in touch with me via PM. I'll be keeping the vmware image where it's readily reproducable. Either way I'll be back around for another test once next year's release comes out.
  7. Doesn't matter I guess, but FYI I noticed the AOL branded free year version and tested that too. From what I saw in the thread it lacked some features, so I was hoping it missed whatever's causing the chkdsk slowdown issue. No such luck.
  8. For those with this issue, it likely won't matter. It will only take longer for the issue to arise (scans will still happen when you access your files, so it'll build up gradually instead). KAV supposedly no longer stores anything in ADS, but it apparently does do something else permanent to the filesystem still. Why or what I can't even begin to guess at. This doesn't occur for everybody, so it might not be an issue for you. But you are right to worry I would say. I recommend anybody that asks me about KAV to stay clear for the time being. The fact it fails to vanish when uninstalling KAV is a very big deal to me. That KL appears to have no idea what causes it (or are ignoring it, I don't know which) isn't very confidence inducing either. The really sad part is that, apart from this one issue, it would be my #1 recommended AV.
  9. Tested and no change. Any confirmation the issue's even made it into KL's bug tracking system?
  10. Thanks. I downloaded and will give it a test later tonight. I did test 344 meanwhiles though and no improvement, so I'm not too optimistic.
  11. I can only find .344 on the site. Where can I get 356? Figured I could spare half an hour to test it safely (in vmware).
  12. Not in my case at least. Same OS, but that's about it. Don't need to put any filesystem load on at all to get the chkdsk slowdown. Other IO didn't change it but running a KAV scan did. In other words, as far as I could tell, it was purely down to KAV's activities.
  13. Not to be rude, but I'm monitoring this thread for updates on the KAV caused chkdsk issues. Can I safely assume nothing further will be said about that in this thread so I can remove the thread watch? I'm getting spammed with "thread updated" this morning cause of the memtest/harddrive/heat issue that's become the new topic of the thread.
  14. As I've mentioned previously this also occurs inside a vmware session. Which would be hardware independent. In other words, I doubt this is actually relevant. Sata drives in raid0 on an integrated Intel 82801FR controller.
  • Create New...

Important Information

We use cookies to make your experience of our websites better. By using and further navigating this website you accept this. Detailed information about the use of cookies on this website is available by clicking on more information.