Shadow defender or returnil ?

Dear CM,

Let us talk about each virtualization program in combination with Rollback Rx installed.

WTF: By this I believe you mean, "Wondershare Time Machine". If you install this with Rollback Rx installed, it will give you a warning that it cannot co-exist with Shield.sys. If you do a Google, you will find that Shield.sys belongs to Rollback Rx which is put by Rollback Rx in the UpperFilters. There is a conflict with WTF and Rollback Rx in the UpperFilters.

Deep Freeze: If you install this with Rollback Rx installed, you will have a blue screen. Again, there is a conflict with Deep Freeze and Rollback Rx in the UpperFilters.

SD (Shadow Defender): I have read in your other post that SD has to be installed after Rollback Rx is installed. I found this to be incorrect, and I didn't want to point out this to you earlier. I have used SD in combination with Rollback Rx. I have found out it doesn't matter which one is installed first. SD always puts its entry in the UpperFilters at the very bottom, where as Rollback Rx puts Shield.sys at the very top of the UpperFilters. Thus, there seem to be no apparent conflict in the UpperFilters.

Best regards,

 

WTF is Wondershare Time Freeze. I tried it but not anymore, SD is much better IMO.

When I first tried RX about 2 years ago it warned me that SD was installed and it wouldn't install. This is a fact, it has happened to me. RX has been updated since then, so maybe this is not the case anymore. In any case, I have always installed SD after RX since then, just in case. BTW thank you about the UpperFilters explanation, I wasn't aware of that.

I never mentioned Deep Freeze at all. I tried it on its own a year ago, and didn't like it.

RX, Sandboxie and SD work perfectly together, at least for me. This is the example I mentioned, and I never said that ALL LV apps work with ALL snapshot apps. I have actually mentioned before that this is the case when compatibility is not a problem, and in the case of these three it is not, at least on my systems.

RX allows me to test software that require reboots, and gives me different software setups to suit different needs. Such setups are easily switchable with a simple reboot, a GREAT convenience. It also undoes file system errors caused by crashes, thus allowing me to test overclocks safe in the knowledge that I don't have to run chkdsk after every BSOD. I used to have to restore my backup once every few months in order to clean up and get that fresh clean Windows feeling again. Not anymore, thanks to CTM (when I still used hard disks as system drives) and RX (since I switched to SSDs). Now I can get that clean fresh bodyform feeling with every reboot!

SD gives me a safety net against rootkits, and allows me to test software that don't require reboots.

Sandboxie allows me to safely test suspect executables, and by browsing the sandbox folder I can see at a glance what an executable would do to my system if it was to run out of the sandbox.

For some reason you seem to disregard all these combined benefits. In any case, lets end this here once and for all. I don't want us to post each other to death, or even worse, lose our good rapport and civility.

 

Two years is like ages when it comes to computers. In 1984, when I first bought my IBM PC, it didn't came with hard disk. Later on IBM XT came with only 10MB hard disk.

Are you saying above?
1. That in these two years, you have never uninstalled Rollback Rx and reinstalled.
2. Or, every time you have uninstalled Rollback Rx, you uninstalled SD too! Then you installed Rollback Rx and SD in this order.

Which one?

You are welcome! We all learn everyday, the day we quit learning we are six feet under!

I learned it from Froggie (The Rollback Frog) in regards to Rollback Rx.

Keeping Sandboxie aside, I think using Rollback Rx in combination with SD is overkill. Pegr has agreed with me in a different thread. This is my opinion and I am entitled to my opinion. For this reason I don't use Rollback Rx and only use Deep Freeze. As I have mentioned earlier that SD for me doesn't work with SSDs.

You seems to think that Rollback Rx is great in combination with SD. This is your opinion and you are entitled to your opinion. And, for this reason you are using it in your system.

We are both entitled to give our opinions when someone ask in an open forum. I gave my opinion is post number 3 on the very first page of this thread. You seems to take exception to my opionion rather than giving your own opionion.

Best regards,

 

BTW, I have seen you giving advise to others about turning off TRIM so to use SD with SSDs. And, that it doesn't matter. You mentioned that that RAID array turns off the TRIM.

I kept quiet. I don't think that the above is true. If you remember, we have discussed this earlier that Rollback Rx puts the SSDs in software RAID array for the TRIM to work properly. If you remember, you asked me to prove it and I had posted screen shot for you.

We also discussed that maybe the reason SD works in your system with SSD, it could be that your system is under RAID array with Rollback Rx with TRIM working properly. If you remember, you posted screen shot showing that TRIM is working on your SSD with both SD and Rollback Rx installed.

Best regards,

 

Since I had that RX message refusing to install after SD, I always made sure to install RX first, then SD. I don't uninstall stuff, when I want to install the latest RX version I just restore a clean Win7 backup, then install all the latest versions of everything with RX added before SD.

Of course you are entitled to your opinion. One person's overkill is another's optimal configuration. Please understand that it was not my intention to misjudge your software choices.

I suspect that RX somehow selectively filters TRIM calls for sectors that contain snapshot data. I also suspect that with TRIM disabled a user wouldn't have a problem running SD on an SSD, for as long as SD sits well with the rest of his hardware/software configuration. Still one can never know, in the past I have installed SD on systems with hard disks and had blue screens immediately on the next reboot. That was with just Win7 or Vista installed and no additional drivers or software added apart from what Windows had found and installed itself during setup. I assume that some hardware combinations just couldn't take SD. I suppose Triple Helix will tell us if it does work for him when he actually tries it. If you think it's wrong I still value your input KOR, and I respect your opinion even if I don't agree with it. And yes, we seem to be posting ourselves to death at this point, so please, lets not dwell on this no more.

 

Hi aladdin,

I think this really is the essential issue. The question is whether or not Rollback Rx snapshots represent a virtualized system state. I have searched the HDS website for information on how Rx actually works, and what I've found so far leads me to think that, unlike VMware or a light virtualization program like Shadow Defender or Returnil, Rx isn't a virtualization program. I may of course be wrong but let me explain my reasoning.

To see the difference between a system virtualization program and a rollback program, consider what happens after a vdisk made by a virtualization program such as VMware is restored as opposed to what happens when a vdisk made by a rollback program such as Rx is restored.

With a virtualization program, the vdisk represents the state of the virtual environment at the time the snapshot was made. After restoring the virtual environment to the state it was in when the vdisk was made, the virtualization program continues to virtualize all system changes within a virtual container. On leaving the virtual environment, all changes that took place within the virtual container are discarded. No matter how many vdisks are loaded, the real system is never impacted.

This can be further evidenced by what happens if a system crash occurs within a virtualized environment. A system crash within a virtualized environment will never impact the ability of the real system to reboot. With full virtualization such as VMware it may be possible to have several virtual machines all running side by side at the same time. Changes in each virtual environment will be contained within its own VM, isolated from all the other VMs and from the real system.

With a rollback program, the vdisk represents the state of the real file system as seen by Windows at the time the snapshot was made. After restoring the file system to the state it was in when the vdisk was made, all system changes from that point on continue to take place within the real file system.

If a system crash occurs that leaves the system unbootable when a rollback program is in use, what happens next will depend on what option the user chooses when rebooting. The user will be presented with the option to restore a vdisk in order to revert the file system to a previous state. Unless the user chooses to do this, the system will remain unbootable as the real file system has been impacted. Information about how Rx works supplied by HDS makes it clear that this is true for Rx.

Likewise, when a rollback program is uninstalled, the user will be presented with the option to restore a vdisk in order to revert the file system to a previous state when uninstalling. Unless this option is chosen, the file system will remain in its current state. Information about how Rx works supplied by HDS makes it clear that this is also true for Rx.

The point is that rollback programs do not virtualize the system. The vdisks represent snapshots of the real file system as seen by Windows at a point in time. It is the real file system that is reverted when a vdisk is restored. This is, in principle, no different functionally to what imaging programs do. The difference between imaging and rollback programs lies in the technical implementation. There is enough information in the Rx documentation to suggest that Rx works in the way I have described.

The ability of a program to make and restore snapshots does not automatically imply system virtualization. It's what the snapshot represents and the function it performs that determines this. If a virtualization program has the ability to make and restore snapshots of its virtual environment, then the snapshot is a consequence of the virtualization, not a determining factor. Rollback and imaging programs both make snapshots but the vdisks are snapshots of the real file system as seen by Windows at a point in time. This is what gets reverted on a restore and no system virtualization is involved.

Further evidence that Rx is not a virtualization program can be found on the section of the HDS website where a comparison is made between Rx and Norton (formerly Roxio) GoBack. Virtualization programs have to monitor all system changes in order to contain and virtualize them. It is clear from the Rx documentation that Rx does not do this. Rx snapshots are only made when the user wants one. Rx does not continuously track file system changes in the way that GoBack does. For a rollback program like Rx this is a very good thing in terms of a reduced performance overhead and lower disk storage requirement but it isn't virtualization.

We may end up agreeing to disagree over this but for me it has been a pleasure discussing this with you and I hope you feel the same.

Kind regards

 

Are the changes in Win7 inside the VMware discarded or retained?

Same as VMware snapshots are made when the user wants!

As far as Rollback Rx is concerned, it is hush, hush with HDS!

Best regards,

 

Not really; it's clearly documented on the HDS website and works as I've described above.

Kind regards

 

Thank you for the detailed and very informative post pegr. I don't completely disagree with Aladdin and as I said I value his opinion and have learned new things from both his and your posts. I just feel that most users consider snapshot apps like RX (EAZ-fix) and CTM as different to LV applications because of their approach, as I quoted from your last post. LV apps as you said constantly monitor the real system for all changes and contain those changes in a buffer. Snapshot apps on the other hand do no such monitoring, they only intercept and redirect Windows writes to sectors that contain snapshot data (and possibly they also selectively intercept and redirect TRIM calls addressed to such sectors; this is just speculation on my part, HDS are silent on this matter).

Another thing I have always found strange is how the internal garbage collection of SSDs does not interfere with the snapshots. GC is initiated by the drive's internal controller and we know that GC moves data around in order to optimize things, so how on earth can RX deal with its snapshot data moved around from sector to sector? I wish HDS would let us know, I have repeatedly e-mailed them with such questions and all I ever got was "we will consult with the tech team and let you know". I have also spoken with Comodo's Razvan, the team leader that is currently in charge of developing the new CTM v3.0. He told me back in January that they were trying to deal with this GC problem, so hopefully he'll be able to give us some real answers soon.

 

Hi CyberMan969,

I too value aladdin's opinion. He is an experienced user of Rx and he writes some very helpful and knowledgeable posts. The only issue that we have been debating - in a friendly way - is whether or not Rollback Rx should be classified as a virtualization program. As you say, with a light virtualization program disk changes are intercepted and redirected to a buffer. The virtualization lies in the redirection. GoBack intercepts file system changes but it isn't virtualization because there is no redirection; the changes are made to the real file system and copied to a buffer as a backup. Rx intercepts file system changes but it isn't virtualization because there is no redirection; the changes are made to the real file system and the pointers within the snapshot multi-dimensional tree table are updated, maintaining disk sectors pointed to by snapshots in their original locations without using a buffer for backup.

The explanation of SSD garbage collection given in the following link seems to imply that neither Windows, nor Rx would need to know what was happening at the physical level within the disk. As Rx intercepts Windows logical disk I/O, it is likely that Rx also works at the logical disk level. If the explanation is correct, the responsibility for mapping logical disk I/O to physical storage is the responsibility of the SSD drive controller, which would have no knowledge of deleted logical disk sectors until Windows tries to reuse them. Any logical disk sectors holding snapshot data would be locked by Rx, which would prevent Windows from trying to reuse them, in which case Rx snapshot data would never be deleted by SSD garbage collection. Of course, the reality may be more complex than this. As you say, unless HDS release some technical details of what, if anything, they had to do to make Rx compatible with SSDs, it is all a matter of speculation.

http://thessdreview.com/latest-buzz/garbage-collection-and-trim-in-ssds-explained-an-ssd-primer/

Kind regards

 

Dear Pegr,

I like debating in a friendly way and questioning, questioning, questioning ..... Without it, we will never learn anything new and I have learned a lot from your excellent posts, so keep them coming.

Intel has come out with a driver called, "iaStor.sys" in their Intel Rapid Storage Technology (RSTL) which works with RAID array. I know that CyberMan thinks that this driver is slower in comparision with "ACHI.sys". I don't believe this, neither the 80% users of SSD.

You are right that HDS doesn't give very much information on Rollback Rx. The amount they give is to incite the users of other programs to start using Rollback Rx, thus comparison to other programs. This information given by HDS on Rollback Rx is useless.

Basically, Rollback Rx puts the SSD under software RAID array for the TRIM to work properly. The reason I found out, is that when I had Rollback Rx installed on my three computers with SSDs, one of which was Intel SSD, the Intel Toolbox told me. This I posted on Rollback Rx forum, and no one believed me, so I had to post some screen shots. Based on this, Froggie (The Rollback Frog - on this forum) did some more work and posted his results on Rollback Rx forum.

Best regards,

 

Likewise my friend. We are all learning from each other.

Kind regards

 

I believe the same guys!

 

You are probably right about the majority of users, but on my system the RSTE drivers have been very inconsistent between differen versions.

I recently updated my SSD to the latest firmware, secure-erased it, and then restored my sector-by-sector backup which contains a clean Rollback RX snapshot with only Windows freshly installed plus latest drivers for my mobo (apart from nVidia). No other programs were installed, perfect conditions for benching. This snapshot has no RSTe, just the Intel Chipset Software Installation Utility v9.2.3.1020 is installed to it. I benched my SSD, using the latest versions of AS SSD and Anvil, plus CrystalDiskMark, both in random and zero-fill (results in the 1st attached picture).

I then restored the clean snapshot, installed RSTE v3.0.0.2003 which had already downloaded from my mobo's download page at the Asus website (this version is still the one recommended by Asus for my mobo). I rebooted as needed then benched again, (second picture). Results were slightly better than when using ahci.

Lastly, I restored the clean snapshot again and tried RSTE v3.1.0.1085. I benched it and this time writes sucked big time when compared with the previous benches, as you can see on the third picture.

Moral of the story based on my results: The RSTE driver is still hit 'n miss and it all depends on the version used. RSTE v3.0.0.2003 seems to be the best for my system at the moment. Of course this is just my results, I cannot say it will be the same for anyone else.

 

Dearest CM,

You have always been in our club!

Best regards,

Mohamed

 

So the iaStor.sys used for your mobo gave you better results than ACHI.

I personally have two ASUS laptops, one Lenovo Desktop and one Generic Desktop. The Lenovo iaStor.sys driver I am using on these four computers is dated newer than the Intel RSTL on their site. It is dated 29-11-2011

What is the date for your ASUS RSTE v3.0.0.2003?

Best regards,

 

The iaStorA.sys and iaStorF.sys files belonging to the Asus RSTE v3.0.0.2003 setup, both have a "modified" (timestamp) date of 12 Oct 2011 (same date for both for x32 and x64 versions). The later RSTE v3.1.0.1085 really crippled my writes as you can see on the third photo, I'm now waiting for a new version to come out so I can bench again.

 

Dear CM,

Thanks for the information. Appreciate it!

P.S. It is first time, I am hearing that they are two different drivers, iaStorA.sys and iaStorF.sys. What is the reason for two different dirvers? And, what does A and F stands for?

Best regards,

 

There is also another sys file, iaStorS1.sys in there. I don't know the reason for having all those sys files. The Asus file I downloaded is not an exe installer, it's just a zip file containing the setup files/folders. These are more than one folders in there containing driver files. The paths containing .sys files:

I:\#\RSTe_V3002003_XPWin7\Driver\Disk\32bit
I:\#\RSTe_V3002003_XPWin7\Driver\Disk\64bit
I:\#\RSTe_V3002003_XPWin7\Install\Drivers\SCU\x32 (this folder contains the iaStorS1.sys file as well)
I:\#\RSTe_V3002003_XPWin7\Install\Drivers\SCU\x64 (this also contains the iaStorS1.sys file as well)
I:\#\RSTe_V3002003_XPWin7\Install\Drivers\AHCI\x32
I:\#\RSTe_V3002003_XPWin7\Install\Drivers\AHCI\x64
I:\#\RSTe_V3002003_XPWin7\Install\RST\Drivers\x32 (there is no x64 folder in there)
I:\#\RSTe_V3002003_XPWin7\Install\RST\x64 (this folder only contains DIFxAPI.dll and Drv64.exe, no .inf .sys or .cat files in there).

Actually, the iaStorS.sys is the only one that also has .inf and .cat files with the same filename.

 

Do you have the above installed.

If yes, can you look into under, "Device Manager > ATI/ATAPI controllers" and see the followings:

1. Type of Drivers
2. Date of Drivers
3. Version of Drivers

Best regards,

 

No, but I will restore a clean snapshot later, install it and check it out.

 

OK, thanks!

 

for me i use shadow defender and rx..
they work smooth together and it got simple ui..
cool software, love it..


best regards,
cJ

 

Dear pegr,

Panagiotis is a very expreined ex-user of Rollback Rx and an expert on ISR on this forum. You must know him. He calls Rollback Rx in the following thread in his post #6 as such:

https://www.wilderssecurity.com/showthread.php?t=327355

He further describes in his post #8 as follows:

Best regards,

 

The author of the thread asked about SD or Returnil, which to choose?

I am an avid fan of SD and I've used it a lot. But since it's no longer being actively developed I'd go for Returnil. There's no guarantee SD protects against modern malware as it's been well over a year since the software was updated.