Forum Discussion
Nested-V Dedup corruption 26100.1742 and Insider 26296.5001 (and Server 2022) is still there.
After you get the repro, do share the logs mentioned in points c), d), e) and f) of my initial post.
Thanks
I redid it fresh.
Host is Windows 11 24H2, Ryzen 5950x ECC RAM. L1 VM fresh Server 26100.2033, and the two L2 VMs fresh too, though I accidently used build 26296 there :D. The L2 guest VMs are identical, the second is a clone of the first.
One big difference: Instead of running Windows Update a powershell script "Server2025-and-Server2022-dedup-corruption-repo-test.ps1", used in the L2 guests, is enough to trigger it. Script is at https://github.com/Joachim-Otahal/PowerShell . Has a little menu, create a 4 GB file, modify it, check whether the CRC is the expected value. In some cases running Step 1 in one of the L2 VMs alone is enough o crash both, on other cases the "step 1, step 2, step 3" had to be repeated a few times in both L2 VMs.
There is no memory.DMP, it did not seem to survive the chkdsk.exe run. Even cmd.exe, dir c:\*.dmp /b /s /a shows no .DMP file anywhere.
The chkdsk output and events of L2 guests, as far as I could capture them:
https://joumxyzptlk.de/tmp/microsoft/Server2025-dedup-corruption-Events-CHKDSK-etc.7z
The whole package, L1 guest and the L2 guests BEFORE activating deduplication. I had it on the second D : 😧 SSD, not the boot SSD. (Can anybody tell me how to turn of that over-eager auto smiley stuff? Feels like over-eager MS office autocorrect, correcting even when turned off...)
https://joumxyzptlk.de/tmp/microsoft/Server2025-dedup-corruption-BEFORE-actviating-dedup.7z
The whole package, L1 guest and the L2 guests AFTER they crashed, which should include "everything".
https://joumxyzptlk.de/tmp/microsoft/Server2025-dedup-corruption-AFTER-the-crash.7z
If you import those in Server 2025 or Windows 11 24H2 on an Intel machine: You may have to deactivate and reactivate Hyper-V on the L1 guest, else it may not work. There seems to be some differences on that regard, which are only taken into account when activating Hyper-V.
The culprit, from my point of view, is still the L1 guest, either Server 2022 or Server 2025, not the host OS below or the second level guests. Using Server 2019 as L1 guest with the nested VMs inside works fine, whether the real hardware host is Server 2019, Windows 10, Server 2022, Windows 11 or Server 2025 does not make a difference.
If I could get access to .ISOs from vNext between Server 2019 and Server 2022 I could narrow it down at bit when that bug was introduced.
For the "fun": A few screenshots.
This last one is with the chkdsk run in both VMs when booted from Server 2022 ISO into recovery "repair computer" "cmd.exe" mode.