Troubles with Win 8.1 (exclusive to Win8.1)

T-S · Post by **T-S** » Sun Sep 20, 2026 4:42 am

Hi

I recently discovered that there is something wrong that happens, only applying images in compact mode in Win8.1/Win8.1 Embedded.

In short I have all sort of VHD/VHDX compacted in LZX, both for native or virtualized usage.

And practically I never had problems with any flavour of Windows, from Win7 to server 2025.

For my reasons I never used Win 8.1 too much, I have always preferred either to stick to Win8 or to use Win Server 2012R2.

Now I have a newer machine that don't work well with Win 8.0, so I used Win Server 2012R2 (no problems with it), but I also wanted to build a client OS of that era, so I installed Win8.1 Embedded.

The captured and restored LZX image boots (apparently) w/o problems, but if I try to resize the OS partition from its own disk manager, I get a "file not found error".

Also I discovered (after many tests) that in this condition Sysprep fails instantly, I guess for the same reason.

I spent literally a week trying to understand what's wrong.

There isn't any meaningful error in the system logs, there isn't any obvious thing observable using the process monitor.

The only clue comes from the sysprep logs

Code: Select all

BitLocker-Sysprep: Failed to get FVE status for the OS volume. (0x80070002)
[gle=0x00000002]

I did many test, more for curiosity, than for real reasons, given the OS is otherwise perfectly working.

What I collected so far:

1) the problem isn't new: I had old Win 8.1 VMs that are affected, I just didn't notice.

2) The problem happens during the apply phase, not during capture

3) The problem happens even applying for the first time the image from the installation media

4) No other OS is affected, Server 2012R2, Win 8, Win7, Win10, Win11 anything different than Win 8.1

5) The only relevant difference I can think of, is the absence of the original WOF.SYS from 2012R2, just like Win7 and Win8.0, so I tested Win 8.1 with the Wof.sys service removed, but nothing changed.

6) The compression method isn't relevant, the problem appears even using Xpress4k.

I'm short of further ideas, the only option that remains is that winmlib threats 8.1 in a special way a way that breaks something
Also the problem is so subtle that it may have passed under the radars unnoticed, for years

Any idea?