ATI 2016 & 2017 - Restored full systembackup with Win 10 1607 won't start on different partition anymore
Hello everybody,
I've been using ATI for years without any problems. Now I have a big one. For over 10 years I use one hdd which is divided in two partitions, A and B. Partition A is only for private purposes, partition B is my evaluation one for software tests purposes.
Everytime when B is full or needs to be cleaned, I start A, delete the B volume and restore the A image to B. So that I have to identical partitions and aftewards I can work with B again. As mentioned before, this worked for years.
3 days ago partition B needed to cleaned again. So I started A, updated it to 1607 including the latest updates, made a full backup of A with ATI 2016, deleted volume B and restored partition A to B.
After that I restarted my pc and started partition B. It did until the log in screen appears. After that the screen started to blink. I saw the background picture of my log in screen and a full screen with my chosen background colour blinking alternately. Never saw my desktop. I had to reset but that didn't help.
To make a long story short, I am still able to restore an image to a different partition. But this partition won't start anymore. This problem only appears with partitions with Win10 1607 installed.
When I try the same procedure with Win10 1511 including the latest cumulative updates, everything works fine as it did for the last 10 years with XP, Win7 and Win10.
I appreciate your help for locating the problem.
Thank you.

- Log in to post comments

I cannot help directly with this question as have not received the Win 10 AU update for any of my Win 10 systems yet and haven't had any desire to go get this given some of the feedback being published about problems AU introduces.
Out of interest, if you restore your B partition with 1511 and then upgrade to 1607 and take a backup of B at that point, can you restore that back to B and get it working OK?
I am wondering if 1607 (AU) has tightened up on taking a copy of a different partition and moving this to another partition, hence my question above?
I assume that you have your A and B partitions running in a dual-boot scenario.
- Log in to post comments

Thank you Steve for your comment. The scenarios you suggested have all been tried out by me. None of them did work out. And yes, they all are dual boot systems.
Here comes the strange part, now. I downloaded a demo version of Pragon Backup and Recovery and also of O&O Backup. I made a full backup of a partition with Win 10 1607. Restored the partition on a new volume and on an empty hdd. They both started fine.
Tried the same procedure again with ATI 2016 and 2017 and the new restored partitions started to hand themselves during the log in screen was shown.
So, who's to blame for this? Acronis or Microsoft?
- Log in to post comments

It certainly sounds like there is an issue with both ATIH 2016 and 2017 if neither of these can do a successful restore and yet you can use Paragon and O&O and do this fine!
I would recommend opening a support ticket against ATIH 2017 given the new support model that gives you a year of support instead of just 30 days as with 2016 and earlier.
Out of interest again, with Paragon and O&O did you do the restore from within Windows or using bootable media? Which method did you use for ATIH 2016 / 2017 (Windows or boot media)?
If using boot media, did you use the same boot mode as used by Windows (UEFI or Legacy/BIOS) for the media?
- Log in to post comments

For over 10 years I've been restoring from within Windows. I used this method also with ATI 2016 and 2017. 2017 is an Acronis demo version which I got from one of our company's administrator.
I hope that someone from Acrois will take a look at this thread and leave a comment on how to solve this.
- Log in to post comments

I have experienced this problem. I found that it is how your machine boots as to why this occurs. I would bet that your machine bios supports both UEFI and Legacy/CSM boot. I would also suspect that you have both boot options enabled in the bios of your machine. You are probably booting the machine in UEFI mode to normally start Windows. If you change your bios boot setting to UEFI only mode then I believe you will not have this issue, it worked for me.
- Log in to post comments

Enchantech wrote:I have experienced this problem. I found that it is how your machine boots as to why this occurs. I would bet that your machine bios supports both UEFI and Legacy/CSM boot. I would also suspect that you have both boot options enabled in the bios of your machine. You are probably booting the machine in UEFI mode to normally start Windows. If you change your bios boot setting to UEFI only mode then I believe you will not have this issue, it worked for me.
I am happy for you that you solved it. But it did not work for me. Tested on 2 different machines with Asus Boards. As you suggested I changed on both machines the CSM setting to "UEFI Only". No success.
Thank you anyway.
- Log in to post comments

Have you tried with Secure Boot disabled?
- Log in to post comments

Steve Smith wrote:Have you tried with Secure Boot disabled?
Yes I tried both settings Secure Boot enabled/disabled.
- Log in to post comments

My experience was with ASUS boards as well, Z97 Deluxe boards to be more specific. I have had this twice on 2 different builds. In one case I was able to simply change the bios setting and that fixed the issue. In the other it was necessary to also disconnect all attached internal SATA drives other than the OS disk from the board and change the boot to UEFI only which solved the problem. You might have one of these stubborn boards as well. Don't really think it is the boards themselves but rather the bios versions that cause this issue. I am now running the latest current bios revision 2907 and have not seen the issue since this update. I will say however that leaving both boards set to boot UEFI only has resolved several issues I had with these boards and 3 different bios revisions.
I also found that what was happening in the case of my most stubborn was that upon boot of the restored drive Windows decided that the boot drive was another disk installed in the machine so Windows went into repair mode and wrote an EFI partition to one of the other SATA disk installed in the system. I found this by using the install media command prompt and using diskpart to list disk and then list partition on each disk. I cleared the EFI partition from the incorrect disk, detached all SATA drives from the board except of course the OS disk, and ran the restore while booted from the recovery media. I understand this is not ideal and not how you are used to doing things but worth a try to get your machine back up and running.
- Log in to post comments

@Enchantech: I appreciate your detailed comment. I will give this scenario a try. But let me ask you, do you have to unplug the SATA cable everytime after you restored an image to a different partition or is this a only necessary once?
I have here three machines 2x ASUS X99-E WS / USB 3.1 and 1x Asus Rampage V Extreme Edition 10. I will try to update each BIOS version to the latest ones also unplug all Non-OS SATA drives.
Just to be clear, you experienced the same issue after you updated to Win 10 1607?
- Log in to post comments

In hopes to fully clarify my dealings with this issue:
My first experience with this was during beta testing TI 2016 while running Windows 10 Pro X64 10586.318 (1511) with bios revision 2501. This occurance was remedied by changing the bios to UEFI boot only. At the time I believed it to be due to 2016 being in beta. I also had some inclination to think that my restore attempt from within an active Windows session of the Windows OS system might be part of the issue. I do not perform OS system disk restores from within Windows normally, it is and has been my practice to do so using boot media but in beta testing I took the chance. Having said that after changing the bios boot mode to UEFI only I did run the restore from the Windows installed application and it was successful.
My second experience with this which was the worst was using the release version of TI 2016 while running Windows 10 Pro X64 10586.420 (1511) with bios revision 2502. This occurance was the most troublesome requiring the disconnect of the SATA drives. In all honesty I may have gotten by with just disconnecting the drive which Windows decided to write the EFI partition to. That drive ( a Patriot Torch SSD) I had added to the system as a spare test drive but becasue of the trouble I was having I just disconnected all of them. The restore was again done from within Windows as I was once again testing such a restore. The difference here being that my final recovery which worked I ran from the boot media rather than from within Windows.
In both cases recovery attempts were performed from backups of the same version/build of the already installed OS. Sinse my experiences with this I have made it my policy now that any time I do recovery of a system disk I disconnect all attached SATA disks except the source and target disks. I will not even perform a Windows 10 install with secondary drives attached and since I have moved to exclusively UEFI boot machines I change the boot mode to UEFI only when performing Windows 10 installations.
I made an error in my previous post in the version number of bios typing version 2907 when it should have been 2903. Since my update to this bios revision I have not had cause to attempt a restore of a Windows 10 system OS from the installed Windows True Image app. It is my belief at this time that having multiple SATA drives attached is the cause of this issue and it can happen during recoveries or installs. Jump over to tenforums and do a search for blinking screen or blinking startup screen and you will find a number of links about this problem incuding one that proclaims it an admitted bug in Windows 10 itself.
I will add that the Patriot drive to which Windows decided to write an EFI partition to while atempting to repair itself was attached to a second SATA drive controller on my Z97 board. This may have something to do with it as well.
So as it stands I have not experienced this issue with the Windows 10 anniversary update. Quite frankly I hope not to even though I am confident I could overcome it.
- Log in to post comments

Thank you very much for all the detailed information. I followed every single part of your suggestions.
I tried each of the latest 4 Bios versions on every one of the 3 boards. I disconnected every SATA drive except the OS one before I started the restore process. Every time I restored the OS partition to another one I got the blinking screen during the start of Windows on the new partition again and again.
Even a fresh iinstall of Windows 10 1607 didn't do the trick.
But here comes the crazy part. I converted my .tib images to .vhd. Imported the .vhd imges to my demo version of Pragon Backup and restored those images every time to different partitions or empty hard drives. And it worked. They all started Windows without any problems at all. Tested on each one of my 3 machines.
I really hope that the Acronis technical support will comment this and maybe will help to solve this issues.
- Log in to post comments

Very stubborn issue you have here. I have 2 suggestions left. The first is recovery using the boot media rather than the installed Windows True Image app. I know you do not want to do it this way but it might just be your only workable solution with True Image.
The second is this, when you configure the recovery task are you including the MBR Track 0 in the recovery? If yes try leaving it out of the recovery if no then try adding it to the recovery. The documentation states that if recovery is performed to the same disk do not include the MBR Track 0 but if you have problems booting to then restore the MBR Track 0.
This reads that you should restore the disk omitting the MBR Track 0 and if boot problems arise to then restore just the MBR Track 0 to the disk. I have never done this but do not see any reason why it would not work so may be worth a shot in your situation.
- Log in to post comments

In addition to the MBR track 0, a seperate test could be running universal restore and generalizing the drivers and see what the video behavior is like after that - just as a test. Of course, this would not be ideal (if it works) and should not be necessary since you're using the same hardware and have been doing backup and restores just fine prior to the Windows 10 1607 update. Worth a shot if you're still interested in trouble shooting. If, for some reason it works, you could then reinstal drivers, take an image and try another resore and see if the behavior returns or is resolved.
- Log in to post comments

I had also found this (http://techdows.com/2015/08/fix-screen-flashing-issue-in-windows-10.html) as a possible solution in a different thread where screen flashing was happening in Windows 10 as well. Never heard back though.
- Log in to post comments

Thanks to everybody, but I have to stop trying. After I also tried O&O Backup software and was again able to restore and to start the restored partition like it was possible with Paragon my conclusion is, that Microsoft must have changed something with the 1607 update that Acronis cannot handle it anymore the way I restore my partitions.
So I have to wait until Acronis releases an updated build that will work for me again as it did the for the last ten years.
@Bobb_3C0X1: The two services mentioned at Techdows.com are already deactivated in my system.
@Enchantec: I only restore my partition without MBR or EFI.
Thanks again for your help. I really much appreciated it.
- Log in to post comments