2020 crashes immediately when accessing encrypted virtual container drives (either VHD/bitlocker or Bestcrypt)

ATI 2020  crashes immediately under a new Window 10 Professional  installation when accessing an encrypted virtual container. This applies to both a VHD container encrypted by bitlocker or a container created  by Jettico's Bestcrypt software.

Can you clarify exactly how ATI 2020 is being used here?

Are you backing up files / folders that are stored within the VHD container?

Is this a new backup task or one brought forward from an earlier time?

Does ATI 2020 work correctly for all other key purposes?

Thank you for the prompt response. I've answered your questions in what follows.

1 ATI 2020 is being used for a range of data, with widely differing volatility and sensitivity. Some data are "write once" (archives rather than backups) and other elements are changing constantly (e.g PST files in outlook, about 2Gb, but I have 20GB in the archive). About 20+ scripts deal with different backup tasks (image copies, full copies with multiple generations and differential copies).

Apart from the archives, the two main classes are financial data / e-mail and media (I'm into music production - one application alone take 105Gb)

I have 3 x 2TB drives (one for in-box copies), an EVO SSD which acts as a cache, a 4Tb extenal USB and a 4Tb NAS drive.

2 Some data is a risk if the machine were stolen or went in for repair, as it contains all my financial and other details. I have always held this in encrypted containers (as opposed to on encrypted volumes) which hitherto for years has been provided by PGPdisc. ATI worked fine with that under both XP and Win7 (from  which I am just moving). I started to used the Jettico product on my wife's Win 10 Home machine, and that works fine with ATI 2020 (this is weird ?) 

So yes, these data are just files within the container, mounted as a drive, and ATI should just see it as any other disc as it does under Win 7. It's not an image copy. BTW, EaseUS To Do Workstation works fine.

3 All the scripts have been written on this new Win 10 machine from nothing.

.4 Elsewhere, ATI works perfectly (and quickly) as it has done over the years, and saved my bacon numerous times. I transferred about 1.7Tb from the other machine to this one via a USB drive and backed it all up into its new homes with no problem whatsoever, so the only issue is with the container. {Jettico say they are baffled, but the fact that it exhibits the same behaviour with the VHD seems to let them off the hook.}

Note that ATI crashes when entering the script - it never gets to running. I have managed to get a script loaded to run, and then it just sits there for ever, with no movement. I understand that it references the source disc when the script gets set up, and that I believe is where it tanks.

Many thanks, Yorke Man.

Thank you for the further information / answers.

I am sorry to keep returning with more questions but some of your statements are not how we normally see users describing how they use ATI?

All the scripts have been written on this new Win 10 machine from nothing.

What exactly do you mean by the above sentence?

The normal process for creating a backup using ATI 2020 (and most recent versions) is to launch the main ATI GUI, then click on the "+ Add backup" option shown towards the lower left corner of the GUI, followed by giving a name to the new task, then selecting the Source data and Destination location, before finally clicking on the Options button to configure the detail of any Schedule, Backup scheme, Notifications, Exclusions and any Advanced options.

As such, users doing the above are mostly unaware of any scripts being created via the GUI and thus do not refer to these. 

Are you / have you followed a similar process when you say that your scripts were written on that new system?

In terms of your encrypted containers, then provided these are unlocked and available to view & navigate via Explorer before a new task is created, then ATI should be able to capture source data from the same, or even use a container for the destination location.

Steve

Yes, all the backup commands were created in the normal way on the new machine in the manner that you describe.  They are all completely vanilla. [I used the term "scripts" because I have routine to copy the scripts folder from ProgramData\Acronis\TrueImageHome, which then scans the XML TIS files and extracts relevant data with REGEX, and produces a nice neat report in word for me to file and refer to - sorry for confusing things!]

The live Jettico container is unlocked and in use continually, and functions normally with multiple applications (though none are running when ATI does the backup, to avoid locks)

Although as you say, ATI should see it as just another local disc with a file backup, the simple fact of the matter is that it crashes in a repeatable way with the same error. It's also interesting that it fails in the backup 'add' phase, they never get as far as being actually run.

However, importantly it fails in the same way when controlled tests are run on dummy data, not only on a Jettico container, but on VHD’s. I’ve since run further tests, and ATI crashes when trying to add a new backup of files in an unencrypted VHD, i.e. no bitlocker to confuse things.

From this we can conclude that (a) it’s nothing to do with Jettico code and (b) whether it’s encrypted or not seems to have no effect.

These are simple but controlled tests which show that although ATI should have no problems in these scenarios, it fails and just doesn’t work.

It seems to me that we are left with 3 things, namely (a) a bug in ATI (b) some issue with the new machine or (c) a combination of both.

I’m afraid I’m at a loss and would welcome any further thoughts.

Thanks, Yorke Man

PS: a similar error was reported at

 https://forum.acronis.com/forum/acronis-cyber-backup-125/backup-fails

Ok, thanks again for confirming the information here.

Have you tried the suggestion from the Cyber Backup topic about checking for an updated version of the Visual C runtime?

Next, see KB 60915: Acronis True Image: repairing program settings - and try the options suggested there.

If the above makes no difference, then you will need to open a Support Case direct with Acronis to conduct a more indepth investigation and collect the diagnostic information advised in the other topic:

In order to speed up the resolution process, I advise that you reproduce this issue and collect ProcDumps and Acronis System Information from the Agent where backup fails.

I would recommend passing on a reference to this forum topic to show all the steps that you have already taken in trying to prove where the issue lies.

The strange thing here is that your other Windows 10 Home system doesn't show the same issue and nor does other applications accessing the same container data.

One final thought.  Can you unlock the encrypted containers when not booted into Windows 10? If so, then try creating the Windows PE version of the Acronis 2020 Resue Media (using the Simple option) and then unlock the container from that booted media and try to do the backup from that environment.

Yorke Man wrote:

Although as you say, ATI should see it as just another local disc with a file backup, the simple fact of the matter is that it crashes in a repeatable way with the same error. It's also interesting that it fails in the backup 'add' phase, they never get as far as being actually run.

However, importantly it fails in the same way when controlled tests are run on dummy data, not only on a Jettico container, but on VHD’s. I’ve since run further tests, and ATI crashes when trying to add a new backup of files in an unencrypted VHD, i.e. no bitlocker to confuse things.

I'm still not sure what you are trying to do here.  Are you trying to back up the container, or are you trying to back up files within the container?  I have no experience with Jettico or with VHDs, but I use VeraCrypt and use ATI to backup my VeraVCrypt continer daily. 

ATI cannot backup my VeraCrypt container when the container is unlocked; VeraCrypt has exclusive control of it then.  ATI handles this lock by VeraCrypt the same way it handles any locked file on Windows and prompts for a Cancel/Retry/ ... response, but this is when I try to run the already existing backup task.  I don't know what happens if I try to create the task when the container is unlocked.  I'll give that a try.

Update:
I had no trouble creating a backup task for a VeraCrypt container while the container was unlocked (but the task would still complain when executed).  Maybe Jettico uses some nonstandard locking mechanism that ATI cannot handle.  Or maybe it's because my encrypted container is on a NAS.  (I would expect that to be more problematic, not less.)

I believe the Exception code 409 for msvcr120.dll indicates that a problem or bug exists in the call sequence of the application.  The msvcr120.dll is a runtime library file and to my knowledge ATI uses that file in the TibMounter module.  The file is located in C:\Program Files(x86)\Common Files\Acronis\TibMounter64.

I would recommend that you repair install the msvcr120.dll file in ATI and VC++ 2013 for Windows as it may be damaged.

To attempt to address the ATI file you can use Window 10 Add or remove programs.  Just type Add in the search box and open the feature in Settings.  Locate Acronis True Image and select Uninstall.  At the confirmation select Uninstall.  When the installer opens you will have the option to Repair or Uninstall.  Choose Repair.  The installer should repair any damaged or corrupted files it finds in the application.

For the Windows VC++2013, you can download the installer packages Here

and Here

You will find both and x86 version and an x64 version.  Install both.

This should remedy your issue.

Just fyi, all the three machines (old Win7, new Win10 Home and this Win10 Pro) all use ATI 2020 from the subscription service, so there should be no difference there.

Steve : Thanks again. btw, KB60915 is a really useful link for future reference. I've now been in touch with Acronis support and they have responded this afternoon (Sunday!) with a long e-mail and some details actions, so they seem serious about tracking this down.

Patrick : I'm just trying to back up the files in the mounted container, not the container, as apart from anything else, I need to back them up 'in the clear'. I've been doing it for years on my Win7 machine. In fact ATI also backs up the container file itself (I tested it) and has no problem when (as you noted) it was unmounted. It's not something I would do anyway.

I did try Truecrypt as an alternative to PGPdisc (I think Veracrypt was a fork?) and it worked fine, but after that imploded and after some research, I decided to move to Jettico as I migrated our two machines to Win10, because it was impossible to verify that PGP would work - Semantec are totally opaque as a company.

However, as my tests showed, encryption is irrelevant, as an un-encrypted VHD still causes ATI to crash in the definition phase (the VHD is just a virtual disc and the format is used by Oracle as well). It should be transparent to ATI, and yet it works on my old box which has a bitwise identical dll, according the the hashes (see below).This also shows it's not a Jettico issue.

Exchantec : Very relevant, thank you. The directory name the contained is in has an illegal XML character in, so I thought ti smight have been blowin. MSCVR120 has been one line of attack. Its v 12.0.21005.1 from VS2013 on both old (working) and new  boxes, in both System32 and SysWOW64 - ATI opens the file in the latter directory according to Systems  Internals 'Process Explorer'. This is not the latest version of the dll by any means, but I'm loathe to try changing it to a later one without further information. However, the SHA256 hash of the working SYSWOW version on the old machine is identical to the hash on the new machine, so it's pretty conclusively the same. TibMounter opens the file in SysWOW, rather than the (different) version in the directory you indicated, according to ProcMon.

However, you comment opens up an important area of investigation. The old machine has 28 copies of this dll in various locations and sundry sizes, and the new machine has 20 - already (!). The version in the directory you cite is not the same as the version in sysWOW - which drives the question why and which might be the 'correct' one.

All: Firstly, thank you all for the input, which has been most helpful. I'm going to check out the multiple MSVCR versions for good order, but the next task is to work through the Acronis e-mail. If we can keep this thread open, I'll report back when it's solved, or not as the case may be.

This smells of either something complex in the bowels of ATI or something really, really stupid and obvious after the fact which will leave me with a massive red face. Thanks to all.

SOLVED !!!! but I have no idea why ...

I couldn't figure out the inconsistencies in the various scenarios. - it just didn't make sense. Then I though back 40 years to what I used to say to my support desk guys when they used that term "Of course it makes sense.. computers behaviours are logical and repeatable". The tests so far had (broadly) eliminated the o/s, eliminated vendor code, the encryption process etc. So a quick stop by technet to look at the VS2013 docs, and I concluded that it was obviously something passed to MSVCR120. But ATI always failed in one place, which was precisely when entering the files to be backed up. So whatever caused the crash was in that one place when it checks the data entered in at that time.

If I am taking all files in a partition or folder, I just click the 'name' box at the top of the list. Fortunately, all the data are in two top folders in the container, so I thought I'd try them one at a time and then in combinations. My first thought was System Volume Information being a container, but no. The answer was that if I did not make any difference. To cut to the chase if I left out $RECYCLE.BIN it worked. I was sort of gobsmacked (as maybe you are).

The bin had about 170Gb of files in it. I deleted it, and lo and behold, it worked in the normal way by clicking the 'name' box at the top.

My last comment was rather prescient in that I said it might be something really, really stupid. It was a simple solution but I don't think obvious.

I took screen shots at every step of this to send to Acronis. Anybody any thoughts on the reason for this ???

Regards

The default exclusions set by ATI for all tasks would automatically exclude the Recycle Bin as the first item in the list.

Yorke Man wrote:

... if I left out $RECYCLE.BIN it worked. I was sort of gobsmacked (as maybe you are).

This is probably completely unrelated, but I had my own problem with a RECYCLE.BIN. 

It was defined and supported on a NAS and was not part of the Windows  $RECYCLE.BIN processing.  (It may not have even used the name "$RECYCLE.BIN".)  The recycle bin was in the share's top level directory, but I had (foolishly) allowed only the NAS administrator authority to read it.

When trying to set up a files and folder backup, ATI would not even list any of the files and folders in that directory.  It would not crash; it just treated the directory as empty.  When I changed permissions of that recycle bin and allowed all users access ATI displayed all the directory contents and would back up the NAS.

Steve

I didn't quite make clear in my note on the fix (which was implied by prior explanations) that the criteria are

crash IF (contained file) AND (recycle bin > critical value)

(the first predicate because the other backups taking a whole partition's files work ok)

I did have the standard exclusions which include the recycle bin, but it ignored them for some reason. The bin is recorded as 0 bytes in properties. I'll check the other scripts and see what they have in them.

I don't think the documentation indicates the application  will crash if the recycle bin is not in the exclusion list, but whichever way you look at it the fact is that software isn't meant to terminate in that way and it seems to be an ATI bug.

Anyway Steve, and everyone else, thank you for your valuable input - appreciated. I'll get back to getting my machine transfer completed!

I'm not sure how to close this down (first visit), as I don't have a green button to the right ...

Yorke Man,

Congrats on figuring out the issue and thank you as well.  I have seen a good number of posts on this Forum over the years with this same issue and never understood why the recommended steps to correct the MSVCR120 file would not resolve the problem in all cases.  I think I understand now however why that occurs.

Briefly, the Recycle Bin is a Windows system file and as such will display ALL installed fixed hard drives in a system.  Any deleted files on these drives will show up in the Recycle Bin.  Each drive space limit for the Bin is around 5% of free disk space.  You can view the allocated space for the Bin of each drive by right clicking on the Bin icon on the Desktop and selecting Properties. Clicking on any drive in the list will show allocated space.

ATI must compare the entire contents of the Recycle Bin file to the 5% limit of space.  That in turn, if this 5% is exceeded for the backup source drive, must cause the error.  If true this would indicate a bug in ATI as the app should not be doing this. 

Another possibility is with a large amount of space taken by files in the Bin, ATI is unable to process all the files for exclusion and that causes the error.  I think this is actually a more plausible possibility of the two here.

I am going to pass this along to Acronis for investigation.  Once again, thanks for you work here.

Hello everyone,

Thank you for indicating the issue!

Could you, please, send a crash report to us so that I passed it to developers? 

(usually after a crash or with the next start of Acronis True Image there is a window with "Send report to Acronis")