Introducing AX64 Time Machine - hybrid imaging/snapshot software

I am running Win 7 64 bit, my security set up is ESET, AppGuard, and Zemmana AntiLogger. I am using AX64 v 1.3.0.7

As long as I remember to reduce the protection level of AppGuard from high to medium before a restore I have had 0% failure with hot restores,,,,,,, prior to the reduction protocol I would experience approx a 20% failure rate (Isso tracked this one down for me and it took him a fair bit of time to do so,,,,,its where the idea that security software could interfere with hot restores had its origin I believe).

Of course now that I have mentioned it I expect the PC Gods will clobber me the next time I do a restore.

 

I find this fact rather interesting.
Why 20% and not 100% or 0%?
Does this mean the security softwares aren't secure enough (thus the 20% "breach"), or AX64 needs more "tweaks" so that it can "handle" the security softwares more consistently (thus the 20% failure rate)?

Just pondering...

 

At what point in the restore process are people experiencing failures?
eg With hot restores does AX64 fail/freeze when restoring files or at the reboot?

 

not on mine, if i didn't the restore fails (the last time i tried)

 

LD, from my personal feedback and from the reports in the forum, the most common HOT restore failure is a FREEZE during the restore process (not the mouse freeze <normal> but the progress freeze). This freeze seems to occur at random during the process phase.

I have found that if the freeze occurs anywhere except at or near the very end (98-100%), a reBOOT to that image state will not be successful (either at first or eventually) due to a corrupted (mixed old and new) Windows image in place on the disk. Only a COLD RESTORE will insure a proper image state at this point.

When AX64 switches to what we on the forum are calling a WARM RESTORE, it is expected to eliminate this anomaly (at the cost of some additional seconds required for the process to occur) of an active Windows being involved while the restore process takes place. Sure, there will be an "active" Windows involved (WinPE) but not the one on the partition being restored as it is now with the HOT restore... this makes a huge difference.

 

For me, the strangest thing about the missing mouse during cold restores, is the fact that I just booted with a W7 boot CD that can be made with W7's restore program, with Paragons/Linux boot media and a Windows PE CD and the mouse, with a visible cursor (obviously), functioned perfectly!

 

I suspect that it has to do with what else is going on with the PC at the time. The point is that intermittent failures are a fact of life with various security programs (not just mine) and that disabling them seems to resolve the problem.

 

When I had failures it would occur either at the beginning of the hot restore process (0%) or up to the 86% mark. I never had a reboot fail.

 

I've had more Hot restore failures that successes and it always happens as far as I can recall prior to 50%. I don't recall getting past that and it freezing up. Often I can get a couple hot restores on new install, then almost certain freezing after that. I've never had a reboot problem once it gets that far.

I've also had a few freezes, wait and it will actually be continuing while it looks stuck, then it will reboot. I've even had this happen a time or two in what I called warm restores in safe move. Very uncommon though. Ver .24 seems most reliable and fast on warm restores on my Win 7 system.

Its a little bit of a pain to have to restart in safe mode, wait to stop Windows Def once it starts (in services), then restore, but it works and often in about 10 minutes once I do all the preliminaries. In reality those extra steps are not a problem considering a cold restore takes about an hour of not having access to my laptop at all.

 

Actually, my curiosity is on this: was the "hang" intentionally caused by those security softwares (i.e. they're blocking something that AX64 trying to do), or unintentional (it's just so happened)

The 20% figure above was just illustrations.

 

Not sure what you are saying but the 20% hot restore failures number I mentioned was pretty close to what I was experiencing,,,,,,I kept notes during the problem period in order to try to figure out what was causing it ,,,,,,, so my estimate is somewhat more than a gu-estemate.

In short, for every 10 or so hot restores I had 2 failures. A bit of a pain to be sure but still better than having to use Rx or normal imaging apps with their lengthy restore times. I was willing to accept this if absolutely nec (AX64 was still better than the alternatives), but I am very glad it turned out not to be,,,,thanks to Mr Isso.

 

I'm sorry Mr Goodman, to be honest I was just trying to make it clearer, but I guess it wasn't successful

From my very first post on this matter:

"I find this fact rather interesting.
Why 20% and not 100% or 0%?
Does this mean the security softwares aren't secure enough (thus the 20% "breach"), or AX64 needs more "tweaks" so that it can "handle" the security softwares more consistently (thus the 20% failure rate)?

Just pondering..."​

I wasn't actually asking that "why" to you in particular. It's just that your post before it (which I quoted, maybe that's my mistake) made me think how security softwares & AX64 relates.
However, *maybe* because I quoted you, then it made the impression that my post was directed to you, hence so far only you have responded, whereas it's actually an open invitation for all who care to join the discussion.
Of course, it's also possible that no one responded because no one has (yet) anything to contribute, and that's ok with me.

Then, your second sentence in your reply

made me think that *maybe* (again) you got it wrongly that I was referring specifically to the "20" percentage.

I wasn't, because it's your whole post (which of course includes the number above) that made me to comment in the first place. I wasn't debating that percentage, but I was interested to know why & how that happened (and you have kind of answered it with your first sentence).

Hence then for the next post, I posted without any quotes. And my last sentence in that post:

"The 20% figure above was just illustrations."​

supposed to be a clarification for *my own* previous post, not yours, and certainly wasn't intended to question your data (by the way, I really admire your methodical approach).

There's a few maybe's here, and I apologize if all the maybe's were wrong.
On the other hand, if they weren't, then I hope I can get it clear now.

Now, any others would like to contribute for the topic I opened?

Regards

 

By far the number one reason for freezing at any point during a hot restore for most seems to be security software(s). But in my case there seems to be something else as well. (I doubt I'm alone in this since my setup is very normal.) I can manually stop all security software in services and processes, do a hot restore and it will still hang. In safe mode I do have to stop Win Def and with whatever else is off it will work fine. So security software is clearly the first place to look. Exactly why this is the case likely only the developers privilege know this.

 

Now THERE'S an opening if I ever heard one (why aren't you sleeping?)...

To try and dig out an answer to HOT restore failures will not be very fruitful for us outer edge testers.. but I'm sure is known by now by the "team."

Just think of it... the idea of trying to replace active blocks on the disk with new blocks, at the same time an active Windows system is also using that same space just seems loaded with possible anomalies. Windows uses that space during its normal operations... $MT modifications, other metafile changes, pagefile access, all kinds of things going on. It's not just SECURITY apps and other things "watching" us (NSA... are you there?)... it's basically anything that might be going on that just may need access to the disk surface either by itself or by proxy (Windows).

When I first saw how this app worked (HOT restore) I said... "No way! They must have found some super secret way to use a LIVE system to change the reference disk surface!" Well, since then I think they've discovered that the HOLY GRAIL of changing LIVE Windows systems has really not been discovered yet... and, in fact, may not be doable at all, reliably. That's why moving to a PE-based solution (WARM RESTORE) eliminates the LIVE aspect of Windows disk modification completely... eliminating the not yet really discovered HOLY GRAIL approach.

I think we see it's not just SECURITY stuff... some of us have never had HOT RESTORE failures, and some of us have a ton and most of us have tried ti take the SECURITY stuff out of the loop. Sure, the SECURITY stuff may be using proxy functions of the LIVE Windows system causing some to see the problem, but there are many other apps that may be using the same thing, including Windows modules themselves for certain functions.

The above is why I've abandoned any way of trying to determine what the ROOT cause of the HOT restores have been (too many possible sources)... I believe Team Isso basically knows that answer (and they're not talking to their VVPM <Virtul VP of Marketing> ) and will be providing that solution shortly.

Me... I'm just waiting for the great news!!

 

So from what I could find from searching this topic AX64 is not compatible with Shadow Defender however I don't really understand why, I'm guessing it's because Shadow Defender makes something mess up when it's active? In that case what about the below scenario, would it work?

Scenario: Basically using AX64 as backup and then also sometimes using Shadow Defender but never taking a snapshot while Shadow Defender is active and never doing a hot restore when Shadow Defender is active? Would that work? =S Or does it perhaps mess with the tracker file completely even if you don't take snapshots/restore snapshots?

Sorry if this has already been answered, from my searching I just found that it's not compatible but not why and in what situations.

 

Understood, thanks for clearing that up.

 

my twopennorth for what it's worth.
What could be the problem. Defraggers that run in the background? Some sort of automatic running monitoring program during the hot restore. I remember having problems with System Safety Monitor with Shadow Defender a long time ago. Sounds (to me) like two or more kernel level apps locking horns and fighting over ownership of a file and stopping the AX64 process in it's tracks.
I remember a long time ago trying to run two anti virus together and locking up my system. Whatever is stopping the AX64 hot restore process has is not an app that can be easily overridden.

also maybe look for file locking software as a culprit.

 

SanyaIV, don't quote me on this but here's my take...

If AX64 remains inactive during a SD session, AND you don't try and save (exclude?) any files from that session (just a straight Lite Virtualization of the moment), then reBOOT to exactly the state prior to the SD session, AX64 should run just fine.

If you save any SD session files, AX64 will not know about that when you return from the LV session 'cause its tracking file is now what it was before the session and doesn't include the saved session files. If you try and exclude AX64's tracking file (I tried this a long time ago) other problems occur becuse the excluded tracking file contains the LV session's changes but the system doesn't after the revert occurs.

I would try it as I described above... but be careful until you know its happy once again

 

What this error means?
http://s8.postimg.org/3ymiooz05/Snap_Crab_No_Name_2014_3_21_20_21_13_No_00.png

 

To my knowledge there's no readily available list of possible errors from this app.
I would pass that info along using the CONTACT SUPPORT link located on this page.

 

Very well said. I'm just waiting for warm restore (and hoping it plays nice with my SSD, unlike the current cold restore).

 

Taotoo, do you have a post # that describes your SSD-related COLD RESTORE problem?

If not, can you briefly describe here for me? Thanks!

 

I was, grampa
And thanks for the abandonment
Yes, I think they know the what & why, and that's why they changed course.

Cool

So far, for my systems, I never cared to turned anything off. I have CFW, MSSE, NIS (not all of them in 1 system, mind you ), and of course, I don't have a 100% hot-restore successful rate. I don't have the exact figure either (unlike some you), but I feel that the successul/failure ratio is still acceptable.
There's really ghost in the machine

Good thoughts!
I believe Defraggers et al. were seldom mentioned here.

 

Thanks, I'll probably make a backup and then try it out. Actually what if you commit everything (everything done during the virtualization session gets saved, files and tracker etc) Would that cause any issues? I can see the issue if only certain files get saved but I wonder about all files saved? I might try that, I may be playing with fire here but the flame is just so beautiful, hopefully I won't accidentally set fire to my house.

 

I don't think so, just your data maybe