If you’re a normal sort of Linux user, when you buy a laptop you probably keep that Microsoft OS partition around, shrinking it to a minimal size and allowing it to coexist with Linux just in case you need it for firmware updates, special Windows-only tools for special situations, or sometimes just for an A/B comparison if you suspect something might be wrong with the Linux driver for a particular device.
So, after not booting that Windows Vista partition for a few years, and possibly having gone through a few disk upgrades and associated disk imaging in the meantime, you try to boot it up only to find:
- It doesn’t boot via the automatically populated GRUB entry, hanging at a black screen
- It doesn’t boot via Hiren’s Boot CD or another tool booting the Vista partition directly, with a
winload.exe“missing or corrupt” BSOD - Third-party software upgrades don’t work
- Windows Update doesn’t work
- Anything you try to install manually doesn’t work
ARGH!!
Well, here’s how you should be able to fix that mess (steps tested on Windows Vista Home Premium OEM 32-bit SP1).
The Vista partition won’t boot even with a third-party loader, and all I did was clone the disk
Well, turns out that’s a no-no with Vista. The result is a very common refrain:
File: \Windows\system32\winload.exe
Status: 0xC0000225
Info: the selected entry could not be loaded because the application might be missing or corrupt.TLDR for this situation where you only have the one OEM Windows Vista (or later OS using BOOTMGR, but only Vista seems to suffer from this problem) partition on your Linux laptop: Boot into Hiren’s Mini XP, then figure out what drive letter your Windows partition is mounted at, then assuming it’s X: with the default %systemroot%:
X:\windows\system32\bcdedit /store X:\boot\bcd /set {default} osdevice boot
X:\windows\system32\bcdedit /store X:\boot\bcd /set {default} device boot
X:\windows\system32\bcdedit /store X:\boot\bcd /set {bootmgr} device boot
X:\windows\system32\bcdedit /store X:\boot\bcd /set {memdiag} device bootOkay, but it still won’t boot. All I get is a black screen and blinking cursor.
Now that the BCD store has been repaired, we need to figure out how to get the Boot Manager itself (BOOTMGR) loaded. A Windows partition boot record should load BOOTMGR, but if it’s moved around on disk it may not be able to find it. So we need to reinstall the partition boot record to make sure everything is lined up.
Fortunately, there’s a handy tool to do just that called bootrec.exe. Unfortunately, it’s only available on a “recovery disc” that you create in a working Windows installation, or on an original Windows installation media, which you likely don’t have for an OEM installation of Windows.
Furthermore, even if we were able to boot Vista, it turns out that the program recdisc.exe that creates the “recovery disc” was broken in the final release of SP1 and all subsequent releases, even though a beta SP1 version of the same program works correctly!
Grubbing around for a solution
So let’s remove the partition boot record from the picture momentarily and see if Windows will boot.
GRUB is installed in the MBR (Master Boot Record), so before booting the (generally automatically generated) Windows entry, let’s edit it as in this post:
insmod part_msdos
insmod ntfs
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 6060682360680260
chainloader +1becomes
insmod part_msdos
insmod ntfs
insmod ntldr
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 6060682360680260
ntldr ($root)/bootmgr(Of course, ensure the $root variable is left at what is correct for your system.)
The effect of this is to load BOOTMGR directly instead of implicitly via the partition boot record. Combined with the BCD store fix above, this should now work and load Windows Vista. From there, it should be relatively straightforward to repair the partition boot record using bootrec.exe, either via the (F8 at bootup) Recovery Console, or via a “recovery disc” after applying the aforementioned workaround to allow its creation and obtaining the correct OEM Vista installation disc from whatever source.
Software upgrades, Windows Update, and installers don’t work!
If you’re getting errors like 0xC8000022, 0x8000ffff, or 0x8000247 when attempting to install Service Pack 2, various updates, or anything that uses the Windows Installer or Windows Update framework really, you’ve entered a very specific world of pain. Obviously, the Extensible Storage Engine is at fault.
Wait, that wasn’t obvious?
Well, okay, I get why it’s not obvious, since it could also be the Intel Matrix Storage Manager at fault.
Still not obvious?
Okay, okay. This is one of those very special situations that we have both Microsoft and Intel to thank for. So, newer hard disk drives threw somewhat of a wrench into the works by migrating to 4KB sectors from the traditional 512-byte sectors, gaining theoretical performance and storage density. However, performance problems arose both in the pursuit of compatibility and as a result of legacy disk layout tools making inefficient geometric decisions.
However, when confronted with an Advanced Format (4KB sectored) disk drive, both Microsoft and Intel have done something quite special. When the Extensible Storage Engine library is not confused enough already, the drivers included with Intel’s Matrix Storage Manager manage to make things even worse.
The special situation works like this:
- You’ve imaged your Vista partition to a new, Advanced Format disk, and thrown away the creaky old disk.
- Now you realize you cannot install or upgrade anything.
- The fix is to apply a hotfix for the Extensible Storage Engine that replaces
%systemroot%\system32\esent.dllwith version 6.0.6002.22531 dated 23-Nov-2010. - However, you cannot apply this hotfix because, like everything else, it will not install in the presence of a buggy version of itself.
- You can extract the files from the installer manually (described below) and shove them into place manually, overriding Windows’ system file integrity model.
- Then you can install Vista SP2.
- … if you’re lucky. You may still have problems. If you do, uninstall the Intel Matrix Storage Manager as well as its accompanying drivers following a procedure like this. (This may degrade disk performance somewhat, but ‘working’ is a better state of affairs.) Then you install Vista SP2.
- Afterwards, you realize you cannot install or upgrade anything.
- That’s because SP2 replaced
esent.dllwith yet another buggy version! - If you were sane, you delete your Windows partition and wonder why you ever bothered…
So, I have an installer framework that won’t upgrade because the current version of the same installer framework is buggy. What to do?
First, download the Fix333336 hotfix from the above link (or attached here: esent-vista-x86 for 32-bit Vista). Then, open a command window in administrator mode and follow these steps to extract the esent.dll you need from it:
expand -F:* Windows6.0-KB2553708-x86.msu
expand -F:* Windows6.0-KB2553708-x86.cabThe file will be in one of the many subfolders created by the second step. Then, you can follow the same procedure as in repairing the program that creates a “recovery disc” to replace esent.dll with the new version.
After rebooting, your problems should be history and you can get back to computing like it’s 2009!
I’m still having problems with Windows Update
Psst… If you’re sure you’ve solved the above problems and it’s just a squirrelly problem with Windows Update itself, WSUS Offline Update might help. But the last version that worked with Vista was 19.03.2017 Version 10.9.2. Good luck!
Vista sucks! It’s full of bugs and all my favorite software is out of date.
Among the biggest problems:
- Device driver updates generally stopped around 2009, so newer hardware is not supported and existing bugs and feature gaps are not fixed.
- Internet Explorer 9 (2011) is the last version available for Vista.
- Chrome 49.0.2623.110 (2016) is the last version available for Vista.
- Firefox 52.9.0esr (2018) is the last version available for Vista.
A Windows 7 in-place upgrade can be performed using Microsoft tools. Just sayin’.