Windows 10 recovery from damaged registry hive files

Disclaimer: The steps described in this article do not reflect how Microsoft has thought on should use their operating system. You should make a backup - really. One usually does such stuff only in case the alternative would be total loss of the given machine or in case on wants to play around a little. So as usual: Make backups. And if you haven’t had some up until now learn your lesson. And in the best case just switch to a more user friendly and robust system such as FreeBSD or Linux.

Disclaimer 2: This article might be loaded with a decent amount of sarcasm since it emerged late at night after many hours of getting a single machine back up running by an author that already had a somewhat negative bias towards this operating system.

What’s this article about?

So we all know this situation - you have a Windows machine that makes troubles - again. And as usual there is no easy way to recover from an error so the usual suggestion is just reinstall it or move back to a system restore point. But what specific problem is this blog post about?

In case you have a damaged registry hive file (in my case it has been the SOFTWARE hive) the machine might crash during boot just raising an BAD_SYSTEM_CONFIG_INFO error. This is in many cases caused by a damaged hive file in the system configuration contained in \Windows\system32\config\. Currently there are

• COMPONENTS (HKEY_LOCAL_MACHINE\COMPONENTS)
• DEFAULT (HKEY_USERS\.DEFAULT)
• DRIVERS
• ELAM
• SAM (HKEY_LOCAL_MACHINE\SAM)
• SECURITY (HKEY_LOCAL_MACHINE\SECURITY)
• SOFTWARE (HKEY_LOCAL_MACHINE\SOFTWARE)
• SYSTEM (HKEY_LOCAL_MACHINE\SYSTEM)
• Different NTUSER.dat files (HKEY_USERS sub hierarchies)

These correspond to the different registry subkeys as mentions above. Back in the days up to early Windows 10 versions Windows made a periodic backup of the registry into the RegBack folder to allow easy recovery - I have to say I wouldn’t really call this recovery since copying an old version might lead to data loss but it was an easy solution - from such errors. This has been disabled to reduce the disk footprint of Windows even more but can be re-enabled by setting a registry key at HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager\EnablePeriodicBackup to DWORD:1 anyways but as usual you discover such changes when it’s too late. The currently encouraged method to restore the system is to use a system restore point and roll back the configuration of the machine to a previous known state. Unfortunately there was no such point present on the machine I had the problem on. Also utilities such as dism do not work when they’re unable to gain access to the registry.

So I had to use another approach:

• Boot from a recovery disk
• Copy the hive file to another machine
• Use a forensic tool to dump all readable content of the hive file (as it turned out there was nothing unreadable) into a reg file
• Copy that dump back to the damaged machine
• Create an empty hive file using a simple hack
• Import the reg file from within the Windows RE environment

Just took about a day to get to this solution - on any other decent operating system one could’ve just copied a set of the base executable over the existing system and continue running in a few minutes or rewrite the few damaged configuration files - but not so for windows, but that’s what one’s used to on user friendly windows.

How to gain access

First one has to gain access to the current machine. Since there is no way to get something like a boot loader prompt or a shell in case the system configuration store isn’t readable one has to use the installation medium. Since this is not shipped currently on has to download the Windows 10 ISO, burn it on a double layer DVD and finally boot from this disk.

Then one can simply select computer repair options on the installation menu and is ready to go. It’s a good idea to let auto repair try to repair the current Windows installation though since sometimes there are some really basic problems like a damaged BCD or some invalid references inside the boot configuration - or a simple chkdsk that’s required to get the system up and running.

If nothing works it’s a good idea to first try the usual sfc and dism commands that one knows might help (adjust the c: - which is my boot partition - and d: - which is my system partition - paths according to your system):

sfc /offbootdir=c:\ /offwindir=d:\ /scannow

One might also try to fix the MBR, the bootsector and the BCD. In this case I assume that the EFI partition has been assigned the drive letter F by using the usual diskpart commands (list vol, sel vol N, assign letter=F)

bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bcdboot d:\windows /f ALL /s F:

Now one might also use dism to restore system files. This utility usually should be used with active internet connectivity since it tries to fetch components from the windows update site. One might also add a different source but that’s way more cumbersome than simply specifying the path of the installation disk (one usually has to have a wim or esd file such as the one contained on custom created recovery disks - if one has done this instead of using a generic installation medium one can supply the location using the /Source:x:\sources\install.wim parameter). I personally don’t know how to get a wim file at a later stage for a system one hasn’t built a recovery disk for.

dism /Image:d:\ /Cleanup-Image /CheckHealth /ScratchDir:d:\scratch\
dism /Image:d:\ /Cleanup-Image /ScanHealth /ScratchDir:d:\scratch\
dism /Image:d:\ /Cleanup-Image /RestoreHealth /ScratchDir:d:\scratch\

So that’s all pretty well known and basic stuff - now what’s this blog post about? Basically it might happen that dism fails with an error 1009 and complain inside it’s log that a registry hive could not be loaded. It’s a good idea to verify this by trying to import the hive file inside regedit - simply select your HKEY_LOCAL_MACHINE node and then execute the Load structure command selecting the specific file inside \Windows\system32\config\ and specifying any name such as TEST. If it gets loaded correctly your problem is a different one. In case the load fails it’s exactly what this short article is about.

First try to restore a periodic backup

In any case - first check if the RegBack folder only contains 0 byte files. If this is the case you’ve got bad luck. In case files are actually present, have a size larger than zero and are somewhat recent it’s a good idea to simply try to copy them into the config parent folder and try a reboot. Many times this solves the problem.

Extracting hive content

In any other case the next step is to get the files of the machine. I personally used the ftp tool to do this. First one has to disable the firewall:

wpeutil DisableFirewall

Then one can launch ftp

open 192.0.2.1
binary
put SOFTWARE
quit

This allowed me to upload the current hive file onto a different (FreeBSD) machine.

To extract hive content I used some forensic tools - in this case the RegRipper. On FreeBSD it’s available in the security/regripper package and easily installable using pkg install regripper. This suite is a collection of tools that’s usually used during forensic investigations on Windows machines - it allows to search for information inside copied hive files, allows one to dump information and pretty efficiently look for specific data. Basically all I did was to use regexport.pl ~/SOFTWARE -r to dump the information from the hive into the ASCII registry format.

regexport.pl ~/SOFTWARE -r > software.reg

If everything works out this should provide a pretty complete dump of the registry content of the given hive - in my case of HKEY_LOCAL_MACHINE\Software.

Re-importing

The next step is re-importing. Again I used the ftp utility to copy data back onto the windows machine

open 192.0.2.1
get software.reg
quit

The last step was to import the data back into the local registry. Since direct access is not possible and the hive file is still inaccessible I just copied the SOFTWARE hive from the Windows RE environment

copy x:\windows\system32\config\SOFTWARE d:\windows\system32\config\

Then I started regedit and added this as substructure into HKEY_LOCAL_MACHINE directly under the Software2 key. Now I deleted all child keys contained inside this substructure. The last step before importing was to edit the ASCII dump software.reg and replace all HKEY_LOCAL_MACHINE\Software occurrences with HKEY_LOCAL_MACHINE\Software2. Then I simply ran the import function from regedit to load the dump again.

After that a final reboot turned out to work somewhat - after the known hours long black boot screen period that chkdsk triggered anyways (another one of the really user friendly status message hiding features since it seems to be way more intuitive to stare on a black screen for multiple hours than to actually see a message about the current progress of any error checking and recovery operation …). At least tools like dism now worked as before.

Note: Note that of course this removes any security information attached to the registry keys.

As it turned out the system required another run of

dism /Image:d: /Cleanup-image /RestoreHealth /ScratchDir:d:\scratch\

Which now leads to the end of this blog article but not to the end of the recovery of the machine (since DISM now complained with the well known 0x800f081f). Just to note that again: Life is really way easier with a solid and well designed Unixoid operating system such as FreeBSD, Linux, Solaris or even Android …

This article is tagged:

• Computer
• Windows
• Administration