Sun

The gap is real and recoverable, and the reason is that two layers disagree about what "free" means.

The .vhdx is a virtual disk that grows on demand. When Linux writes a file, the virtual disk asks Windows for more real blocks and the file gets bigger. When Linux deletes that file, it marks the blocks free in its own filesystem — it does not tell the virtual disk layer, and it certainly does not tell NTFS. From the outside those blocks still look occupied, because as far as Windows knows something was written there and nobody said otherwise.

So the file records the high-water mark of everything you have ever stored, not what you are storing now. Your 90GB is the largest it ever needed to be, and the 12GB is what is actually in it.

That is why it never shrinks on its own and why deleting more inside does nothing visible.

Yes, same problem, seen from two sides. The hardware virtualisation extensions can be claimed by exactly one hypervisor at a time, and something already has them.

That something is almost certainly Hyper-V, which WSL requires. Once the Hyper-V hypervisor is running, it owns the extensions and everything else has to go through it rather than touching the hardware directly. VirtualBox's classic engine wants the hardware itself, cannot have it, and reports that it cannot enter VMX root mode.

Your Task Manager check is consistent with this rather than contradicting it: it says the firmware setting is on, not that it is available to the caller.

So the two errors are one condition. What is confusing is that yours is failing in both directions, which suggests the hypervisor is in a half-configured state — enabled enough to take the extensions, not enough to actually create a VM.