Forum Discussion
26063 deduplication data corruption is still there.
- Thanks, Joachim. I updated the bug report to note that 26080 is included.
Michael
Build 26080 : Still as easy to reproduce as ever since Server 2022. Without deduplication those VMs update just fine without blue screen and other weirdness.
If there is interest I'll create an 26080 export of the repo from a Server 2019 machine (which should import in Server 2019, Server 2022 and Windows 11 without problems).
- Michael_Bernstein
Microsoft
Thanks, Joachim. I updated the bug report to note that 26080 is included.
MichaelA little update on this: For the first time in many years I had a blue screen on my actual server, which was Server 2019 until mid last year. The first one ever. Bluescreenview from nirsoft lists "ntfs.sys" as culpruit. I unprofessionaly suspect concurrent writes on the deduped volume residing on a tiered mirrored storage space (not S2D). And I unprofessionally suspect that it might be related to the issue with the dedup repo which corrupts data. But only you can tell, not me.
Computer:
i7-4960x, 32 GB RAM (ASRock x79 Fataility). Powersupply a Fujitsu 750 Watt Ex-Primergy.
C: = normal SSD,
😧= Deduped drive. Tiered Storage Space Mirror, 2*SSD, 2*HDD.
E: = Storage Spaces Parity with four drives.
Bitlocker aktive on 😧 and E:
Using NetQoS the speed is limited to 60 MB/s incoming since the tiered storage space cannot write faster. The blue screen happened during three parallel robocopy jobs over network, two of them with 😧 as destination. When the blue screen happened neither a dedupjob, nor a re-tiering job was running according to the event logs. After the crash and the filesystem check I copied linear, not concurrently, on and everything seemed fine.
This is the first ntfs.sys crash I saw anyway since about, maybe, XP SP0?
Here is the dump + the events around that crash.
https://joumxyzptlk.de/tmp/microsoft/NTFS-maybe-dedup-problem-first-server-2022-crash-ever-on-that-computer.7z
MSSWRahmanHi Joachim,
Thank you for sharing the dump. It shows some allocation was corrupted, but since this is a mini-dump it is difficult to debug further.
Do you think you can reproduce the bugcheck issue? If yes, could you please configure a complete dump by setting the reg key below, rebooting the machine, and then reproduce the bugcheck, and then share the dump.
reg add "hklm\SYSTEM\CurrentControlSet\Control\CrashControl" /v CrashDumpEnabled /t reg_dword /d 1 /f
Did you notice event id 55 in system event log in the past when you originally hit the issue? If you can share the following event log files from the repro machine that would be great. %windir%\System32\winevt\Logs\system.evtx
%windir%\System32\winevt\Logs\Microsoft-Windows-Ntfs%4Operational.evtx
In this case the deduped drive (D:) is a Tiered Storage Space Mirror, 2*SSD, 2*HDD. Is this something you configured recently? Asking because in the original report of the issue, this was not mentioned.
We have tried to reproduce the issue internally but have not seen any corruptions. although dedup drive was not a tiered spaces mirror volume.
In your video, the chkdsk output shows cleanup of security descriptor and index files, but that does not indicate corruption. If by chance you have saved the chkdsk output from before, please share that as well.
Thank you.
- Thank you!