I love Acronis TrueImage. It’s one of the essential CDs in my toolbox, always handy for backing up data on hard drives, cloning disks and saving a lot of time. Even Seagate is using a custom version of TrueImage for its hard drive installation tool.
By the way, if you’re into Open Software, my second choice is GPartEd – free and just as powerful!
Having cloned so many disks and systems before, today’s seemed to work as a breeze. After all, I was transferring the software between two laptops of the same model, from one with lower specs to another one beefed up with RAM and a bigger hard disk. On the new laptop, Windows started normally and needed drivers only for the new wireless network card. Perfect, right?
Double-clicking the “Safely Remove Hardware” icon in the System Tray returned the following error: “An exception occurred while trying to run Shell32.dll, Control_RunDLL
At this time, I was fearing that either I’ll have to fix some crazy DLL by running sfc /scannow in command line (to check all Windows core files and restore them from the hidden repository) or by doing a repair install. I also suspected the RAM, although earlier tests proved it to be error-free.
Google came to the rescue by identifying a similar problem and its solution here. The explanation makes sense.
Basically, Windows adds in the Registry some code for each hardware component it finds. This also applies to the hard drive. After Windows is cloned on another hard drive, on the first start-up it will obviously detect the new hard drive and create another code for it as well. The problem is that, for some reason, this code is corrupted in the Registry, missing the invisible “Null” character at the end of the “Generic volume” text – the code marks the end of the text. Consequently, the new hard disk’s name is crippled, which in turn crashes the Safely Remove Hardware functionality implemented in the hotplug.dll library. So there, we know what’s wrong.
Why does this happen? It’s not clear to me (or even relevant) if it’s a bug within Windows that shows up only in specific circumstances, or if it’s a bug in Acronis TrueImage. Some people say that Acronis is actually inserting the code for the new hard drive into the registry of the Windows installation it’s cloning, but I find that hard to believe.
There are two ways to fix this, depending on your PC Power User skills and desire to assume risks.
The simple way to fix this is to delete the offending disk from Windows’ list of identified hardware components, restart the computer and let the operating system redetect it and add the code correctly. For this, you right-click My Computer and select Properties, then go to the Hardware tab and click the Device Manager button. Alternatively, go in Control Panel and open System. In the Device Manager window, enable Show Hidden Devices option in the View menu, then expand the Storage Volumes section below and find the offending drive there – you’ll recognize it because of the weird characters in its name, instead of Generic volume. The options now are to right-click on it and select Delete, or double-click the volume and click the Update Driver button in Driver tab, let it find a driver automatically, and restart the computer.
The more complicated way (and somewhat more dangerous) is to find the corresponding registry entry for this volume, double-click it to edit it, then just hit OK without making any changes to it. This will force the Registry Editor to add the missing Null character at the end of the text. More specifically, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\STORAGE\Volume\somelongcodehere and edit the DeviceDesc key – it should contain the name Generic volume. Restart the computer after finishing opening all keys for all volumes detected by the system.
Another day, another mistery solved The new laptop is a snappy little fella, and the cloning saved me probably 10 good hours of installing and configuring everything from scratch. Awesome!