04 Apr 2021 - tsp
Last update 04 Apr 2021
9 mins
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 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
HKEY_LOCAL_MACHINE\COMPONENTS
)HKEY_USERS\.DEFAULT
)HKEY_LOCAL_MACHINE\SAM
)HKEY_LOCAL_MACHINE\SECURITY
)HKEY_LOCAL_MACHINE\SOFTWARE
)HKEY_LOCAL_MACHINE\SYSTEM
)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:
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
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.
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
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
.
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:
Dipl.-Ing. Thomas Spielauer, Wien (webcomplains389t48957@tspi.at)
This webpage is also available via TOR at http://coihcmhmb6cg6bvtelykwlte45yqhxkl6ffdoco5kc3a4qn3uno53oqd.onion/