Jump to content

Recommended Posts

Even after the first intial scan, there is not much fragmentation of files and most is seen in the KAV report files being built up.

 

TR of KAV 7 with only IChecker enabled; not ISwift.

post-56-1180528489.gif

Share this post


Link to post
Even after the first intial scan, there is not much fragmentation of files and most is seen in the KAV report files being built up.

 

TR of KAV 7 with only IChecker enabled; not ISwift.

Just to keep on-track, the problem we are seeing is not directly a fragmentation problem, nor does it directly involve fragmentation of metadata. If it were, it could be fixed with a good defrag program. That is not the case; at least not for most of us.

 

The symptom again is a long pause (for me it's about 10 minutes) before stage 2 chkdsk. This is caused by KAV adding data to and/or rearranging the indexes when it scans. The role of ISwift or IChecker in this process is not clear to me. These changes to the indexes are not reversed when KAV is removed. Defrag programs do not fix or solve the problem.

 

My guess is it has something to do with ISwift, but the symptom is also created using the AOL licensed version of KAV (AVS). AVS does not have an option to turn ISwift or IChecker on/off. Further it is unclear to me who owns ISwift. The KB article on it suggests that it may be a product of "Intellectual Technologies."

 

Thus far the only fix seems to be to remove the indexes and rebuild them. Dantz has demonstrated that this works.

 

In my view, KAV (or Intellectual Technologies, whoever they are) should provide a tool which does the same thing. This is now a well-documented problem and the causes have been acknowledged by a member of the KAV development team. It's time for KAV to step up and take action.

Edited by jmorlan

Share this post


Link to post

Yes, a removal tool would be much easier to use, and in fact I find it fairly amazing that they have not yet provided one.

Share this post


Link to post
Yes, a removal tool would be much easier to use, and in fact I find it fairly amazing that they have not yet provided one.

Perhaps someone with more knowledge than I have could comment whether the 'Streams' program available from here:

 

http://www.microsoft.com/technet/sysinternals/FileAndDisk/Streams.mspx

 

would help to identify (and possibly allow removal of) the iSwift data from affected files?

Share this post


Link to post
Not quite. I didn't mention it in this forum, but in my ZoneAlarm thread I did state that since this problem began I sometimes get a program error when I try to run a Check Disk of C in Windows in read-only mode.

 

 

im sorry, BUT YOU DON'T READ AT ALL

 

IT IS NORMAL FOR CHKDSK TO REPORT ERRORS IN READ ONLY MODE AND THIS IS COMING FROM THE MICROSOFT SUPPORT ARTICLE ON THE SUBJECT

 

maybe now it'll get through to you <_<

Share this post


Link to post
im sorry, BUT YOU DON'T READ AT ALL

 

IT IS NORMAL FOR CHKDSK TO REPORT ERRORS IN READ ONLY MODE AND THIS IS COMING FROM THE MICROSOFT SUPPORT ARTICLE ON THE SUBJECT

 

maybe now it'll get through to you  <_<

Don't address other members in that tone squal, thats not ok, discuss the subject, otherwise you'll just get what you want..................a battle and a forgotten subject. :)

Share this post


Link to post

sorry Don,

 

information regarding that issue of errors during readonly mode has been posted and i have provided links, at various parts.

 

that is not a problem with kaspersky, but occurs when any program that writes data to the drive is running.

 

i have noticed when my chkdsk reaches 28% on stage 2.. it takes awhile.. this is likely related to the stage 2 pause bug. i think when i transfer my data over when i get a new hdd,.. i'll do so without moving the mft,.. im also wondering why it is necessary for iswift to add anything extra to the index's?... why not just create a index or database of sorts to store the data.

Share this post


Link to post
i have noticed when my chkdsk reaches 28% on stage 2.. it takes awhile.. this is likely related to the stage 2 pause bug. i think when i transfer my data over when i get a new hdd,.. i'll do so without moving the mft,.. im also wondering why it is necessary for iswift to add anything extra to the index's?... why not just create a index or database of sorts to store the data.

You would have to ask the developers regarding that, i a slight delay to stage 2 and thats it, nothing more through 100 builds.

Share this post


Link to post
im sorry, BUT YOU DON'T READ AT ALL

 

IT IS NORMAL FOR CHKDSK TO REPORT ERRORS IN READ ONLY MODE AND THIS IS COMING FROM THE MICROSOFT SUPPORT ARTICLE ON THE SUBJECT

 

maybe now it'll get through to you  <_<

 

The problem is not chdsk reporting errors, but chkdsk itself failing and being unable to run to completion, and I assure you it only started happening after I did a full scan of my hard drive with the KAV-based antivirus that comes with ZoneAlarm Security Suite.

 

I consider Check Disk (chkdsk) to be a vital system utility. If I have to choose between chkdsk running properly and having a particular antivirus program, I will choose chkdsk every time. I can always install another antivirus program, but I have only one filesystem.

Share this post


Link to post
The problem is not chdsk reporting errors, but chkdsk itself failing and being unable to run to completion, and I assure you it only started happening after I did a full scan of my hard drive with the KAV-based antivirus that comes with ZoneAlarm Security Suite.

 

I consider Check Disk (chkdsk) to be a vital system utility. If I have to choose between chkdsk running properly and having a particular antivirus program, I will choose chkdsk every time. I can always install another antivirus program, but I have only one filesystem.

 

as the article said, Chkdsk in Readonly mode reports many issues and in most cases fails to complete or reports a string of errors before reporting that a chkdsk in locked mode must be run.

Share this post


Link to post

The business about CHKDSK errors in read-only mode is a red herring and has nothing to do with the issue here. As far as I know, there is no evidence of actual disk corruption caused by KAV. Nevertheless, I believe the issue is serious and needs to be addressed in a more substantive way by KAV.

 

Perhaps someone with more knowledge than I have could comment whether the 'Streams' program available from here:

 

http://www.microsoft.com/technet/sysinternals/FileAndDisk/Streams.mspx

 

would help to identify (and possibly allow removal of) the iSwift data from affected files?

Actually Kaspersky formerly used Alternate Data Streams (ADS) in earlier versions of KAV but abandoned it in more recent versions. Also Kaspersky provided a removal tool when this came to light and I believe that tool is still available.

 

Interestingly the ADS did not have any noticeable effect on CHKDSK or much else performance-wise, other than fragmentation problems. The complaints stemmed more from a desire to be able to remove the useless ADS after KAV was uninstalled. The uninstaller did not remove them. Personally I believe they were pretty benign. The only issues involved disk fragmentation and possible conflict with other programs that might need ADS for some reason. I could be wrong on that so please correct me if I am.

 

This ISwift issue (if that's what it is) is something quite different and does not involved ADS. There are a number of programs that can detect and remove ADS (although ADS attached to certain system files can never be removed apparently). Whatever ISwift is doing to the indexes cannot be detected by any known method except by the observation of the long delay (mine is about 10 minutes) before CHKDSK stage 2. Some users also observe a delay during CHKDSK stage 2 and in a few serious cases, CHKDSK will not run to completion.

 

I'd like to add a few points which may be obvious to most, but just to be clear. This issue only occurs with the NTFS file system. Other file systems are not affected. The NTFS file system is proprietary with Microsoft and relatively few programmers understand it in any depth. If the ISwift technology was not written by Kaspersky, but licensed by Kaspersky from "Intellectual Technologies," KAV may not be in a position to do anything about it.

 

Nevertheless, KAV is selling a product with this technology and I think they need to do the responsible thing and provide a tool to remove it, just as they did in the past with the unwanted ADS.

Share this post


Link to post

iSwift is a newer technology which supercedes the iStreams, since people complained about it. However, that information was only available when the driver was active and even than information was properly validated. No other program could use and access that information. iSwift is not rented from anywhere and was developed to speed up the scanning routine. Yes it does indeed some internal tagging, but nothing out of the ordinary is being done. The driver which does this passes MS Logo certification. I do not think Microsoft would certify something that does not properly operate on an NTFS file system

Share this post


Link to post

well that brings us to the following :/

 

whats going on with the mft, to cause chkdisk to pause at the beginning, or take some time to read a certain area....

 

lol, also, MS Certification isn't the bee's knee's

 

the problem could very well be there and ms wouldn't know about it.. the tests they run aren't very thorough... look at the nforce 15.00 drivers that they let get past the labs...

 

 

just a little note to everyone getting this

 

you don't have to delete all the files to rebuilt the index's

 

simply get partition magic 7 or 8 and you'll be able to convert back to fat32, delete the now visible mft and volume bitmap files and then convert back to ntfs.

Edited by squall_leonhart69r

Share this post


Link to post

The iSwift does not directly touch $MFT in any way :)

If you switch OFF iSwift and iChecker would the problem still be there?

Edited by Whizard

Share this post


Link to post

i don't think switching it off would help, now that its already occured, chkdsk (/f mode) is done before the kaspersky driver is loaded so i doubt its whats causing the pause at the start, or at random points along the chkdsk,

 

from what i gather, the technology appends some sort of information to the end of the files index info, and the files index info is all stored in the mft. so it doesn't directly modify the mft, but in the end it still ends up with unecessary tagging info.... as i have said.. why do it this way (where it can cause problems) instead of just creating a index or database which kaspersky inputs data to.

Share this post


Link to post

iSwift works only for NTFS volumes for almost all files regardless of their position on the drive. iChecker works exactly as you say but has limited file type support but can do FAT32 :)

Share this post


Link to post
iSwift works only for NTFS volumes for almost all files regardless of their position on the drive. iChecker works exactly as you say but has limited file type support but can do FAT32 :)

Whizard, could you please clarify a few things for us? Are the changes to the index files discussed by Lucian Bara in these messages, put there by iSwift?

 

http://forum.kaspersky.com/index.php?showt...71entry277671

http://forum.kaspersky.com/index.php?showt...24entry277724

 

The CHKDSK issue has been reported by users of AVS. Is iSwift enabled by default in the AOL licensed version of KAV (AVS)?

 

This FAQ states that iSwift was developed by "intellecutual technologies."

 

http://www.kaspersky.com/faq?qid=186010624

 

Who are they and what is their relationship with Kaspersky? It also states that an "NTFS-identifier is given to each object." Is this identifier added to the indexes? Is this the additional information that Lucian Bara references in the above links?

 

When KAV or AVS is removed from a system, are the NTFS-identifiers removed also? If not, can you or somebody please provide a tool to remove them? It appears that this extra data is causing CHKDSK to delay before or during stage 2 on some systems and in a few cases is preventing CHKDSK from running to completion.

 

For many this is merely an annoyance, for others it's a deal breaker.

 

Thank you very much for your participation in this thread.

Share this post


Link to post
This FAQ states that iSwift was developed by "intellectual technologies." 

 

http://www.kaspersky.com/faq?qid=186010624

 

Who are they and what is their relationship with Kaspersky?

I am fairly certain that that phrase is a result of a poor translation from Russian into English. It should probably be proprietary technologies, i.e., technology developed in-house by KL, the actually technology of which is a guarded trade secret and is wholly owned by KL.

 

Ron :)

Share this post


Link to post
I am fairly certain that that phrase is a result of a poor translation from Russian into English. It should probably be proprietary technologies, i.e., technology developed in-house by KL, the actually technology of which is a guarded trade secret and is wholly owned by KL.

 

Ron :)

I admire your intuition concerning Russian phraseology, Ron. You are absolutely right... ;) The only other possible interpretation of the original Russian word would be 'intelligent', but this still does not refer to any company other than Kaspersky itself...

 

Paul

Edited by p2u

Share this post


Link to post
I admire your intuition concerning Russian phraseology, Ron. You are absolutely right... ;) The only other possible interpretation of the original Russian word would be 'intelligent', but this still does not refer to any company other than Kaspersky itself...

 

Paul

That makes sense and it's good to know. But the big question remains. How do we get rid of the "NTFS-identifiers" put there by iSwift?

 

I believe these NTFS-identifiers are the likely cause of the Stage 2 CHKDSK pauses and they are not removed when KAV is removed.

Share this post


Link to post

To simply put you can't. And since technology is propriatory and heavily guarded we might never find out.

Share this post


Link to post
To simply put you can't. And since technology is propriatory and heavily guarded we might never find out.

That's extremely disappointing.

 

In fact Dantz has demonstrated one way of removing the NTFS-identifiers by deleting and restoring data. Another possibility is to convert to Fat32 and back to NTFS using a third party utility. In these cases the indexes will be rebuilt fresh without the NTFS-identifiers placed there by iSwift.

 

Since the iSwift NTFS-identifiers added to the indexes may cause CHKDSK problems for some of us (mine is a 10 minute delay before the start of stage 2), I think Kaspersky should offer a mechanism to undo the damage they have done to the file system. They did the responsible thing and supplied such a tool for iStreams. However the lessons from iStreams do not seem to have been learned. Once you do something to the file system, one cannot foresee all possible consequences in every system.

 

I think it is incumbent on the developers of the iSwift technology to provide a mechanism for removal. Failure to do so is patently irresponsible in my opinion. :(

Share this post


Link to post
That's extremely disappointing.

 

In fact Dantz has demonstrated one way of removing the NTFS-identifiers by deleting and restoring data.  Another possibility is to convert to Fat32 and back to NTFS using a third party utility.  In these cases the indexes will be rebuilt fresh without the NTFS-identifiers placed there by iSwift. 

 

Since the iSwift NTFS-identifiers added to the indexes may cause CHKDSK problems for some of us (mine is a 10 minute delay before the start of stage 2), I think Kaspersky should offer a mechanism to undo the damage they have done to the file system.  They did the responsible thing and supplied such a tool for iStreams.  However the lessons from iStreams do not seem to have been learned.  Once you do something to the file system, one cannot foresee all possible consequences in every system. 

 

I think it is incumbent on the developers of the iSwift technology to provide a mechanism for removal. Failure to do so is patently irresponsible in my opinion.  :(

 

How does this problem affect the average user? Is the only problem a 10 minute delay if you use chkdsk?

Share this post


Link to post
The average user would never notice it. :)

I'm not really an Average Joe, but I have no issues with any of the CHKDSK stages after the KIS uninstall. Maybe that has to do with the fact that I put the KIS/KAV Removal Tool in the root of each disc on my computer and repeated the removal procedure for each disc separately?

 

Paul

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.