Jump to content

Recommended Posts

i run all beta builds, with freezes, crashes etc. hard resets...was never prompted to run a chkdsk and never have. i haven't lost a file to corruption yet. so even if chkdsk doesn't run it won't mean your files are corrupted, and if it run you'll end up with a chk file which you can't do nothing with

428285[/snapback]

 

Your misunderstanding I live in lightning capital of the world.. So UPS only last about 6-12 months max before we have to buy new ones due to batteries completely run out. I have not been able to afford a new one right now so power outages and brown outs cause corrupted files.. computer crashes also cause corrupted files. Chkdsk is required to repair bad indexes, crosslinked files, ect that happen from this. Now if chkdsk can not run than chkdsk can not fix these files.. And the files will continually get worse until the system itself can not run properly at all. Hence damage to my system because chkdsk can not complete to repair these soft errors.

Share this post


Link to post
this is not possible from the implementation point of view.
Lucian,

 

Never say never.

object id is a string contained in a file and in the index file, and having file id's is nothing special, it's a documented feature. it doesn't corrupt files.
Directly, you're quite correct. Can a series of events involving this facility conspire to send your system spiraling down the rabbit hole? I don't know. What I do know is that this facility was not used for it's designed purpose with iSwift. Behind designed purposes one oftentimes has implicit assumptions and those implicit assumptions can sometimes be coded into programs and OS's. It is always extremely unwise, and basically foolhardy, to use facilities beyond their intended purpose. That courts problems, but this is what the developers did.

also copying the files to another medium removes the object identifiers from the file (and theoretically from indexes too), and other file systems then ntfs can't have file identifiers. so for example fi you copy a file to a dvd you have no object ID. your corruption came from something other then the IDs, these only account for a chkdsk hang which is anything but file corruption.

428239[/snapback]

You simply cannot know that with certainty that the corruption experienced by users is exclusively due to other factors, by the same token, these users cannot unambiguously ascribe it to file object ID's either. The connection may be real, it may be happenstance. Nobody knows.

 

This continued harping that it simply cannot be due to KAV/KIS, with absolutely no empirical evidence to back up the claim aside from an understanding of how these features should function in an idealized and perfect setting is, in fact, a major part of the issue facing KL. It is what has polarized opinion on iSwift and whether or not to worry about this facility.

 

Personally, I think most of the concern is misplaced. I don't believe that current or potential users should be using this issue as a make or break item in a decision to purchase KAV/KIS. At this point, the development of apparent genuine corruption is a very low frequency event.

 

However, it shouldn't be causally dismissed as you do above. Those users experiencing genuine corruption are severely affected. The fact that you run betas, have freezes, crashes, and so on, all the time and suffer no issues is basically irrelevant. It is like any other software issue - simply because you don't experience it doesn't mean it's not real. I've run plenty of the KAV/KIS beta's as well. The only times I've experienced problems were with prototype builds. I've never had an issue with any of the beta's going back to the earliest releases. Does that mean the crashes and freezes you experienced didn't happen? Of course not - my system is different, my usage is different, and my results are different as well. The issues experienced by users in the field involving KAV/KIS and iSwift are no different. Different systems, different usage profiles, different and sometimes very unfortunate results - which may or may not be directly or indirectly related to iSwift. That's why I watch this topic. I think most of the concern is misplaced for a variety of reasons, but I don't know that to be the case.

 

Regards,

 

Blue

Share this post


Link to post
my comment about freezes was reffering to the fact that chkdsk is failing resulting in crosslinked files etc. and fiel corruption, which is not true, if chkdsk doesn't run it does'nt neccesarily mean that you get corrupted files simply because it won't finish the job. it's a simple analysis tool, it has no protection system or anything like that.

428300[/snapback]

Chkdsk is an analysis and system maintenance tool. It can nip problems in the bud, while they are still readily resolved, before they develop into system-wide issues. If you cannot successfully run chkdsk, and your file system is becoming increasingly corrupted, at some point your system may become inoperable (it depends where the corruption resides) and a full reformat will be required. That's the underlying issue. As noted here:
When disk corruption is detected on a volume, there are three basic options for response.

 

The first option is to take no action. On a mission-critical server that is expected to be online 24 hours a day, this is often the choice of necessity. The drawback is that relatively minor corruption can snowball into major corruption. Therefore, consider this option only if keeping the server online is more important than guarding the integrity of the data that is stored on the corrupted volume. All data on the corrupted volume should be considered "at risk" until you run CHKDSK. The second option is to run a full CHKDSK operation to repair all file system data and restore all of the user data that can be recovered by means of an automated process. However, running a full CHKDSK operation can cost you several hours of downtime for a mission-critical server at an inopportune time. Your third option is to run an abbreviated CHKDSK operation by using one or both of the /C and /I switches, to repair the kinds of corruption that can snowball into bigger problems in much less time than a full CHKDSK requires.

 

Note however that running an abbreviated CHKDSK does not repair all of the corruption that might exist. You still need to run a full CHKDSK at some future time to guarantee that all recoverable data has in fact been recovered.

 

Note also that NTFS does not guarantee the integrity of user data after an instance of disk corruption, even if you immediately run a full CHKDSK operation. There might be files that CHKDSK cannot recover, and files that CHKDSK does recover might still be internally corrupted. It remains vitally important that you protect mission-critical data by performing periodic backups or by using some other robust method of data recovery.

While they explicitly mention servers, the comments apply to any system.

 

Blue

Share this post


Link to post
Oh dear... looks like we have a pack of vultures circling  ph34r.gif  (Joke, not literally)  wink.gif

This problem isn't going to magically fix itself when one of you/us clicks your fingers, you have to understand that this (although an issue that has been dragging on for a while) KL are working to fix it. Sitting on here and sharing conspiracy theories does not solve the problem.... nor will it bring about a fix any quicker.

My 0.01 cents worth.

425486[/snapback]

Hi,

please let me express a non-technical, personal opinion about the whole question. I absolutely agree with what MAPKOBKA^^ has written in the above post. I think that this topic is striding to a very useless point. Kaspersky Lab is working on the reported problem: that's all. Why keep on complaining? Who may benefit from such further complaints? Nobody, I would say. Thank you for having listened to me too. smile.gif

Share this post


Link to post
I think that this topic is striding to a very useless point.
Yes and no. If it's pure whining of "when will it be fixed", I'd say you're right. If it's a somewhat more balanced/crystallized view of the situation, I'd say no, it is worth stating for concerned current and future customers - unless you'd prefer that they walk to another vendor for lack of information....

Kaspersky Lab is working on the reported problem: that's all. Why keep on complaining? Who may benefit from such further complaints? Nobody, I would say. Thank you for having listened to me too.  smile.gif

428324[/snapback]

If you wade through this and other threads on the topic, lots of key information gets lost in the shuffle. For example:
  • There are two distinct problem threads:
    • A general phase 2 chkdsk slowdown that is to be expected and should not be a real concern for anyone and,
    • A more problematic situation that occurs when chkdsk cannot complete. In isolation, this does not mean there are irrecoverable issues. However, if this behavior is seen, I would recommend uninstalling KAV/KIS and examining the system further.
  • The number of instances of the second issue appearing are quite limited - perhaps a dozen to a few dozen casually reported instances. I actually recall less than a dozen that I'd firmly classify as the second issue.
  • It is unclear whether the second issue is a direct result of iSwift, whether some of the secondary consequences of iSwift exacerbate unrelated problems (i.e. filesystem corruption which remains unfixed due to chkdsk execution issues that evolve into major system problems), or whether iSwift is an innocent party to the reported problems. While there are suspicious correlations, I have yet to see completely unambiguous causation validated.
  • If the latter issue emerges, many folks seem to head straight for a system reformat or image restore. I really don't believe this is needed as an initial solution. My own recommendation would be to first, uninstall KAV/KIS, use the command line approach to remove file object ID's (FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Delete "%a"), then see if chkdsk can successfully execute. Note - on a large file system, that command may take a number of hours to complete, so patience is required.
  • One will note that a handful of users have simply sworn off further usage of KL products. Personally, I think this is an overreaction, but a somewhat understable one given the handling of this situation.
  • The lack of a steady and increasing stream of new reports of major system problems does imply that the issue is not a systemic problem with KAV/KIS, but more likely tied to a limited number of specific circumstances or conditions realized with very low frequency. This detail seems lost in most discussions. I happen to think that it's rather important.
For some, I'm sure the above is a useless summary opinion of one user, for others it may mitigate some vague concerns that have emerged while reading various threads on the net. If you feel it's worthless, so be it.

 

Cheers,

 

Blue

Share this post


Link to post
Your misunderstanding I live in lightning capital of the world.. So UPS only last about 6-12 months max before we have to buy new ones due to batteries completely run out. I have not been able to afford a new one right now so power outages and brown outs cause corrupted files.. computer crashes also cause corrupted files.  Chkdsk is required to repair bad indexes, crosslinked files, ect that happen from this.  Now if chkdsk can not run than chkdsk can not fix these files.. And the files will continually get worse until the system itself can not run properly at all.  Hence damage to my system because chkdsk can not complete to repair these soft errors.

428289[/snapback]

 

It is good to read this since it confirms the suspicions that you must have had much more serious problems causing your disk problems then KAVs ObjectsIDs. I also have 7 "dead" hard disks in my drawer because of bad electricity and I do think you should agree and accept the fact that KAVs ObjectsIDs are not your real problem.

 

I do understand and even agree on your point about chkdsk taking longer to work... However i actually doubt that chkdsk would be able to help you since it is actually quite a weak tool and in some cases causing even more problems then fixing. And as i understand, you knew your disk was failing for a longer time and did not do any backups of your data sleep.gif

 

However if you still have that disk somewhere around I do believe Spinrite ( http://www.grc.com/sr/spinrite.htm ) would be able to help you recover that disk at least temporary so that you would be able to copy at least most, if not all, of your files to the new disk. It did the magic for me and it does not care about such things as NTFS Streams and ObjectIDs.

 

Short, your disk was doomed from the beginning because of the bad electricity (as ware the seven in my drawer) and nothing was able to help or fix it for you (except an UPS probably). Your disk would died sooner or later even if you had no KAV. Dust, heat, shaking/vibration and bad electricity are the real problems when it comes to real disk damages.

 

I am still not convinced that ObjectIDs can cause any more problems then delaying the second stage of chkdisk and maybe some compatibility issues with other programs that also use ObjectIDs for their needs.

Edited by saso

Share this post


Link to post
However if you still have that disk somewhere around I do believe Spinrite ( http://www.grc.com/sr/spinrite.htm ) would be able to help you recover that disk at least temporary so that you would be able to copy at least most, if not all, of your files to the new disk. It did the magic for me and it does not care about such things as NTFS Streams and ObjectIDs.

428530[/snapback]

+1

Great tool by Steve Gibson.

 

Paul

Share this post


Link to post
+1

Great tool by Steve Gibson.

 

Paul

428546[/snapback]

 

 

Saved many a harddrives under my watchful eye smile.gif

Share this post


Link to post
[*]There are two distinct problem threads:

[*]A general phase 2 chkdsk slowdown that is to be expected and should not be a real concern for anyone and,

[*]A more problematic situation that occurs when chkdsk cannot complete.  In isolation, this does not mean there are irrecoverable issues.  However, if this behavior is seen, I would recommend uninstalling KAV/KIS and examining the system further......

Cheers,

 

Blue

428360[/snapback]

 

I'm just joining this thread now, but Kudos to Blue for posting the summary on the 25th page of this post and sparing me from reading the 480 other posts in this thread!

 

I'm experiencing the phase 2 slowdown and using KIS 7 with a trial key. I run chkdsk regularly and did not have a phase 2 slowdown prior to installing KIS7 (when it exactly popped up, I'm not entirely sure).

 

A few questions:

 

1) can dexter_'s objectID string with the 'query' switch alleviate this issue? Or must you use the 'delete' switch?

 

2) If running with the 'delete' switch on my boot volume...am I going to be stuffed? Or do I stand a good chance of the everything still working for the most part? (I will of course perform a full backup, but if it's just going to bugger my boot volume it would be good to know that I need to budget in the time for a format/restore).

 

Finally, as a side note to the moderators of this forum/thread... [bEGIN RANT]480+ Posts in one thread is utterly insane and totally obscene [END RANT]

Share this post


Link to post
I'm just joining this thread now, but Kudos to Blue for posting the summary on the 25th page of this post and sparing me from reading the 480 other posts in this thread!
Thanks, but others did the heavy lifting

I'm experiencing the phase 2 slowdown and using KIS 7 with a trial key. I run chkdsk regularly and did not have a phase 2 slowdown prior to installing KIS7 (when it exactly popped up, I'm not entirely sure).
Take some time to assess the nature of the slowdown. If it's a few minutes and no errors emerge, it is simply chkdsk dealing with additional information to process, should be expected, and needs to happen. Also, if you plan on keeping KIS7, it really doesn't make sense to try to delete these items. If it's the end of the trial and have decided to look elsewhere for a bit, I'd do the removal a s a matter of system hygiene.

A few questions:

 

1) can dexter_'s objectID string with the 'query' switch alleviate this issue? Or must you use the 'delete' switch?

Query just verifies their presence. Delete is the only action which will do anything.

2) If running with the 'delete' switch on my boot volume...am I going to be stuffed? Or do I stand a good chance of the everything still working for the most part? (I will of course perform a full backup, but if it's just going to bugger my boot volume it would be good to know that I need to budget in the time for a format/restore).
As far as I could observe (I've performed the operation), you should be fine, just plan on budgeting a few hours.

 

Blue

 

Share this post


Link to post

Ok everybody. I guess we have our answer, pathetic as it is, and not even the courtesy to post it in this historic thread. I take a bit of bitter satisfaction in learning that we victims have been right all along and that Microsoft has officially slapped Kaspersky for their recklessness in using Object Identifiers in a way not intended by Microsoft.

 

I have given Kaspersky my feedback regarding their answer to this issue both in official feedback to Kaspersky and copied to the dslreports thread. It looks like poor StraightShoot is doomed to forever have that negative Kaspersky statement as his signature since he said he would keep it until there was a fix for the problem from Kaspersky. Since Kaspersky has apparently given all of us the finger and abandoned us (but at the same time been busily making certain this doesn't occur in the 2008 version) I too am going to extend Jim's signature to everywhere I post and not just in Wilders Security forums.

 

I am on record all over the internet as having stated that I believe KAV 4.5 to be the finest AV ever and I still believe that. I also believe that Kaspersky is a most arrogant and reckless company whose idea of tech support is abandonment and which shows no respect for the injured customer. Where is our removal tool? Where is Kaspersky's OFFICIAL apology? Is that lame, hidden tech support article the best Kaspersky can do? Where is Kaspersky in this thread now? Why the silence from Kaspersky now in the dslr thread?

Share this post


Link to post
Yes and no.  If it's pure whining of "when will it be fixed", I'd say you're right.  If it's a somewhat more balanced/crystallized view of the situation, I'd say no, it is worth stating for concerned current and future customers - unless you'd prefer that they walk to another vendor for lack of information....

If you wade through this and other threads on the topic, lots of key information gets lost in the shuffle.  For example:

There are two distinct problem threads:

A general phase 2 chkdsk slowdown that is to be expected and should not be a real concern for anyone and,

A more problematic situation that occurs when chkdsk cannot complete.  In isolation, this does not mean there are irrecoverable issues.  However, if this behavior is seen, I would recommend uninstalling KAV/KIS and examining the system further.

The number of instances of the second issue appearing are quite limited - perhaps a dozen to a few dozen casually reported instances.  I actually recall less than a dozen that I'd firmly classify as the second issue.

It is unclear whether the second issue is a direct result of iSwift, whether some of the secondary consequences of iSwift exacerbate unrelated problems (i.e. filesystem corruption which remains unfixed due to chkdsk execution issues that evolve into major system problems), or whether iSwift is an innocent party to the reported problems.  While there are suspicious correlations, I have yet to see completely unambiguous causation validated.

If the latter issue emerges, many folks seem to head straight for a system reformat or image restore.  I really don't believe this is needed as an initial solution.  My own recommendation would be to first, uninstall KAV/KIS, use the command line approach to remove file object ID's (FOR /R %a IN (*.*) DO @ECHO. && @ECHO - %a && @FSUTIL ObjectID Delete "%a"), then see if chkdsk can successfully execute.  Note - on a large file system, that command may take a number of hours to complete, so patience is required.

One will note that a handful of users have simply sworn off further usage of KL products.  Personally, I think this is an overreaction, but a somewhat understable one given the handling of this situation.

The lack of a steady and increasing stream of new reports of major system problems does imply that the issue is not a systemic problem with KAV/KIS, but more likely tied to a limited number of specific circumstances or conditions realized with very low frequency.  This detail seems lost in most discussions.  I happen to think that it's rather important.

For some, I'm sure the above is a useless summary opinion of one user, for others it may mitigate some vague concerns that have emerged while reading various threads on the net.  If you feel it's worthless, so be it.

 

Cheers,

 

Blue

428360[/snapback]

 

Thank you for the informative post. It is so refreshing to see clear, unbiased facts without the drama. Maybe the new forum will have an optional drama filter button.

Share this post


Link to post
It looks like poor StraightShoot is doomed to forever have that negative Kaspersky statement as his signature since he said he would keep it until there was a fix for the problem from Kaspersky.

 

Well Mele20 poor old Straitshoot is stating Kapersky a Virus now. Feel free to read his last post. I think he is now oversetepping his own crediabilty, and has lowered my opinion of himself, to nothing but a troll.

 

http://www.dslreports.com/forum/r19036986-...st-me-at-ISwift

 

I don't seem to have the chkdsk issue as bad as everyone else. chkdsk only takes a couple of minutes to run on my system. smile.gif

 

 

 

Share this post


Link to post
Well Mele20 poor old Straitshoot is stating Kapersky a Virus now. Feel free to read his last post. I think he is now oversetepping his own crediabilty, and has lowered my opinion of himself, to nothing but a troll.

 

http://www.dslreports.com/forum/r19036986-...st-me-at-ISwift

 

I don't seem to have the chkdsk issue as bad as everyone else. chkdsk only takes a couple of minutes to run on my system. smile.gif

432150[/snapback]

Welcome. "Everybody else".....About a dozen .......maybe not caused by Kaspersky.... "troll"......generic terminology. More specific would be "Professional Xenophobiac".

 

Share this post


Link to post

That thread at DSLR is so ridiculous, Mele20 & StraightPoot are allowed to post anything they like as far off topic as they like without any moderation..... I have never liked DSLR they are somewhat like a cult, if you question the "chosen few" your posts will be deleted.... utterly ridiculous. After reading some posts by Mele20 & StraightPoot about other topics the level of their computer expertise is quite evident..... VERY low. That's not a low blow, it's a fact, some of the things they ask help for or answers they give are evident of not being very knowledgeable. They have truly out done themselves on this topic, proven their ignorance of technical computer issues and posted it everywhere on the internet.

 

rolleyes.gifrolleyes.gif

Share this post


Link to post

LMAO....

 

It is quite funny how the moderation is over there in the security forum. I think you nailed it Dr Tweak, some aren't allowed to say anything, and then others can say anything.

I know I've had my share of deleted posts. smile.gif

Edited by norwegian

Share this post


Link to post
LMAO....

 

It is quite funny how the moderation is over there in the security forum. I think you nailed it Dr Tweak, some aren't allowed to say anything, and then others can say anything.

I know I've had my share of deleted posts. smile.gif

432180[/snapback]

No doubt, I'm Anon00 on DSL Reports. I've been a pretty long-time member of the site, granted lurking lately (busy) outside of the Social Forums, since I like to read what others say more.

 

But yeah the moderation in that thread was ridiculous, with pretty much anything Anti Kaspersky allowed to fly. Rebuttals against some of the just pure BS gets moderated while original posts stand.

 

I remember when the Security Forum was pretty respectable but now it seems its a dumping ground of Symantec shills, conspiracy theorists, and axe-grinders.

 

Don't get my wrong, I think Kaspersky probably didn't take the right avenue with iSwift, and a removal tool for the excess ObjectIDs once v8 is out wouldn't be a bad idea, they probably should have erred on the side of caution and received MS's OK before doing this (though who knows MS probably would've said it was ok) but it comes along way from corrupting files. The pure FUD being spread is out of control.

 

I also like how Kaspersky's answer isn't acceptable but Microsoft's answer that Chkdsk can't properly check its indexes or that they don't properly lock down their API is. I mean, ffs, if they didn't want ObjectIDs to be created by anything outside of their own services then why allow it at all? That's like Microsoft BLAMING hackers for its security flaws.... wait... they've done that too IIRC smile.gif

 

In either case, I think Kaspersky has shown a flaw in NTFS and I'll hope v8 isn't a huge slowdown.

Edited by jonnyjl

Share this post


Link to post
I also like how Kaspersky's answer isn't acceptable but Microsoft's answer that Chkdsk can't properly check its indexes or that they don't properly lock down their API is. I mean, ffs, if they didn't want ObjectIDs to be created by anything outside of their own services then why allow it at all? That's like Microsoft BLAMING hackers for its security flaws.... wait... they've done that too IIRC

 

In either case, I think Kaspersky has shown a flaw in NTFS

432183[/snapback]

 

Yes, pretty much it, and I doubt Microsoft would be willing to fix it for a user or 2 either in the next update roll-out. Maybe we can be proved wrong from the facts we already know.

 

 

 

Share this post


Link to post
Yes, pretty much it, and I doubt Microsoft would be willing to fix it for a user or 2 either in the next update roll-out.  Maybe we can be proved wrong from the facts we already know.

432185[/snapback]

biggrin.gif

 

Oh and I probably should have said a "Kaspersky has shown a flaw in Chkdsk" rather than in NTFS since it doesn't appear the File System is negatively affected by large Indexes or a large number of ObjectIDs outside of using this utility... Though who knows.

 

Probably time for MS to create a new File System anyways.

Edited by jonnyjl

Share this post


Link to post
Probably time for MS to create a new File System anyways.

 

Funny thing is that they did, WinFS, it was supposed to be introduced in Vista, probably the best feature that Vista was supposed to offer and the developers dropped it because they didn't have time to properly implement/develope it..... they should have waited and finalized it.

 

smile.gif

Share this post


Link to post

I remember when the Security Forum was pretty respectable but now it seems its a dumping ground of Symantec shills, conspiracy theorists, and axe-grinders.

 

Well, to be fair, I got better information over at DSLR than I got here and an actual solution to this iSwift problem was first posted by Dexter over there. Here, I got an insistence that there was no problem or that the problem couldn't be reproduced. This has been an extremely frustrating experience over a very long time. I'm not surprised that tempers flared.

 

But there has been good information posted here too, and some particularly well done summary posts in recent weeks that I think were very helpful. The value of a forum is the quality of its contributors and I think there are excellent contributors both here and there. But I agree there have been over-the-top and irrational posts on both sides and in both forums. Par for the course I'd say.

 

 

 

Share this post


Link to post

 

Was there an update to the engine that helps this. I had a corruption issue on a box where some fixing was needed and the MFT fixed via chkdsk due to a abnormal shutdown? On a dusty old box. :)

 

 

Share this post


Link to post

Hello All,

 

I have been using Kaspersky antivirus ver 6 and 7 on a notebook computer and recently installed the trial version of Internet Security on a new computer. On the new computer, MS scandisk will not run at all. On the older notebook, it bogs down at stage 2. I was unaware that this problem was caused by Kaspersky until recently. The question I have, and this is addressed to Kaspersky tech support as much as the members of this forum, is should I buy my copy of Internet Security with the expectation that Kaspersky will come up with a patch that will return my hard drive to its original condition? The other alternative to use the HP Vista reinstall disk to return the OS to its original condition. (Would this work or do I have to format the disk first?) I don't have much data on the new computer as it's only a week old. I have no other problems besides the scan disk issue. I already tested the hard drive with Spinrite and the Seagate utility and there are no errors. I suppose I am more upset at Kaspersky's attitude than the problem itself. It seems like they are trying to sweep it under the rug. So I ask you, Kaspersky, will you write a patch to return my hard drive to the condition it was when i purchased it? Your program is otherwise superior, but I cannot do business with a corporation that has a corrupt culture.

 

My other question, adressed to the forum members, is which product would you recommend if I had to switch. You can email me privatlly if necessary.

Thanks to all.

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.