Jump to content


  • Content Count

  • Joined

  • Last visited

1 Follower

About BlueZannetti

  • Rank
  1. Read the thread on all client updates are FAILING, locking up machines, just started this afternoon for details. Blue
  2. I guess I'd mention two points: First, I've gone through a couple of enterprise level malware events - one of which required a rather expensive ($7.5k-$10k) repair to a piece of equipment - that was the hardware cost alone - due to Sasser compromising some needed feedback and control communications - and this event seems a bit worse in terms of the anecdotal productivity loss. Second, in the few years I've used KAV WKS, I've gone through this 3-4 times and the end result is pretty much the same - bad update ties KAV WKS in a knot and recovery is not seemless. Now, I'm not an enterprise-level user of KAV WKS. My pain was limited to a couple of hours nursing things along until my systems were fixed. It was a rather inconvenient time for these things to occur for a few reasons (e.g. end of semester...) and a couple of the machines were pretty useless for a bit, so I can appreciate the feelings of those folks who had somewhat irate users like myself breathing down their necks. Given that this has occurred in the past, and the downside potential in an enterprise, it would probably be worthwhile for someone in KL to look at what it would take to create a failsafe mechanism to execute a forced recovery of the system. Although this event has been a little different, there's really only a handful of steps that seem critical in recovering from this type of event. The problem is that some of the obvious steps are actively guarded against, particularly these days. In any event, in addition to making sure it won't happen again, someone needs to start with the premise that it will happen again and figure out how a large enterprise deployment can rapidly and easily recover if it does happen again. Blue
  3. Since you note that you have uninstalled it until you get the problem sorted out, I'm not sure you fully appreciate the dependencies. If KAV/KIS is installed and you run fsutil to delete the object ID's, they will be immediately recreated. If you have a KAV engined AV as a temporary replacement while KAV/KIS is not installed, they may or may not be immediately recreated (it depends on the product). If you plan on reinstalling KAV/KIS, it makes no sense at the present to remove the file object ID's. It only makes sense to run fsutil if KAV/KIS is fully removed from the system and you have no intention of reinstalling KAV/KIS. Blue
  4. You are correct in your impression that many people have complained about the time that stage 2 of chkdsk takes to complete. They really shouldn't since it's a complete non-issue (unless one believes that the laws of physics are only suggestions....). The problem with the whole situation is the convolution and merging of the stage 2 time increase (not a problem) with cases in which there is an inability of chkdsk to successfully complete. The latter is a clear problem, although the direct relation to KAV/KIS generated file object ID's remains obscure at best, at least in my opinion, although there are certainly a number of people who differ on that point. Blue
  5. But for the folks who reportedly have real problems, that's not the issue. Fragmentation will not prevent chkdsk from completing, which is the real problem, and which may set up a cascade of events that leads to genuine and irreversible file system corruption. Blue
  6. Yes, as I wrote earlier (post 486) Correct Not correct, see above. It depends. Copying does not preserve file object ID's. Other operations do. No Blue
  7. Thanks, I try and occasionally succeed. Actually, my reply was meant as a counterpoint to that flow developing in the thread in question. While I hate cross-forum discussions (and really hope this doesn't go in that direction), I'll note that the thread in question is here since the connection to the present discussion is not obvious from the initial location or subject. Blue
  8. That would be me. I am not an Eset moderator. I am a Global Moderator at the Wilders site. They are rather different roles. You can confirm it yourself by running: FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Query "%a" For the record, it appears that the online KL scanner no longer creates these entries (it never should have since it was a transient application anyway). Some KL engined AV's also create them, other KL engined AV's don't. Blue
  9. Do you have a specific thread where this was discussed? As far as I know, the only real issue arises if the machine in question is actively using the Distributed Link Tracking Service, see http://msdn2.microsoft.com/en-us/library/aa363997.aspx I don't see this being an issue at all on a home based workstation, and the issues where a concern is applicable are minor to none as well. Blue
  10. According to http://support.microsoft.com/kb/266679 the answer would be yes with respect to these items at the restored point in time. Blue
  11. nu_D, Before worrying, verify that the object ID's are present. Is the external drive a FAT32 or an NTFS volume? Object ID's can only be created on an NTFS volume. Further, read the thread indicated above. These items can be deleted at will whenever desired. Those details are in that thread - the last few pages. Blue
  12. About 1.8-2.3% by my best estimate (~ $70-90 MM vs $4000 MM for the entire industry - sources are news releases with some projected growth included). I estimate that they're about 12-15% of Symantec alone. Blue
  13. As long as you're not experiencing a BSOD, you should be able to get through this without reformatting. What I'd try is the following: 1. Boot to safe mode without networking 2. Select Start>Run>type msconfig in the dialog box, then enter. This will start the System Configuration Utility 3 Go to the Startup tab and deselect/uncheck any entries related to either KAV or McAfee. Perform the same step after selecting the Services tab. 4 Restart normally If the system is stable (you may get some error messages on restart), uninstall the active product (i.e. the one whose entries you did not uncheck). Either after completing the uninstall but before a restart or after a full restart, rerun msconfig as described above and reenable the entries that were unchecked. Restart to bring up the reenable AV. Uninstall the remaining AV product. Use CCleaner to perform a quick clean of any orphaned registry entries, then reinstall the single product that you wish to use. In principle, you should be able to simply disable both AV's as described above and then uninstall the disabled products, but I've noticed an increased likelihood of orphaned files with some applications when this is done, hence the recommendation to uninstall while active (even though you often have to formally exit the application GUI). The recommendation to uninstall both then reinstall one is to minimize the likelihood of a partially corrupted install that may not be apparent early on. Blue
  • 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.