IMPORTANT NOTE - RE Reflect v7.1.2646 Update Regardless of whether or not Reflect v7.1's "CBT" and/or "MIG" and/or "viBoot" options were selected for initial installation, if the above-noted release update is executed as a patch, related drivers and support files will be installed as follows: C:\Windows\System32\Drivers\MRCBT.sys (Macrium Reflect Change Block Tracker) C:\Windows\System32\Drivers\MRVDP.sys (Macrium Virtual Disk Provider) C:\Windows\System32\MRCBTES.dll (Macrium Reflect Change Block Tracker) C:\ProgramFiles\Macrium\Reflect\MIGService.exe (Macrium Image Guardian Service) C:\ProgramFiles\Macrium\Reflect\mrcbt.sys (identical to \Drivers\MRCBT.sys) C:\ProgramFiles\Macrium\Reflect\MRCBTCA.dll (CBT Custom Action DLL) C:\ProgramFiles\Macrium\Reflect\viBoot.exe (Macrium Virtual Image Boot) C:\ProgramFiles\Macrium\Reflect\viBootCA.dll (viBoot Custom Action DLL) Depending on whether all of the foregoing were registered by the Windows trusted installer as having been included in the initial Macrium Reflect installation, any subsequent attempt made via the Windows Control Panel "Programs & Features" to change or remove those components may fail to complete as intended. Manual removal is NOT recommended. Kinda makes a mockery of those user selectable installation options. SECONDARY NOTE - RE Reflect v7.1.2646 WinPE Update If the above-noted update release is executed as a patch, the C:\ProgramFiles\Macrium\Reflect\WAIKFilesXXxXX.exe package file is not actually updated, notifications by the Reflect rescue media "wizard" indicating availability of newer WinPE rebuild package files notwithstanding. If the update is installed using the full Reflect setup executable, the WAIKFilesXXxXX.exe package is actually updated as expected.
I have not tried the new patch yet, but should we use the full installer instead? UPDATE, I did do the complete Installer and I still have the Power Off issue. I will see if it goes away after a few days like in the previous 2638 update. That is why I did the full install..anyway, safe to remove hardware IS OK now.
I hope not, but I do detect a disturbing trend in that direction. It might be less worrisome except for the apparent tendency to get themselves out of their depth in some areas of knowledge and managerial competence. Their unquestionable expertise in handling primary backup and recovery functions is not matched in their handling of peripheral areas, or even some quite basic functions of the Windows OS itself. Those deficiencies, and in some cases downright sloppiness, seem to show up in their installation and patching process in particular. I've mentioned here previously their earlier dangerous handling of the kernel mode driver installation/uninstallation and their patch misplacements of certain DLL files in relation to the relevant Windows registry entries. Even their most basic installation method appears to reflect a complete misunderstanding of the Windows trusted installer operations such that they end up with not one but two differently named but identical .MSI sources registered for each installation. (Under HKCU\Software\Macrium\reflect and HKLM\Microsoft\Windows\CurrentVersion\Installer\UserData and HKLM\SOFTWARE\Classes\Installer\Products.) That leads to situations like this one, but all such signs of bad process management are dismissed as inconsequential by the gatekeeper, of course. In this case, the patching process takes no account whatever of user selectable installation options as recorded in the Windows registry and the results are as I've noted them above. The ultimate consequences will become apparent to users only if and when they attempt to uninstall components or modify their installation choices in any way. So they'll also be dismissed until it all adds up to a major and irrefutable problem. Like Acronis in that respect at least.
Mr. Sills has declined any answers (even to his favourite one-man-band questioner) about what he calls the "secret sauce" of MIG functionality. So far as I can determine, however, its protection is specific to Macrium backup (*.mrimg and *.mrbak) files exclusively and achieves that by means of a kernel mode device class filter. If so, it's not unlike the CBT device class filter except in its narrower range of applicability. In any case, it would not extend any protection to the MBR itself. The forthcoming Windows 10 "Fall Creators Update" will provide much broader user-selectable anti-ransomware protection, but how well they'll interact with each other remains to be seen.
Yesterday exactly the same thought crossed my mind. There are far fewer bugs with MR, and different from Acronis, MR is fixing what they know about - but the feeling is similar. The striking difference between v6 and v7 suggests to me that the developers or the people making the decisions are different. After waiting all this time, I finally updated to v7 (choosing to not install anything that was optional) a few days ago, immediately before the new bug reports started rolling in. I quickly went back to v6. May I suggest to Macrium that they engage someone like Arvy to help them where their expertise might be shallow, and to provide a second opinion in other areas. Tiny differences in input can quickly become overwhelming differences in output (from Chaos theory). The number of these problems and the amount of time to get to a "rock solid" product is hurting a brand that has been invaluable to me and so many others.
It's never a good sign when any regime begins to prefer flattery, sycophancy and gatekeeping over loyal criticism. It destroys kings and corporations alike.
Tried imaging (instead of cloning) and allowed skipping bad sectors (but log any encountered) on the drive that has been problematic for a couple of weeks. This backup succeeded without a single error (but took more than 7 hours for 1,25 TB over e-SATA). Rather confused now, but curious what an incremental/differential backup will do next week.
Ironic. With V6 they leaked a pre release and we were able to put it thru the wringer. They ironed out a lot of bugs before release. The same offer was made to them before release, but they declined the offer saying they had already done the testing needed. Also once I decided to add Acronis 2018, I found they had fixed a couple of major issues and it's now a real contender. Also I just put their active Protection and does indeed protect the whole system from Ransomware. Even protects the MBR. So I wouldn't laugh off Acronis just yet.
Pete, thanks for cleaning up the false impression I left about the current state of Acronis. I should have made clear that my bad experience was from many years ago.
It's possible that you may have been lucky if Reflect's "intelligent backup" process encountered no data located in any of the drive's bad sectors. Nevertheless, I'd still recommend replacement of any drive that appears to be failing in that way. It's certainly not going to improve with age. Have you tried restoring that completed backup image to another drive and, if so, did it boot successfully with all data intact? At the very least, you should try mounting and checking all of the backup image partitions and/or try a virtual boot.
Definitely not. As I mentioned in one of my earlier replies, I'm hanging onto a copy of their most recent release for more reasons than just "old time's sake." I think Acronis has now learned some hard lessons and, regrettably, it's beginning to look as if Macrium may also have to learn some of those same lessons the hard way.
What is the recommended procedure of uninstalling v7.x and reinstalling v6.x? Is it that simple? Edit: Or should I use REVO Uninstaller Pro for a cleaner uninstall? Note, I am using the free version so licensing issues won't affect me. Thanks.
No, I did not put it on another drive (no 2 TB spare drive available; if I did I would have replaced the drive). Only performed a verify (which took several hours) and that went OK. The PC holding that drive is rather old (2008\). The owner is not sure yet whether to just replace the drive or buy an entire new PC.
Follow the advice given below by Arvy. For your future reference, you might consider my suggestion to take an image immediately before installing any software, which is what I used with v6 recovery media (CD) to change a paid version on a tower and a free version on a laptop from v7 back to v6.
Oh. Okay. Since your problem originally involved a failed cloning attempt, I just assumed that that destination drive would be available for restoring the backup image. Verification only tests self-consistent integrity (no corruption) of the backup image against its own checksums.
Other than restoring a pre-v7 backup (the very best way to do it) I can't, in good conscience, recommend any uninstall method other than that provided by Windows own "Programs & Features" removal options. The critical and potentially dangerous factor involves removal of those kernel mode drivers. Whatever else you may do, you do NOT /repeat/ NOT want to remove nor let anything else remove the driver files themselves without first ensuring that ALL device class filter loading references and service start=0x00000000 references have been completely removed from the Windows registry. Run the full setup executable if you need to reinstall v6, but it has no user selectable installation options like v7.1.
I uninstalled from Windows uninstaller and these two drivers are still present, so I guess even if I was to reinstall v7 these wouldn't be removed? I wonder why they were installed with the free version? Those options ("CBT" and/or "MIG") are not available in the free version anyway.
Not having installed the Reflect Free edition myself, I can't speak with absolute certainty. However, if you updated your installation using the patch method (i.e., using the "Check for updates" option), then I would guess that's probably what put them there. If so, it apparently not only fails to check the user's installation option choices, but also doesn't even check whether it's updating the free edition. Hard to believe they'd be as careless about it as that, but I can think of no other explanation. If "CBT" and "MIG" options were not available for selection in your original v7.1 installation, re-installing and re-uninstalling that Reflect edition will do nothing more to get rid of them that it did the first time. In the circumstances, the drivers and the related device class filter services are not likely registered for loading by the Windows registry anyhow. It's up to you, but I'd recommend just leaving those driver files in place. They do absolutely no harm (nothing at all for that matter) if they're not being loaded by Windows, and it's safer to just leave them "abandoned" there than to take any chance on deleting them.
Pete I presume you tested Active Protection in a VM? I presume on your real system you would still use your other security softs, and not rely on this?
