Ran into this issue yesterday. Typical situation where a client wanted to upgrade one of his employees laptops. We got a similar Acer Travelmate model, just a few years newer. I find these to be excellent value for the money and very reliable.
The plan was to create an image of the drive from the old computer and restore it onto the drive in the new computer. I used an external USB SanDisk SSD, although it would have been even more straightforward to use a M.2 SSD adapter - but these are pretty expensive and different generations use different "keys" so you need the right adapter for the job. So these were the steps I took:
- Use Macrium to create an image of the old laptop's system drive onto an external USB drive
- Use Macrium to create an image of the new laptop's system drive (this way if things go badly I can just go back to where I started)
- Create a Rescue Environment in Macrium onto a USB stick
- Disable Secure Boot on the BIOS of the new laptop, and enable the boot menu (F12 on Acer laptops)
- Boot the new laptop using the USB stick into the Macrium Rescue Environment and restore the image of the old laptop's system drive onto the system drive of the new laptop
In the boot menu the system recognized the Windows Boot Loader (on the first, EFI partition of the cloned drive). A little spinny animation came up and then the first error: Inaccessible Boot Device!
Inaccessible Boot Device!
This was straightforward to fix because Macrium provides a "Redeploy to New Hardware" function in the Macrium Rescue Environment. This feature is well documented in the Macrium Knowledgebase, see: Re-deploying Windows to new hardware using Macrium ReDeploy. Macrium may ask for some missing drivers, which in my case was "Intel RST VMD Controller." You can find these on Intel's website (look for the zipped, VMD version with filename "F6flpy-x64 - VMD.zip"). Download it and unzip the archive to a directory on the Macrium Rescue Environment thumb drive, Macrium will then automatically find the missing drivers during the redeploy process.
Additionally, Macrium also has a feature called "Fix Windows Boot Problems" which is also well documented in the Macrium knowledgebase: Fixing Windows boot problems
This feature basically helps fix issues such as invalid Boot Configuration Data. The BCD usually needs to be corrected after cloning a GPT formatted drive because the drive ID and configuation will have changed, and Windows will not be able to boot until the BCD is updated.
For some background on the BCD, please read: Working with BCD in Windows 10
Understanding the modern Windows boot process
Use of boot configuration data, or BCD, and the Windows bootloader was introduced with Windows Vista. Windows OS load behavior was substantially reworked in 2004, when Vista was still code-named “Longhorn” to support EFI and to overhaul the earlier NTLDR (“NT Loader”) architecture used in preceding versions of Windows NT.
In fact, BCD is best understood as a firmware-independent database for boot-time configuration data. The BCD information resides in a data file named bootmgfw.efi in the EFI partition in the EFIMicrosoftBoot folder. You will also find a copy of this file in the Windows Side-by-Side (WinSxS) directory hierarchy. When a PC begins booting, a firmware-based bootstrap loader starts the boot process and then hands the process over to the Windows Boot Loader (you’ll see this latter program referenced as a line item in your BIOS or UEFI boot information, usually as the default OS boot entry). That boot loader accesses the EFI partition on the default or designated boot drive, and uses the BCD information to start booting the OS so it can take over control of the PC.
There are two major variations on the Windows boot theme. Some (mostly older) PCs use a Master Boot Record (MBR) disk layout and work with BIOS to perform what’s now called a “legacy boot.” Other (mostly newer) PCs use a GUID Partition Table (GPT) disk layout and work with UEFI to perform what’s called a “UEFI boot” or “EFI boot.” Some of the details involved in managing boot vary according to the type of boot (legacy vs. EFI) that’s performed, so it’s important to know what you’re working with on any given PC…
After running both the "Fix Windows Boot Problems" and the "Redeploy to New Hardware" functions on the new computer from within the Macrium Rescue Environment, windows started to boot! And then promptly showed a BSOD with the error "iastorafs.sys"
iastorafs.sys BSOD
You may get an "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED" or "DRIVER_IRQL_NOT_LESS_OR_EQUAL" mentioning iastorafs.sys, and no amount of restarts or windows repair sessions will help. You can google and you'll find plenty of useless articles on the topic such as this one: Top 3 Ways to Fix iaStorA.sys BSOD Windows 10 where they explain how to resolve the issue…from within Windows.
Luckily Erik over at tipsdotcom.com stumbled upon an easy fix, which he describes in detail in his post "Macrium Reflect iastorafs.sys BSOD Error". I suggest you read it, but in short, you simply have to boot into the Macrium Rescue Environment and use either the command line of the Windows Explorer utility (little icon on the bottom-left) to find "iastorafs.sys" and rename it to anything else. In my case it was located here: c:\windows\system32\drivers\iastorafs.sys
Finishing Up, igfxdin.dll bug
The steps above were enough to get me into Windows. Of course, next steps are to use windows upate to install all updates as well as missing drivers that Windows can find for itself. I also downloaded drivers and software manually from Acer's website, since Windows isn't able to find everything using Windows Update. And then, as icing on the cake, after a final reboot windows went into a forever loop where after logging in, the explorer process kept crashing, so basically the taskbar kept disappearing and reappearing. Even booting into safe mode or with low-resolution drivers didn't help. Luckily the task manager still worked and from there I was able to open the windows event viewer (just run eventvwr), and in the application logs I saw the same error being logged over and over mentioning igfxdin.dll. Because this is associated with the "Intel Common User Interface" I first thought it must be one of the Intel drivers I just installed. It took me a while to realize that the real cuplrit was OpenShell, which I had installed on the old laptop. Perhaps it was trying to show some message and this was leading igfxdin.dll to crash, which took the explorer process with it - I'm not enough of an expert to understand the process - but in the end I was able to run appwiz.cpl and uninstall Open Shell. This fixed the issue. Of course, I tried to reinstall it just to check, and the problem came back, so for now the user will be stuck with the terrible Windows 10 start menu. Oh well.
