Skip to main content

Mounting image error / tib image id data

Thread needs solution
Forum Member
Posts: 19
Comments: 53


I think Steve Smith has this info, but I know he prefers a new topic vs. private mail.  The following really (in part or fully) can apply to TI 2016/2017/2018.  As a background I have a number of PCs with TI installed.  While I do occasionally use the windows main program (usually to mount a FULL DRIVE image backup, via the Windows Explorer context menu) to retrieve a single file contained therein.  I always create (using the MVP program) a WIN PE boot USB drive, by which I actually create all of my FULL DRIVE IMAGE Backups, and to Restore such a FULL DRV TIB to a FRESH HDD in case of (e.g.) a program or Windows update gone rogue.  Also, I must say the using the WINPE "rescue" USB boot method is (for ME) VERY stable and more flexible compared to the Windows Full, have 10+ systems here, I simple backup/restore images from several Large USB drives.  Again, I ONLY create FULL DRIVE IMAGE BACKUPS...never incremental, nor File/Folder backups-and I verify every backup.

So, today, I was looking for an old file, and so wanted to use the ATI Windows Program to mount an Image....and it failed with the error "Cannot assign a drive letter to a partition from a backup archive".  Browsing the support section of Acronis, I do find prior posts, and patches (you mentioned...some time ago.).  Let me say that SOME TIB (FULL) images WILL mount and assign drive letters.  The case in point is a PC with ATI 2016-6595 installed.  As far as I can determine some TIB's DO NOT have this issue, others do.  All verify OK.

At the moment I am considering that (?) this might be an issue of a situation where I have an image created with ATI 2017 or 2018 and trying to mount with 2016-6595...But I do not think so.  Obviously I am aware that the Main Windows based program, or rescue disk may not mount or process a backup file created with a NEWER ATI variant (e.g. FORWARD compatibility is NOT expected).

As a programmer I would expect that each TIB file would (perhaps in it header data) an identifier that would indicate the ATI VERSION (year/Release) that created the TIB file???  Surely?  Do you have any info on this, utility tool that can retrieve it etc.




0 Users found this helpful
Forum Member
Posts: 19
Comments: 53


This does not appear to be an issue of mixed version backups:

1. Only some backups have the problem (eg tibs from the same pc only 2 days apart, 1 is ok, the other not)

2. The system HDD contains win7, Basic MBR system partition (C:) and a secondary partition D:

3. In some cases I can select & mount perhaps either C or E but not both

4. Other times Mounting only works if ALL partitions of the ONLY HDD in system are selected.

5. Same error, on same TIB occurs attempting to mount the TIB on either a W7 system (2016-6595) AND on a different W10x64 system running 2017-8058.

6. All images (TIBs) pass validation test on all host systems (w7 and w10).

7. At the moment, tests so far indicate that FULL TIB images which have "mounting Problems", WILL (using MVP WINPE rescue USB, actually do a bare metal restore sucessfully...that is...the entire system drive is recovered  with all partitions, bootable etc.  Of course, this is really good and goes along with all TIBs passing Validation either in the Main Win Application AND also via the WinPE rescue media.

====  Looks to me like this is a multi-year version "bug" in the MOUNT functionality of ATI?



Posts: 109
Comments: 28191

Bob, please use the MVP Log Viewer tool (available via the Community Tools link below) and check what is shown in the TibMounter logs for when you have tried to Mount your backup .tib files.

This can be helpful in trying to understand what is happening here?

I see the following entries in my log for a mount of a small partition image:

05/08/2018 23:24:14 :407  [T] build: 2592; process: 10572; 'C:\Program Files (x86)\Acronis\TrueImageHome\TrueImageTools.exe'
05/08/2018 23:24:14 :407  [T] 2018.08.05 22:24:14 UTC
05/08/2018 23:24:14 :407  [T] 2018.08.05 23:24:14 LOCAL
05/08/2018 23:24:14 :407  [T] Control device '\\.\Global\TibMounterControl2592' handle=1564
05/08/2018 23:24:14 :408  [T] UserMan Init status 0x0
05/08/2018 23:24:14 :408  [T] DLL: 5.0.2592 Acronis TIB Mounter API
Copyright © Acronis International GmbH; 2002-2015.
Driver: 5.0.2592 Acronis TIB Mounter Driver
05/08/2018 23:24:14 :408  [T] vbInit status 0x0
05/08/2018 23:24:15 :138  [T] vbGetLogicalDrives result 0x7FC
05/08/2018 23:24:15 :139  [T] vbGetLogicalDrives result 0x7FC
05/08/2018 23:24:23 :282  [T] Mount TIB parameters:
2 U: RA
05/08/2018 23:24:23 :282  [T] BusInfo: 0 devices { }
05/08/2018 23:24:23 :283  [T] pathCount=1 [password] [encryptionKey]
05/08/2018 23:24:23 :330  [T] PrepareForMounting success
05/08/2018 23:24:23 :572  [T] remove handle=1844
05/08/2018 23:24:23 :572  [T] BusInfo: 1 devices { 0 }
05/08/2018 23:24:23 :572  [T] letter mask=0x100000
05/08/2018 23:24:26 :653  [T] Mount status 0x0 (3375 ms)
05/08/2018 23:24:26 :653  [T] vbMountTib status 0x0 (3375 ms)
05/08/2018 23:24:31 :050  [T] Passed ...
05/08/2018 23:24:31 :050  [T] Control device handle 1564 has been closed
05/08/2018 23:24:31 :050  [T] vbDone status 0x0

Start: 05/08/2018 23:24:14
Stop: 05/08/2018 23:24:31
Total Time: 00:00:17

In the above, it shows the full path of the image being mounted and then the drive letter assigned for this (U:).  The image was of a small USB stick with ATI 2014 rescue media mounted on my ATI 2018 system.

Forum Member
Posts: 19
Comments: 53

Dear Steve,

Thanks for your prompt response.  In the meantime I have begun to sort-out some of the original issues.  Without repeating myself, I had mentioned (due to my needs across several PCs, running win7,w10x86, w10x64, plus the fact that I have several 4-6 GB external USB drives to which I backup to and restore from...and I rotate these external drives (and thus the backups) for more security so that if a single ext. USB HDD backup drive fails it won't cause panic as by rotating the storage media 3x week, at worst I'd lose 2 days of work.  With this in mind, with the inception of ATI 2015 up, swapping around the external storage media causes all sorts of confusion in terms of ATI's internal backup "database" of what was backed up, when, where and seemingly the actual TIB file name vs the backup name displayed in the WIN full applicaton.  OK, I think you get it.

For that reason, plus any particular ext HDD BU drive might have backups from 6 PCs, and the original source of these backups might have been ATI 2016/17/18.  For me ATI was just trying to become "too smart".

For this reason, I have created WINPE "RESCUE" USB drives.  These cannot ONLY be used to Recover an image TIB FULL backup, but can also be used to CREATE a new full Drive Image TIB backup.  In this way, I enter my own descriptive names, in my own method on the EXT USB drives.  Never had an issue.  These backups also Validate using the rescue USB or from within the Main Windows App.

I actually only use (mainly) the full ATI Windows Installed Program to Create the Rescue Win PE w/wo UR, Validate TIBs and occasionally to MOUNT a backup (produced by the RESCUE USB Backup made TIB.  What I have found is that, seemingly without any cause I can find, some TIBs may not always Mount (Rt Clk Win Context window)...see my first post in this chain.)  Then again, 10 minutes later it may work..or not.  This issue is NOT tied to situations of trying to (for example) mounting a ATI 2017 produced TIB with a full Windows ATI 2016.

In all cases where this unreliable behavior occurs, I can, Using Windows explorer, simply expand the TIB (all my TIBs are 100% FULL Backups) and I have access to all partitions, folders & files.

My educated guess at this point, is that the TIB internal file structure when produced via Rescue Media vs. the Full Windows App are somehow inconsistent??  I would not expect this behavior to be by design?  Any comments or ideas?



Posts: 109
Comments: 28191

Bob, I have never encountered any issues that suggest there could be differences in the TIB internal file structure between being created via the Windows app or via using Rescue media.

There is one tip to clear the TibMounter Cache that you can try to see if it makes a difference:

Try deleting all the files in C:\Users\[your_username]\AppData\Local\VirtualStore\ProgramData\Acronis\TrueImageHome\Database 

This location may or may not exist when you look for it but the tip came from one of the Acronis Senior people (Slava) a while back and I saw it being suggested by Ekaterina recently in another forum topic.

Posts: 109
Comments: 28191

Bob, if you visit the MVP User Tools and Tutorials repository on Google Drive, there is a batch file there created by Bobbo back in 2016 for automating the clearing of the TibMounter cache and which handles the case where the location doesn't exist.