Forum Discussion
0x139 in wcifs!WcRemoveInMemoryTombstoneAfterRenameLink on Server 2019 RDS hosts with new Teams
We run a Remote Desktop Services farm on Windows Server 2019 (build 17763.9376, October 2026 cumulative update) with local user profiles (no FSLogix) and the new Teams client (MSIX). Since late October 2026 the session hosts bugcheck with KERNEL_SECURITY_CHECK_FAILURE (0x139), parameter 1 = 3 (LIST_ENTRY corruption, double remove). Four crashes in two weeks, on three different hosts, with a different user each time.
Stack, identical in the two complete kernel dumps we have:
nt!KeBugCheckEx
nt!RtlRemoveEntryHashTable
wcifs!WcRemoveInMemoryTombstoneAfterRenameLink+0x2d8
wcifs!WcPostSetInformation
FLTMGR!...
Ntfs!NtfsCommonSetInformation (status c0000022)
FLTMGR!FltCompletePendedPreOperation
cldflt!HsmiInfoRenameNotificationCallback
cldflt!HsmFltPreSetRenameInformation
nt!NtSetInformationFile (from user mode)
- Process: ms-teams.exe, MSTeams 26288.2003.5258.9616.
- Operation: IRP_MJ_SET_INFORMATION, FileRenameInformationEx, Flags = 0x5 (REPLACE_IF_EXISTS | SUPPRESS_PIN_STATE_INHERITANCE).
- Target: %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Local\Microsoft\OneAuth\accounts\<guid>, renamed onto itself, in a local user profile.
- No third-party filter driver in the stack. !analyze buckets one dump as MEMORY_CORRUPTION_LARGE, but that comes from !chkimg differences in nt (normal runtime patching), not real corruption.
Our reading: Teams renames the OneAuth account entry onto itself, cldflt pends the operation, and when it completes wcifs removes its in-memory tombstone twice.
One more data point: the only host in the farm running Windows Server 2022 (build 20348.5761, with FSLogix profile containers) has had the same Teams builds and has not crashed. All crashes are on Server 2019. It differs in both OS and profile type, so we cannot tell which one matters.
Questions:
- Is this wcifs/cldflt double remove a known issue, and is a fix planned for Windows Server 2019?
- Has anyone else seen 0x139 with this stack on Server 2019 RDS hosts?
We can share the dumps privately with Microsoft.
1 Reply
Your repeated stack is useful escalation evidence, but 0x139 parameter 1=3 establishes LIST_ENTRY corruption, not necessarily where that corruption originated. Microsoft notes that detection can occur after the damaging operation. I could not find a published Microsoft notice matching this wcifs/cldflt signature or a Server 2019 fix date, so I cannot confirm it as a known defect or promise a patch. Open a Windows Server support case and provide the kernel dumps privately, exact OS/Teams versions, crash times and your cross-host comparison. Ask support to correlate the affected list entries and filter state rather than treating the process name as proof of cause. There is also a support boundary: Teams’ current VDI guidance lists Server 2019 support ending October 2025 and Server 2022 ending October 2026, recommending migration to Server 2025. Pilot a supported configuration with controlled variables; the existing Server 2022/FSLogix comparison changes two variables and cannot isolate either.
