Updated: May 9, 2018
Several weeks ago, I decided to test Macrium Reflect, a free system imaging software. Macrium Reflect uses Windows PE as bootable live media, inside which you can perform both backups and restore operations. Now, with system imaging software, testing restores is the most important thing, and I decided to do this both on physical hardware as well as in a virtual machine.
This is where I hit a problem. Trying to boot the PE image in VirtualBox, I got the following error - E_FAIL (0x80004005), with more details available in the VBoxHardening.log file. Inside this file, among many lines of text, I found several hits that read lacks WinVerifyTrust, one of them resulting in the failure below. What now?
Problem in more detail
The particular error code as well as the error attribute are not too telling. We need to look at the created log file to understand better what happened. Specifically, these are the lines that resulted in the failure:
\Device\HarddiskVolume5\Windows\System32\bcrypt.dll [lacks WinVerifyTrust]
13b4.1f40: Error (rc=0):
13b4.1f40: supR3HardenedScreenImage/NtCreateSection: cached rc=Unknown Status -626 (0xfffffd8e) fImage=1 fProtect=0x10 fAccess=0xf cHits=4 \Device\HarddiskVolume5\Windows\System32\bcrypt.dll
What we see here is that this specific library (bcrypt.dll) fails the WinVerifyTrust check. Do note that there might be other objects that fail this check but not fatally. Indeed, with this information, we can see that there's indeed a ticket on this issue, as well as a long forum discussion.
Essentially, this is probably caused by a mismatch in certificates that Windows provides, as part of the PE image, and those that VirtualBox has, in the current build. The error is triggered by security hardening introduced in this virtualization product.
There are several ways around this. You can revert to an earlier Windows build for your virtual machine - in this case, use a different, older Windows 10 PE image as a baseline for the rescue media for instance, or for most people, just a different version of the operating system. Alternatively, you can change (upgrade) the VirtualBox edition. The latter is usually a cheaper, faster workaround than messing with the operating system. The best way would be to toggle hardening flags off, but that does not seem possible in any trivial way.
And so, although it may sound like Hello Capt. Obvious, what are you doing here, the solution is to try to update VirtualBox to the latest edition, if possible. In my testing on several hosts, moving from the 5.1.X branch to the 5.2.X branch resolved this issue for Windows 10 based virtual machines.
As a techie, you probably get angry when support people tell you to update your software to the latest version. Sometimes though, like in this case, it's the fastest and most sensible way to work around this problem. Security hardening in VirtualBox introduces various complications, and it will always be the game of cat and mouse between Microsoft and Oracle. Occasionally, some libraries may not load, causing your VMs to stop working.
However, the technical bits are less important here - what matters is that you know how to approach this issue in a systematic manner. First, carefully examine the error code, then read the error logs. Once you find the culprit, you will also be able to ask the right questions and find the right solutions. In this case, it's the matter of a program update, but we do that with the full understanding of what went wrong. I hope you find this little guide useful, for all your current and future VirtualBox snags.