Home AOMEI Products Support

Backup C: partition then restore to F: partition causes screen flicker when booting to F:


To test AOMEI Backupper Pro v3.2 I performed a partition backup of my C:
partition then restored that backup to an identical partition (F:) on
the same disk.  When I boot to F: the Windows login screen appears
normally, but when I log in my monitors start flashing and continue this
indefinitely.  (Each time the monitors flash the Windows desktop
briefly reappears.)

Past testing worked:
I tested this backup/restore-to-different-partition AOMEI functionality
last year on Win 7 and it worked.  Also, after I upgraded one of my PCs
to Win 10 I used the AOMEI partition backup/restore operation to copy
Win 10 from my first PC to my second PC.  The second PC then ran Win10
with no errors.

More information:
Booting to the (unchanged) C: drive remains functional.

I have validated the Win 10 installation on C: using "sfc /verifyonly"

I have validated both the F: and the C: drives with "chkdsk".

Backups which do not restore are not useful.
Any assistance is appreciated.

My System:  Windows 10 Pro (x64), fully patched with windows update
                        Dual ASUS VE228H monitors
                        Dual boot option is managed with EasyBCD from NeoSmart Technologies

Plans:
Try partition C: backup, then restore to partition F: on my second PC to see if the sequence also fails there.

Comments

  • Sorry for that our software cannot support to boot two systems in one disk.

    There is one condition maybe it is worked, what is te system in C partition is unable to boot.

    We do not know why you do it sucessfully in the past testing.

    Sorry for the inconvenience again.


  • edited May 2016

    dual boot is more complicated than just restoring c: to f:  and "booting" into f:

    There is also windows recovery environment, and I assume this causes to boot back to your c: and flash.

    I did not see EasyBCD handle the dual windows recovery environment. There are also setup information in c: and f: (that point to the windows recovery environment of c:)

    Validating and repairing using sfc is past technology, it worked in System 7, but does not help in Windows 8 and later. Now one has to use dism. You may safely assume that Backupper did copy and restore the individual partition contents properly.

    And how about detaching one monitor? Maybe the graphic card driver is bound to the original partition, although it should not be the case. It should rather not be the monitor, but the graphic card if graphics is the issue. If it is not bitlocker, other encryption, virus protection and the like.


  • edited May 2016

    I wonder, if you boot from the Win10 on F: does Explorer show the current OS on C: or on F:? It should be C: but when a partition backup is restored on F: it could easily be F: and C: being not present because drive recognition is hardcoded. So any (registry or exe) referal  to C: (like a monitor driver) points to a non existing drive.

    You should remove all the device mapping on the C: version immediately before making the backup (or as soon as possible on the F: version)


    Regedit: HKLM\system\MountedDevices

    Delete all entries except Standard. They will be rebuilt at first start up. Now your F: version maps to C:  and maybe you have to manual assign a letter to your original C:


  • edited May 2016

    >>>>I wonder, if you boot from the Win10 on F: does Explorer show the current OS on C: or on F:?

    Windows OS is always on C:. On conflict on preferred drive letters Windows assigns drive letters as needed. Drive letters are not fully hardcoded, except A: B: C: X:. (Consider USB where it happens frequently. I assign drive letter H: to a USB, partition, und usually get H: for it. When H: is already occupied I get J: or K:, and next time I get H: again. However nothing can be hardcoded as F: in this question, as F: was an empty or non-existing partition.

    I understand C: in this thread's question as "first OS partition" and F: as "second OS partition" and not as drive letters proper. In such a case, a tag in every partition, after restore, before EasyBCD, would be helpful, that is C:\ThisIsTheFirstPartition.txt, F:\ThisIsTheSecondPartition.txt. (I have done on Recovery partitions, in WIMs and the like in multi-boot-exercises including vhd dual boot, where everything looks nearly the same).

  • edited May 2016

    Windows OS is always on C:


    No, that is not always the case.

    If you backup an OS partition and restore in on  the same disk in another partition, that OS starts from the other partition. Hardcoded may be not the right expression, but in the (copied) registry is recorded that device xxx = C: and device yyy = F:. xxx and yyy stay the same on the same disk, so C: stays C: and F: stays F:.

    You cannot test this behavour with vhd's or virtual PC's. Only on the HDD directly.


    Another example: If you install Win7 on another partition (like F:) from within a running OS (like C:) , it will start from that other partition, F:.  Only if you install from an external medium (like DVD) on system boot it will remap your drives and the original F: will start as C:.


    By deleting the MountedDevices registry the device assigns are built again at start up and OS will allways become C:


    If the cloned OS (from C:) starts from F:  you may be not noticing that links point to C: drive, like C:\my documents. In this question I assume that F: existed before the backup or clone was made, so the F: assigning was recorded in the registry and then of course also in the copied OS.


    If TS restores on another disk the the OS will be on C:, existing drive assigns will automatically rebuild.


  • Back to the problem:

    Even if C: exists while the OS starts from F: things can get mixed up. Especially with poorly written programs. 


    Example if the current OS is on F:

    C:\windows refers to "the other" partition

    \windows refers to the current partition

    %windir%  normally to the current, but in this backup/restore situation I am not sure.


    So if a program writes to C:\windows but reads from \windows (or vice versa) things will go wrong. therefore my first question, is the OS starting from C: or F:?


    I can't think of another reason why some peripherals don't behave as normal, since the copied OS holds exactly the same files as the original. Only hardcoded pointers can go wrong.




  • edited May 2016

    You're right it happens, it never happened to me.

    (I  could try it on a virtual computer. Windows will not be different on virtual disks from real ones and can have multiple partitions and multiboot).

  • edited May 2016

    This is how it looks when I boot from the original partition. This boot does have the Windows Recovery Environment (details on request)

    image

    This is how it looks when I boot from the second partition, GG.  CC gets the drive letter F: assigned, and GG is drive letter C: This boot does not have a Windows Recovery Environment (details on request).

    image



    I was not able to change the drive letter of C: to something else, trying Windows Disk Management, trying diskpart.


    In the green, original boot, I was able to change the drive letter of C: to H: using mountvol and it broke Explorer and the command shell, and I was able to revert (doing CD to g:\windows\system32). This was however a special experience.


  • edited May 2016

    I was successful in producing a similar screen effect as the original poster asked.


    I did this: I  renamed the registry entry, on the red system where OS is GG,

    HKLM\System\MountedDevices\DOSDevice\C: to HKLM\System\MountedDevices\DOSDevice\G: and rebooted, and got a similar flashing effect as in the original question (everything black, and the cursor goes away and comes, and sometimes a spinning wheel appears and goes).

    I then proceeded to rename the registry entry on GG back (it was involved to do it, and I did it from CC and it was involved) and GG booted again fine.


    In the original posters question, I need to assume that "something" adjusted drive letters, because in ordinary Windows 10 everything is fine when booting GG. Maybe in Windows 7 it is different, or some utility is extra-fixing HKLM\System\MountedDevices in the original question.

  • edited May 2016

    I just tested this too, but on a real pc with a real harddisk. You (probably) cannot simulate this on a virtual disk.


    Situation before, The OS (Win10Pro) is on C: and D: is empty.

    image

    I tested with a clone from C: to D: and I tested backup from C: to external disk and then restore via Linux CD into D:. Both times the same result.


    After the clone/restore was complete I started the original OS and added an entry in the bootmenu for the copied version using EasyBCD. 

    I also changed a textfile name (ThisIsOriginal.txt) on the desktop from the copied version to: D:\users\<username>\desktop\ThisIsTheCopy.txt


    Then I rebooted and started the OS copy.

    The flickering began. After a few minutes the flickering stopped and taskbar icons appeared. I could open explorer.

    image

    As you can see Windows 10 starts from D: (WinLogo). But the desktop shows: ThisIsOriginal.txt and the user documents and pictures refer to the original C:

    The Startmenu didn't fire. A complete mess. The flickering can be seen as a warning: "This Windows is messed up!"  . On internet you can find a "solution" for flickering screens by unchecking 2 error report services, but that only suppresses the symptoms not the cause of the error.

    B.t.w. %windir% is D:\Windows


    I rebooted into D: and again the flickering for a few minutes.

    Then I deleted the HKLM\System\MountedDevices entries (starting Regedit.exe in Explorer)  and rebooted.

    Everything was fine. No flickering anymore. 

    The desktop showed: ThisIsTheCopy.txt and old_D became C:

    But the original C: was missing. You can assign a letter in disk management if you like.

    image


    This behaviour is not specific for Win7 or Win10. It exists at least since Win2000/XP.

    www.goodells.net/multiboot/partsigs.shtml

     (Remember: only on the same harddrive in another partition, this problem occurs)

  • edited May 2016

    I did not restore from the Linux CD, but from within the live system. I did backup and I did restore from the live system. My backup was to a NAS. The virtual disk is SCSI, not SATA or IDE in my case.

    I shall test restore with the Linux CD. I shall use the virtual disk as SATA. In my opinion a virtual computer is as good as a real computer. And MBR is as good as GPT, specially since the behaviour is old. I hope NAS is as good as a real external backup disk. All this should not make a difference.

    I looked at the MountedDevices in my case #8, they were fully present, but did auto-change as needed for the flicker-free good result.

  • edited June 2016

    Phew, what a mess. image


    A Clone is the same as a backup and immediate restore, isn't it? No it is not.

    A Clone is a clone, isn't it? No it is not.


    Suppose I have a PC with C:, D: en F: partitions. C: and D: both holding Win10 and F: is empty. I want to clone the C: partition to F:. There are at least 16 ways of doing so. With different results.

    Possible outcomes when starting the Win10 copy from F: after an entry in the multiboot menu is added in the C: version using EasyBCD:

    1. The F: drive is now called C: and everything works fine. Other drives may have no letter assigned and invisible in Explorer. Letters can be assigned in Disk Management.

    2. The F: drive is still called F: and holding the OS. %Windir%=F:\Windows. C: is still C:

    This results in flickering screen since everything is mixed up. Desktop from C: is shown etc.  This can be fixed by deleting all entries in HKLM\System\MountedDevices and reboot

    3. F: won't start at all. light blue screen errors when trying to. EasyBCD cannot fix this.


    The 16 methods, 4 Clones and 12 backup/restores:

    You can make a partition clone of C: to F: using Aomei backupper started from:

    a. from running C;,  result=2

    b. from D:

    c. WinPE DVD, result=2

    d. Linux CD, result=1


    You can make a backup of the C: partition in 3 ways

    e. from running C:

    f. from D:

    g. WinPE DVD

        Linux CD has no backup option


    You can restore that backup into F: in 4 ways

    h. from running C:

    i. from D:

    j. from Linux CD

    k. from WinPE DVD


    4 + 3x4=16. It takes a lot of time to test all these combinations. If one wants to, be my guest.  I (and Peter) tested a few:


    a.  result=2

    c.  result=2

    d.  result=1

    e. + h.  result=1.

    e. + j.   result=3 (tried twice)

    e. + k.  result=1

    f. + h.  result=2

    f. + j.  result=2

    g. + h. result=1

    g. + k. result=1


    I suppose that the version of WinPE is not important but I am not sure. I used Win7PE.


  • edited May 2016

    A very good analysis, congratulations!

    It looks like MountedDevices is not always copied, and gets then rebuilt.

    That heap, SYSTEM, is contained as a file in Windows\System32\Config on the cloned system and can be attached as a structure to HKLM, in WinPE or in the original system. It will allow to see what really gets copied.

    Method a, and method e+h are first study objects.


    PS what are the error codes on result 3. ? If it is "required device" this could happen when the partition is not at exactly the same location (MBR case) because disk signature+partition start address make the precise identification of the partition in BCD, and partition is called "device" here.

  • edited May 2016

    The same backup file (e.) is used in h., j. and k. Only the Linux restore (j.) didn't work. Peter, you mentioned in #11 you would try the Linux restore. I am curious if you get the same error.

  • edited May 2016

    I did not try e+j, however I tried e+h and got the behaviour 2.

    I then deleted just the MountedDevices entry of the second partition F: but it did not help.

    I did then another try of e+h and got behaviour 1.

    There is a difference: whether the second partition, F: is already known at the time the backup is taken. On the first try of e+g the second partition F: did exist at backup time. On the second try of e+g, the second partition F: did not exist at backup time, therefore it did not have an entry it the backed-up registry (file SYSTEM in windows\system32\config).
  • edited May 2016

    for e+j I got behaviour 2, when I boot from the second partition, and it flashes and the start menu does not show.


    This dual boot issue is not specific to Aomei backupper and known since ever...

  • edited June 2016

    So you got different results than I did. And I don't understand what you mean by e+g? e+k I guess. Nor do I understand that e+h now results in 2, while in #11 you said it was 1. Did you reboot after the deletion of MountedDevices?


    And indeed as I mentioned in #10, it exists at least 16 years. It's a Windows thing not Aomei's.  www.goodells.net/multiboot/partsigs.shtml


    I did another e+j with a new backup (e). Now I got result=1 without errors. I have nu clue what's the difference between e1 and e2.

    So we have 3 outcomes with the same procedure. I got 1 and 3, Peter got 2.


    And  I did another f+h (new f), again I got result=2.





  • edited June 2016

    e+g was misprint, it was e+h, and Backupper did a reboot into WinPE to do it. The only reasonable explanation in behaviour is whether F: existed at the time the backup or clone was done. And even then it seems not clear why it works sometimes.

    I did not delete MountedDevices ( because I was just testing and we know that it resolves).

    For behaviour 3. my best explanation is the following: the entry in BCD for the cloned partition F: already existed, but another restore got F: to a different, slightly different location (MBR case, where only the location counts as signature). In the GPT case, it would be completely explainable, because every restore, that is delete and re-create of the partition, creates a different partition signature.


    continuing behaviour 3: Although partition drive letters are displayed for BCD, internally in BCD it is the disk signature+partition signature that is stored. Drive letters displayed or entered are converted on the fly. This was even more drastic with VHD, where I say partition=K: (K: a OS partition in a VHD \file.vhd), but internally it is not K:, but instead type VHD at (parent disk, parent partition, \file.vhd, and within the VHD: disk, partition), a total of five pieces and a different type, never shown and not enterable directly. I could see them by reading BCD00000000 using regedit.

Sign In or Register to comment.