04 Apr 2021 - tsp
Last update 04 Apr 2021
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.
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
hive) the machine might crash during boot just raising an
error. This is in many cases caused by a damaged hive file in the system
configuration contained in
\Windows\system32\config\. Currently there are
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
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
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:
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.
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
chkdsk that’s required to get the system up and running.
If nothing works it’s a good idea to first try the usual
commands that one knows might help (adjust the
c: - which is my boot
partition - and
d: - which is my system partition - paths according to
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 (
sel vol N,
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
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
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
HKEY_LOCAL_MACHINE node and then execute the
command selecting the specific file inside
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
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.
In any other case the next step is to get the files of the machine. I personally
ftp tool to do this. First one has to disable the firewall:
Then one can launch
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
On FreeBSD it’s available in the
security/regripper package and easily
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
The next step is re-importing. Again I used the
ftp utility to copy data
back onto the windows machine
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
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
directly under the
Software2 key. Now I deleted all child keys contained
inside this substructure. The last step before importing was to edit the
software.reg and replace all
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
Just to note that again: Life is really way easier with a solid and well designed
Unixoid operating system such as FreeBSD,
or even Android …
This article is tagged:
Dipl.-Ing. Thomas Spielauer, Wien (firstname.lastname@example.org)
This webpage is also available via TOR at http://rh6v563nt2dnxd5h2vhhqkudmyvjaevgiv77c62xflas52d5omtkxuid.onion/