Jump to content

Recommended Posts

Just to chime in here, I've recently installed AOL's Active Virus Shield, which, apart from the issues mentioned here, appears to have meddled with the boot drive's security settings, causing all kinds of error messages about a corrupt C: drive, and corrupt/inaccessible files. Running CHKDSK at boot time would result in a stream of "Inserting an index entry into index $0 of file 4442" messages.

Fortunately, I was able to reset the security settings, which also appears to have cleared up that particular CHKDSK error.

However, on the boot drive (a 500GB PATA drive with about 160GB free), there's still a lag of over 20 (!) minutes before pass 2 starts! BTW, this may have initially led me to believe CHKDSK was hung, and pushing the reset button, which _may_ have caused the security errors...

Needless to say, I've uninstalled Active Virus Shield, and gone back to AVG.

 

Since my system (Windows 2000 SP4) isn't the most stable one, I have to hit the reset button every now and then, and like to run CHKDSK afterwards as a precaution. Obviously, this 20 minute lag is a major inconvenience! BTW, this same lag also exists when the system is booted using a BartPE XP rescue CD.

 

Fortunately, I still have my Linux system for email and web browsing, which was a big help in getting the Windows system up and running again...

 

Ellen

Share this post


Link to post

hopfuly they fix this for even aol avs as it is a kaspersky engine i don't have any problems as of now but would like a tool to remove it in the future if problems hapen about.

 

Edit: Stop asking for a tool every day! If & when a tool is available you can be 100% sure i will post a link to it here, so no need to post the same everyday. smile.gif

Edited by Don Pelotas

Share this post


Link to post
My experience is similar to MAPKOBA^^'s. I have used plenty of v6 and v7 builds (including Beta .055) and my computer has not exploded, imploded, mutated nor spontaniously cumbusted. It has never told me that it needs to do a CHKDSK or that it is recomended that I do a CHKDSK. I have seen such prompts on other machines stateing need to run CHKDSK, but those machines never saw KIS. My CHKDSK is unchanged since I Have been using KIS. I am confident that KIS will not prevent CHKDSK from doing its thing in life, in a timely manner. Any AV will not be unnoticable, at many levels, once installed on a machine. If I were a professional AV tester, I would have professional hardware and software on tap so I can revert as I go from AV "n" to AV "n+1" as "n" approaches infinity. My ego has accepted the fact that I am not a professional AV tester, so having finally found a security suite that I am happy with, I have humbly accepted the fact that it will lock itself down into my system in ways that I may not be technologicaly advanced to understand.  Thank you for the live link. The dead version of the same link was posted in this forum in a different thread about a week ago.  EDIT: Grammer, punctuation, spelling and math errors (but not all).

393416[/snapback]

Great post.

 

Swift and Checker have been enabled since initial install w/ full molestation privileges of all my drives/data .. yet, I remain chkdsk problem-less. I know I didn't just advance the effort to solve the problem for those so effected .. just sharing my status.

 

Oh, one last thing .. from someone who's owned/used 300 baud modems up to formerly using Avira's suite prior (and all the other "security" crap in-between) .. KIS still is amazing to me. It is, imho, "the" gorilla in the forest.

 

 

Share this post


Link to post

This is an note to both KAV users and KAV developers.

 

----

 

Let me first give some additional background on this since I see that there is quite some confusion about this around the net and several things are mixed...

 

In version 5 (and some of it already in version 4.5 if I remember right) KL (Kaspersky Lab) has introduced two new technologies to its anti-virus products to speed up scanning time by not rescanning objects that ware recently scanned and not modified since then (I think Sophos was actually first to use something like this). This two technologies ware called iStreams and iChecker. iChecker worked by saving the needed informations in memory while iStreams saves them as an NTFS ADS (alternate data stream) to each file. This is not something very strange, for example IE places an ADS to all the files it downloads to be able to warn you that this file was downloaded from internet.

 

To protect its ADS from malware, KAV (Kaspersky anti-virus) has additionally "lock" them with "rootkit" like technology. Please don't freak out on the word rootkit, all security product need to do this this days if they want to be able to fight today complex malware. To be more precise this "rootkit like technologies" are mostly different types of kernel and user mode hooks to system functions.

 

OK back to iStreams. The problem with them was that different anti-rootkit tools ware starting to detect allot of suspicious rootkit like objects (since the KAV ADS ware protected and hidden). So KL decided to remove iStreams from version 6. It also provided standalone and build in tools to remove its ADS after KAV was uninstalled from the system, so one was able to completely clean his system of this. iStreams and its ADS have NOTHING to do with the chkdsk issue.

 

There ware two technologies iChecker and iStreams because each of them has its limitations. So since KL has removed iStreams in version 6 they have replace it with new technology called iSwift. iSwift stores the needed informations to special database files and because of the speed issues also uses some of the NTFS functionality to monitor when an object (file) is changed. KAV makes no changes directly to your files (and never has) it only uses some of the available NTFS technology for the file table (indexes).

 

YES the thing with chkdsk is an issue and it is known since the very first beta builds of version 6. However from millions of computers that have KAV installed, from what I know, there is NOT a single report that this would actually do any REAL damage to your disk, file system or your files. I use KAV myself on several systems and will continue to use it, since all this seems to do is to make the second stage in chkdsk scan a bit longer (because of the additional informations from KAV that needs to be checked).

 

I do however agree that KL should make some more research in to this and provide some more detailed informations. Some of us (users) have tried to give some answers on this issue but this seems no longer to be enough, mostly because it seems that no one really knows what exactly is going on here. And the only known way, for now, to remove this after you uninstall KAV is to move all of the files from the disk and then back so that the NTFS creates new indexes for them.

 

To conclude, personally I think there is allot of FUD (Fear, uncertainty and doubt) going on about this issue and that there ware some users that had real hard disk problems and ware blaming KAV for it. Because of all this there is allot of wrong conclusions, speculations and confusion going on about this.

 

On the other hand, I do think KL should do something about it and make a stand point on this issue mostly because all this FUD seem to be reaching an critical mass and KL is loosing old and new users because of this. Unfortunately to some users KAV seems to be known as "the AV that damages your computer" and the number of such users seems to be growing.

 

----

 

And about the speculations that AOL has dumped KAV because of this issue...

 

IMO this is pure speculation and holds no more water then if we say that KL has dumped AOL because allot of KAV users ware complaining to KL how they can team up with someone like AOL that is installing additional adware/spyware together with KAV package and by doing this throwing dirt on the great name of Kaspersky.

 

I don't want to sound as an Kaspersky fan boy, if someone is able to provide some real informations and details about this I am willing to accept and agree on it, but all I see is allot of FUD going on about this on different forums and newsgroups.

Edited by saso

Share this post


Link to post
This is an note to both KAV users and KAV developers.

 

----

 

Let me first give some additional background on this since I see that there is quite some confusion about this around the net and several things are mixed...

411107[/snapback]

Very much appreciate you sharing this information and your insight, particularly the historical clarifications. Thanks.

 

 

Share this post


Link to post
There ware two technologies iChecker and iStreams because each of them has its limitations. So since KL has removed iStreams in version 6 they have replace it with new technology called iSwift. iSwift stores the needed informations to special database files and because of the speed issues also uses some of the NTFS functionality to monitor when an object (file) is changed. KAV makes no changes directly to your files (and never has) it only uses some of the available NTFS technology for the file table (indexes).
While KL is using available NTFS functionality, I believe the key question from the user base is whether or not the file object ID's created are implicitly presumed to be sparse objects by some applications, and if they are not and under some circumstances, whether unpredictable results may follow. iSwift appears to use this feature outside of it's designed scope. That should always be approached with extreme caution (actually, one simply shouldn't go down that path....).

 

I use KAV myself on several systems and will continue to use it, since all this seems to do is to make the second stage in chkdsk scan a bit longer (because of the additional informations from KAV that needs to be checked).
Basically the same here as well.

 

And the only known way, for now, to remove this after you uninstall KAV is to move all of the files from the disk and then back so that the NTFS creates new indexes for them.
As posted here already, to query file object ID's, the command

 

FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Query "%a"

can be employed or, to delete them, use

 

FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Delete "%a"  

This basically operates at the drive/folder level from which it is invoked and walks down the directory tree. To clean a drive, start at the root folder. One can use the file copy scheme, but this is a "known" approach as well and the only approach if you don't have the sparse storage space available.

To conclude, personally I think there is allot of FUD (Fear, uncertainty and doubt) going on about this issue and that there ware some users that had real hard disk problems and ware blaming KAV for it. Because of all this there is allot of wrong conclusions, speculations and confusion going on about this.
While there is clearly more than enough FUD going around, dismissing the problem as unrelated to KAV is as bad as immediately ascribing the primary cause to KAV. All the available data implicates KAV, but it is unclear whether iSwift is a primary cause or a secondary factor.

On the other hand, I do think KL should do something about it and make a stand point on this issue mostly because all this FUD seem to be reaching an critical mass and KL is loosing old and new users because of this. Unfortunately to some users KAV seems to be known as "the AV that damages your computer" and the number of such users seems to be growing.
KL's handling of this is basically a case study on what not to do.

And about the speculations that AOL has dumped KAV because of this issue...
I agree, it's actually a rather ridiculous speculation if you think about it.

I don't want to sound as an Kaspersky fan boy, if someone is able to provide some real informations and details about this I am willing to accept and agree on it, but all I see is allot of FUD going on about this on different forums and newsgroups.

411107[/snapback]

In the absence of firm technical information, speculation will always run rampant. That's why I personally find KL's relative silence incredible - passively asking to "send logs and/or images" is not actively managing the situation.

 

Blue

 

Share this post


Link to post

Thank you Blue for this post. Yes i have found this information from deXter_ few hours ago an I am right now heavily testing this.

 

I don't know for how long this information is known, it is new to me, but I think it is very important since at least it exactly shows what is going, that KAV is not doing some strange modifications to the file system or files, but that it is using an well known and documented NTFS feature which the operating system itself is using. However it is true that KAV is using this much more heavily.

 

One more very important news here is that there is an command line tool on every windows machine that makes it possible to create, modify, query and delete this ObjectIDs. Delete beaning the important function here since it is widely spread that there is nothing one can do about this changes.

 

I was going to keep this information from deXter_ a secret a for a bit longer since there are some comments that the above command for removing ObjectIDs from all the files can cause some problems. So I think this has to be tested to provide a safe removal.

 

In any way I think this informations from deXter_ are a great step froward to solving and closing this issue once and for all.

 

While there is clearly more than enough FUD going around, dismissing the problem as unrelated to KAV is as bad as immediately ascribing the primary cause to KAV.  All the available data implicates KAV, but it is unclear whether iSwift is a primary cause or a secondary factor.

 

IMO the important thing to answer here was the information on what exactly is going on. Of course it is KAV that is doing this, the big confusion from what I was able to see was, what it is doing. The FUD that was going around was that it is doing some very strange things to your files and damaging your disk. From the informations from deXter_ (and I did several test to confirm them) I see nothing weird or dangerous going on here.

Edited by saso

Share this post


Link to post
....I think it is very important since at least it exactly shows what is going, that KAV is not doing some strange modifications to the file system or files, but that it is using an well known and documented NTFS feature which the operating system itself is using. However it is true that KAV is using this much more heavily.
It's more than just heavy use of a standard facility, it is use of a facility outside the scope of it's design objectives. That's important since it can generate unintended consequences. Again, in a normal file system, file object ID's should be sparse.

I was going to keep this information from deXter_ a secret a for a bit longer since there are some comments that the above command for removing ObjectIDs from all the files can cause some problems. So I think this has to be tested to provide a safe removal.
I don't have objective proof, but I believe that these cautions really only apply to a networked domain. It should be irrelevant to a standalone home user.

The FUD that was going around was that it is doing some very strange things to your files and damaging your disk.
I do believe that the various threads going around have been long on speculation and short on facts, or even objective quantitative information. It should be clear that this facility should not directly damage a disk or file. However, if used beyond it's design scope, the issue of an unintended cascade of events doing precisely that should not be dismissed out of hand. This is the reason design scopes exist.

 

Blue

Share this post


Link to post
This is an note to both KAV users and KAV developers.

 

----

 

Let me first give some additional background on this since I see that there is quite some confusion about this around the net and several things are mixed...

 

 

I will state it has caused damage to my computer! When the index or that gets corrupted and this stops chkdsk from running at all.. That is damage to a persons system! I had to use an external utility made by someone else to get rid of all ObjectID's before chkdsk would run. So UNTIL I was able to run it I was having programs go berserk on me when launching them since they would infinitely try to load because of some invalid corruption or pointer! Totally would crash my system. But after using the above mentioned utility I was able to run scandisk.. let it repair crossed files and bad indexes.. and I was back in operation.

 

On a very large drive with a very large amount of files.. chkdsk delay would cause it to fail because after 20 minutes or so it would report it could not complete.. and this was on stage 2 like everyone else but the sheer drive size and file sizes stopped it from running at all.

Share this post


Link to post

Using the scripts suggested by deXter_ on my 65% full 420GB partition, I managed to delete most of the ObjectIDs. (some files were locked by the system, so their ObjectIDs would have to be removed using a different boot partition or medium)

This way, I was able to reduce the CHKDSK stage 2 delay from 22 minutes down to 30 seconds! So far, this doesn't appear to have affected file system integrity, or program execution...

Share this post


Link to post
Using the scripts suggested by deXter_ on my 65% full 420GB partition, I managed to delete most of the ObjectIDs. (some files were locked by the system, so their ObjectIDs would have to be removed using a different boot partition or medium)

This way, I was able to reduce the CHKDSK stage 2 delay from 22 minutes down to 30 seconds!  So far, this doesn't appear to have affected file system integrity, or program execution...

411582[/snapback]

 

Did you uninstall KAV/KIS before doing this, doing this could allow to remove some more? Maybe running the command in safe mode will also help to remove some more of them.

Share this post


Link to post
I will state it has caused damage to my computer!  When the index or that gets corrupted and this stops chkdsk from running at all.. That is damage to a persons system!  I had to use an external utility made by someone else to get rid of all ObjectID's before chkdsk would run.  So UNTIL I was able to run it I was having programs go berserk on me when launching them since they would infinitely try to load because of some invalid corruption or pointer!  Totally would crash my system.  But after using the above mentioned utility I was able to run scandisk.. let it repair crossed files and bad indexes.. and I was back in operation.

 

But can you be sure that the actual damage, corruption, was actually done by KAV and not for example because of some bad sector or something similar? IMO one could not blame KAV in such case.

 

On a very large drive with a very large amount of files.. chkdsk delay would cause it to fail because after 20 minutes or so it would report it could not complete.. and this was on stage 2 like everyone else but the sheer drive size and file sizes stopped it from running at all.

411423[/snapback]

 

Yes, I will agree with you on this one. Having very large number of files and an slow CPU could cause something like this.

 

Share this post


Link to post
But can you be sure that the actual damage, corruption, was actually done by KAV and not for example because of some bad sector or something similar? IMO one could not blame KAV in such case.

Yes, I will agree with you on this one. Having very large number of files and an slow CPU could cause something like this.

411726[/snapback]

 

The damage was that KIS broke Chkdsk which if you have a file corruption and it can't run.. it can't get fixed.. and of course file corruption just continues to get worse as time goes on if you don't run chkdsk.. eventually it starts computer lockups.

 

And on the second part not a slow computer.. AMD 64 3000+ with a Gig of dual channel DDR PC3200 ram is not a slow computer.. but the HUGE amount of files to fill up nearly 500GB of HD is huge and will slow chkdsk with the KIS issue. Now it's down to about a minute to run complete from never finishing after removing these ojbect id's.

 

Share this post


Link to post
Did you uninstall KAV/KIS before doing this, doing this could allow to remove some more? Maybe running the command in safe mode will also help to remove some more of them.

411721[/snapback]

Yes, I uninstalled Kaspersky (actually, AOL Active Virus Shield) before deleting the ObjectIDs. Didn't try removing them in safe mode yet, though...

 

Share this post


Link to post

Hi,

 

Just to keep you informed. We have reproduced the issue with chkdsk slowdown and it looks like we understand why it happens. Unfortunately the problem is inside chkdsk and we now work with MS team. I'll inform you as soon as we find some solution.

 

If anyone can reproduce "chkdsk /f" failure and provide us the image of your drive - please contact me directly. I don't track forum.

Share this post


Link to post
Hi,

 

Just to keep you informed. We have reproduced the issue with chkdsk slowdown and it looks like we understand why it happens. Unfortunately the problem is inside chkdsk and we now work with MS team. I'll inform you as soon as we find some solution.

 

If anyone can reproduce "chkdsk /f" failure and provide us the image of your drive - please contact me directly. I don't track forum.

413211[/snapback]

Well done Talec - good to hear you're getting somewhere at last. Perhaps we'll eventually get a new version of CHKDSK from Microsoft!

Share this post


Link to post

I would like to know if this issue affects users of either KAV or AOL's AVS who are running Vista.

 

I know that Vista's NTFS is different than the NTFS in previous versions of Windows (see http://en.wikipedia.org/wiki/Transactional...nsactional_NTFS ), and I don't recall hearing any complaints from anyone about having a slow chkdsk who also identified themselves as running Vista.

Share this post


Link to post
I would like to know if this issue affects users of either KAV or AOL's AVS who are running Vista.

 

I know that Vista's NTFS is different than the NTFS in previous versions of Windows (see http://en.wikipedia.org/wiki/Transactional...nsactional_NTFS ), and I don't recall hearing any complaints from anyone about having a slow chkdsk who also identified themselves as running Vista.

414539[/snapback]

 

I have Vista, using KIS 7 with iSwift enabled, and I have a lot of files. I have a chkdsk slowdown of about 6 seconds at stage 2. It does not seem to be getting worse.

Share this post


Link to post
I have Vista, using KIS 7 with iSwift enabled, and I have a lot of files. I have a chkdsk slowdown of about 6 seconds at stage 2. It does not seem to be getting worse.

414549[/snapback]

 

 

Hmm. So apparently this *does* affect Vista. Thank you for your response.

Share this post


Link to post
This is an note to both KAV users and KAV developers.

----

 

On the other hand, I do think KL should do something about it and make a stand point on this issue mostly because all this FUD seem to be reaching an critical mass and KL is loosing old and new users because of this. Unfortunately to some users KAV seems to be known as "the AV that damages your computer" and the number of such users seems to be growing.

 

411107[/snapback]

Hello all.

 

First of all, thank you Saso for the great post! You are right (and very clear) in your first 5 paragraphs about the history of iSwift/iStreams/iChecher technologies.

 

I want to provide some information about the internals of iSwift technology:

1) we use a special feature of NTFS - "object identifier", "optional attribute that uniquely identifies a file or directory on a volume"...

"An index of all object IDs is stored on the volume. Rename, backup, and restore operations preserve object IDs. However, copy operations do not preserve object IDs, because that would violate their uniqueness."...

"You can perform the following operations on object IDs: Creation, Deletion, Query"

(http://msdn2.microsoft.com/en-us/library/aa363997.aspx)

 

2) we use a documented API to create objectID for scanned files

http://msdn2.microsoft.com/en-us/library/aa364230.aspx and "NTFS file system generate an object identifier if one does not exist"

 

3) After the Windows installation an index of all object IDs can be about 2Mb

And after Full Scan on average disk this index can store 200Mb and more - because of this documented NTFS feature (see points 1,2).

 

4) CHKDSK on stage 2 try to check some NTFS indexes including the index mentioned above (NTFS record #19h on any volume). And the problem is CHKDSK does not show the scan progress of such big index.

 

That's all. Let's wait for MS answer about this issue.

And sorry for our previous silence.

Share this post


Link to post

See http://support.microsoft.com/default.aspx?...kb;en-us;187941

Read the fine print. Stage 2 slowdowns are to be expected. Even if it appears to hang for a period of time, that is normal. Kaspersky is asking if anybody has problems that are much worse than a teeny weeny slowdown. Even medium slowdowns are normal. Would you believe that even kind of biggish stage 2 slowdowns are normal, even on PC's that have never seen Kaspersky? Several minute stage 2 slowdowns have been around since the Pre-Cambrian Era was late breaking news. If the link is dead, oops. None of the smilies match how I feel right now. Bye, I gotta go brush my teeth for six seconds. Maybe next week it will be for 22.375 seconds.

 

The same is not necessarily true for the second phase of CHKDSK. The amount of time required to process a directory is closely tied to the number of files or subdirectories listed in that directory. But the percent complete listed during this phase is the percent of the number of directories to be examined without regard for the fact that some directories might take much longer than others to process. For example, on a volume with many small directories and one very large one, the percent complete might progress rapidly from 0 to 10 percent complete and then appear to get stuck for a long period of time before rapidly progressing from 10 to 100 percent complete. Therefore, unless you know for certain that the directories on a volume are highly uniform with respect to the number of files they contain, the displayed "percent complete" during this phase cannot be considered a reliable representation of the actual time remaining for this phase.

(Excerpt from above link)

Share this post


Link to post
See http://support.microsoft.com/default.aspx?...kb;en-us;187941

Read the fine print. Stage 2 slowdowns are to be expected. Even if it appears to hang for a period of time, that is normal. Kaspersky is asking if anybody has problems that are much worse than a teeny weeny slowdown. Even medium slowdowns are normal. Would you believe that even kind of biggish stage 2 slowdowns are normal, even on PC's that have never seen Kaspersky? Several minute stage 2 slowdowns have been around since the Pre-Cambrian Era was late breaking news. If the link is dead, oops. None of the smilies match how I feel right now. Bye, I gotta go brush my teeth for six seconds. Maybe next week it will be for 22.375 seconds.

 

The same is not necessarily true for the second phase of CHKDSK. The amount of time required to process a directory is closely tied to the number of files or subdirectories listed in that directory. But the percent complete listed during this phase is the percent of the number of directories to be examined without regard for the fact that some directories might take much longer than others to process. For example, on a volume with many small directories and one very large one, the percent complete might progress rapidly from 0 to 10 percent complete and then appear to get stuck for a long period of time before rapidly progressing from 10 to 100 percent complete. Therefore, unless you know for certain that the directories on a volume are highly uniform with respect to the number of files they contain, the displayed "percent complete" during this phase cannot be considered a reliable representation of the actual time remaining for this phase.

(Excerpt from above link)

414725[/snapback]

Good info in for a topic that has been on multiple sites and seen threads with a lot of misinformation and just plain FUD. Especially the stories of chkdsk erroring out and actual File System Corruption. Edited by jonnyjl

Share this post


Link to post
Hello all.

 

First of all, thank you Saso for the great post! You are right (and very clear) in your first 5 paragraphs about the history of iSwift/iStreams/iChecher technologies.

 

I want to provide some information about the internals of iSwift technology:

1) we use a special feature of NTFS - "object identifier", "optional attribute that uniquely identifies a file or directory on a volume"...

"An index of all object IDs is stored on the volume. Rename, backup, and restore operations preserve object IDs. However, copy operations do not preserve object IDs, because that would violate their uniqueness."...

"You can perform the following operations on object IDs: Creation, Deletion, Query"

(http://msdn2.microsoft.com/en-us/library/aa363997.aspx)

 

2) we use a documented API to create objectID for scanned files

http://msdn2.microsoft.com/en-us/library/aa364230.aspx and "NTFS file system generate an object identifier if one does not exist"

 

3) After the Windows installation an index of all object IDs can be about 2Mb

And after Full Scan on average disk this index can store 200Mb and more - because of this documented NTFS feature (see points 1,2).

 

4) CHKDSK on stage 2 try to check some NTFS indexes including the index mentioned above (NTFS record #19h on any volume). And the problem is CHKDSK does not show the scan progress of such big index.

 

That's all. Let's wait for MS answer about this issue.

And sorry for our previous silence.

414711[/snapback]

 

Um i thought that the they were normal delays myself but they are not i actualy had it so bad that i finaly had to reformat both my pc with aol AVS on them and went to a difrent antivirus. dont ignore stage 2 delays for two long they will eventualy slow down to the point to were they sit forever and well ovintaly complet or not.

Share this post


Link to post

I'd been running AOL's AVS on my Vista Ultimate box for a few weeks. I'd done one full system scan immediately after installing AVS, after which my chkdsk was speedy and normal, pausing at 10% during stage 2 for only a couple of seconds.

 

Concerned about this chkdsk situation, though, I uninstalled the AVS today. Afterward, chkdsk (of my system partition C) ran quickly as usual, but the first time Vista loaded, it loaded unusually slowly. On subsequent reboots, Windows loaded at roughly its usual speed. But each time I ran chkdsk on C (at boot), the same thing happened: the first time Vista loaded, it loaded unusually slowly.

 

After removing AVS, I also opened "Computer" ("My Computer" in previous versions of Windows) and ran chkdsk on my data partitions (D, E, F). In each case, chkdsk proceeded quickly and reported no errors. Afterward, however, and also in each case, my "Computer" (formerly "My Computer") went into a Not Responding state. This had never happened before installing the AOL AVS.

 

My chkdsk seems to have problems . . .

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • 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.