EAZ-FIX Users : Disable CHKDSK Recommended

2 days ago, my computer went through a chkdsk on bootup and lots of errors were found and corrected (recovered). After that, my Windows and some programs became corrupted. I then rolled back to my previous few snapshots and found the same corruption. Only my base installation snapshot is working well and not corrupted. I believe the CHKDSK process somehow corrupted my subsequent snapshots through its corrections.

I recommend all EAZ-FIX users to disable CHKDSK to protect their snapshots from being corrupted by doing this :

Start --> Run --> chkntfs /x c: (assuming you want to disable on C drive only)

 

yo nanana1 10x for the tip mate... will use it

 

Exactly. This past week I experienced the very same problem as nanana1 with EF (the version I got free from Giveaway of the Day). I am also a user of Tuneup Utilities and while I was doing my usual 1-Click Tuneup at the end of the day, it informed me that I had some corrupted files and advised running chkdsk.

Running chkdsk did indeed reveal a large number of corrupted files, so I decided to revert to an earlier EF snapshot, which was similarly corrupted. After finding that several EF snapshots were corrupted, I decided to restore my system using my DriveSnaphot. That solved the problem, but as a result of this incident, I have decided to uninstall EF and just rely on DS.

 

I recall that I also had this earlier when i used EF...the files in question were outlook express files and others from the common files folder...they were recovered by chkdsk and in win seen and placed in a recovered folder as chk.001 and so on, or something like that...the only thing to fix this was as mentioned an image restore...

 

Remember when i backed up Eaz-Fix and restored it and certain image softwares failed and immediately ran Chkdsk on bootup and corrupted it worse. There is something wrong to begin with as Peter is saying. It could be Eaz-Fix has messed up already. If it all working good ChkDsk works fine.

 

The way I see it, getting a corrupted file or some bad pointers once in a while isn't that unusual, but I don't understand why running chkdsk messes-up EF (or RB). That's not to imply that chkdsk couldn't have caused the problem, I'm just 'befuddled' as to how that can happen.

I don't see that disabling chkdsk is any solution for this issue. but until the problem is understood and fixed, I would make frequent image-backups (as Aaron suggested).

 

There's more chance of errors using Eaz-Fix, which i believe has happened probably from a malfunction of Eaz-Fix, ChkDsk tries to repair it and ends up making it worse. If you disable ChkDsk, it probably get worse, but the way Eaz-Fix works it's got worse already.

 

I will not disable chkdsk. Not a good idea IMO.
This is basically an old old bug of Eaz-Fix that still persists.

 

You may have a Outlook file that is corrupted that needs to be fixed with chkdsk, but why risk corrupting all your EF snapshots running chkdsk ?

 

Agreed, and until there is a easier and more convenient software that protects all its snapshots than EF, EF and its clones remain the only option we have.

You could add on by doing a full disc image backup, etc.

 

This is an old chestnut...search here..
https://www.wilderssecurity.com/showthread.php?t=184940&highlight=Rollback chkdsk

Really a staggering enduser clusterf%ck..
Check the HDS forums ( I cant even get that forum to display properly atm)

I've tried hard not to comment here as I felt the many threads spoke for themselves and there is a somewhat personal aspect at stake which could be inappropriate bashing :

just me, but HDS .
At a personal level having purchased license for RB V7x ( heh: which gives me some license), and not withstanding some outstanding support, HDS have treated me with disdain and condescension.
I really find it hard to swallow the claims of massive end user acceptance and corporate success at the website, but, who knows.
HAving said that, there are many power users who have had great success with RB and EF.
IIRC, nicM used RB in his hooking tests.
Chris 1293 was a supporter.

Unfortunately the promised functionality is so alluring..
Possibly in stringently limited workstation corporate environments their tools might work well.
Over and out.

 

This is one of the reasons why I ditched EF and went over to FDISR...Another reason was imaging.

 

I thought all problems were solved in RBRx and its clones. Obvious not.

 

Disable CHKDSK can only hide the warning. but in fact, there are many damaged files in your disk.

 

Say Pete.

Remember when you ask me that same question some time ago when i reported that CHKDSK wanted to run so i let it after booting to a different other FD-ISR snapshot?

I haven't seen that issue with my EAZ-FIX yet and might be because i keep it on a non-partitioned single drive.

I still can't answer the WHY to CHKDSK wanting to run but on my XP Pro it occasionally wants to do just that sometimes after switching to different HD's and even my USB Pens.

I simply cancel it within the 10 second limit and move one. Sometimes it repeats again after a simple reboot, sometimes not.

Bug?

 

Thanks again.

That just confirms once more my suspicions about that all along and the delicate matter and differences of what Windows determines should be corrected (via CHKDSK) versus what really isn't any issue at all.

Once burned twice shy.

This probably isn't as much an issue with FD-ISR as it can be with EAZ-FIX/Rollback due to it's different handling measures of the sectoring as you indicated.

EASTER

 

Which is really my point here. If you must use EF or RBrx, because of the nature of its technology with its kernal filter and disk reference points which CHKDSK does not understand will stands more to be corrupted than helped by CHKDSK.

Therefore, if you want to use EF ot its clone, CHKDSK is recommended to be disabled as it will corrupt EF snapshots more than help clean your "dirty" drive

 

OK man, in that case we divide EF/RB-users in 2 camps :
1. Chkdsk-ENABLED-users.
2. Chkdsk-DISABLED-users.
and both report problems, if they occur.
If you are right, you will save all the Chkdsk-ENABLED-users, if you are wrong only you need to be saved, not the other Chkdsk-ENABLED-users.

As it is now, I got nothing to recommend anymore, regarding Multiple Snapshot ISR-softwares.
1. I can't recommend FDISR, because it is terminated.
2. I can't recommend EF/RB, because it isn't reliable.

 

I had been chkdsk-enabled and had seen my snapshots corrupted through bootup chkdsk process, only the base installation snapshot remain clean and working. I must say I did not lose my data as I was able to roll-back to my clean baseline snapshot and still retrieve my data from the corrupted snapshots.

Having been chkdsk-enabled and seeing this, I will now move to the chkdsk-disabled camp as recommended. I still like the EF/RBrx speed and convenience and always confident that the baseline snapshot has always been solid stable despite all the reported issues which had affected the subsequent snapshots. Bottomline, EF/RBrx users always have the baseline snapshot working in the worst scenario

 

is there any backup prog that can backup even all the snapshots? coz EF build in backup image cant... maybe someone did succeed doing that... ?

cheers

 

Let's face it like ErikAlbert continually tries to bring to light, that is the unadulterated TRUTH!

Rollback aka HorizData is bordering on nothing but a complete sham of a company, and they're not fooling everyone, their product STINKS! period.

They simply refuse to spend the time, effort, or resources required to at least make it indefinitely useable without issue, but instead throw out in distribution an ISR that is severely hampered. Maybe not today, but you can bet the farm at some point not too far down the line with some use, it's going to flop.

I have never once during all their (HDS) so-called developmental quarters experienced a single, let me repeat again for clarity, not a single issue of any serious concern with FD-ISR, yet they seen fit once they got their grubby paws on it to rip it to bits so it would behave just like the rest of their lousy distributions they been arrogantly careless with as well as their customers.

Verdict In:

CASE CLOSED:

Read My Lips! NO MORE COMPENSATION FOR SUCH LOUSY WORKMANSHIP.

 

I have run chkdsk on a great number of occasions, and have never experienced RB corruption as a consequence of doing that. I have been using RB v7.21 without any problems for 1 1/2 years. I suspect the problem here may be one of creating a corrupted snapshot. In that regard, it may be of interest to note that I have set RB's System Setting to only take a snapshot when the system is in a consistent state - that just seems to make good sense as the liklihood of a corrupt RB/EF snapshot has to be far greater if the system is in an inconsistent state at the time the snapshot is being created!

That said, I would not be without an image-backup (my final fail-safe protection). In that regard, as of now I prefer Drive Snapshot.