Forum Discussion
Nested-V Dedup corruption 26100.1742 and Insider 26296.5001 (and Server 2022) is still there.
MicrosoftHello Joachim_Otahal
I have a few clarification questions.
While configuring dedup on 😧 of L1 guest, did you use VDI profile?
And did you set "deduplicate file older than" to 0 days?
On L1 Hyper-V, when you import the L2 VMs, what import type option did you use?
We have not been able to repro the issue internally with the VDI profile on either WS2022 or WS2025 as the L1 OS.
Given that it is reliably reproducible for you, could you please do the following?
a) enable full dump on both the L2 guest VMs by running:
reg add "hklm\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t reg_dword /d 1 /f
b) Do the repro. If you can, save the output of chkdsk C: /f or chkdsk C: /scan run on the L2 guest VMs
c) Share the system.evtx, Application.evtx and Microsoft-Windows-Ntfs%4Operational.evtx from the L2 guest VMs. They are under C:\windows\system32\winevt\Logs folder.
d) Run the command: fsutil repair enumerate C: on both the L2 guest VMs and share the output.
e) Share the system.evtx, Application.evtx and Microsoft-Windows-Ntfs%4Operational.evtx from the L1 guest VM
f) If either of the L2 VMs bluescreen, please share the dump.
Greatly appreciate your input in figuring out this issue.
Thanks
Thank you for your reply!
Which profile: Does not matter, happens with all three (as described in previous. postings..).
"Deduplicacte older than 0 days" is only needed if the L2 VMs are fresh set up, before starting any Windows Update. If you import existing VMs without starting them, which have not been touched for > 3 days, you don't need "0 days".
How to import the L2 VMs: Attach the VHDX, open Hyper-V GUI, import "register directly". Exactly as in the video.
As for sharing the crashed: I will follow your additional preparation instructions, and then provide you with the complete VM package "right before dedup", "right before the final repo step", and "after L2 VMs died", which includes the L1 OS and the (crashed) L2 VMs. Host will be Win11 24h2, Ryzen 5950x, ECC RAM, which is important since the L2 VMs does not work on Intel hosts in my tests unless you deactivate and reactivate Hyper-V in the L1 guest.
Do you have a special request regarding what OS the 1st or 2nd level guests have to be? Else I'll use "Server 2025 with updates" for L1 guest, and "Server 2012 R2 German and English" for L2 since the latter are already there.
regards,
Joachim Otahal
- MSSWRahmanThank you for the clarifications, Joachim.
Please use VDI profile because that is the recommended one in this scenario. For the L1 guest please use server 2025, because that is where dedup is being enabled. For the L2 guest, feel free to use server 2012. I guess L2 could be any OS; I was using server 2022.
Also, my attempts have been on Intel hosts so far. I will try your tip of deactivating and reactivating Hyper-V in the L1 guest (before starting the dedup job i guess).- MSSWRahmanJust one more thing. You may be knowing this already, but when you enable full dump on the L2 guests, please check that pagefile is enabled on C: and is big enough to accommodate the RAM size on those VMs.
After you get the repro, do share the logs mentioned in points c), d), e) and f) of my initial post.
ThanksI 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.7zThe 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 ISOinto recovery "repair computer" "cmd.exe" mode.