Intermittent STATUS_SHARING_VIOLATION enumerating immutable layer on Windows Server 2025

[bugale]

Describe the bug

Concurrent, read-only recursive enumeration of a directory in an immutable
Windows container image layer intermittently returns native
0xC0000043 (STATUS_SHARING_VIOLATION) in a process-isolated Windows Server
2025 container.

The reproducer uses an official Microsoft .NET Windows Server Core image. It
builds a target tree and an unrelated pressure tree into the image, starts a
fresh container, releases 128 synchronized MSBuild wildcard expansions while
64 workers perform copy-on-write activity only in the separate pressure tree,
and checks every expansion. No process writes to or intentionally holds the
enumeration target.

This is not specific to .winmd files. The public reproducer enumerates
ordinary .dat files and has failed on several generated target directories.
MSBuild catches each enumeration exception and returns the literal wildcard,
which is the downstream symptom.

The default .NET 8 command reproduced on 4/4 independent affected Windows
Server 2025 hosts. First failures occurred in fresh-container attempts 8, 4, 1,
and 5: 4 failed containers out of 18 started, and 4 successful reproductions
out of 4 default ten-attempt invocations. The failed waves returned the literal
wildcard in 509/512 independent expansions.

The .NET 10 form reproduced on its first fresh container. One untraced run
failed all 128 expansions with 254 logged System.IO.IOException sharing
violations. A later traced first container failed 24/128 expansions and
captured the corresponding native operations.

To Reproduce

1. Use an elevated PowerShell prompt on a Windows Server 2025 host capable of
   running process-isolated Windows containers.
2. Clone the standalone public reproducer and run:

git clone https://github.com/bugale/wcifs-sharing-violation-repro.git
cd wcifs-sharing-violation-repro
pwsh .\run-public-barrier.ps1 `
  -BaseImage mcr.microsoft.com/dotnet/sdk:10.0-windowsservercore-ltsc2025

The script prints host OS, wcifs.sys, Docker, image, and workload details. It
builds the derived image and tries up to ten fresh containers. A hit prints the
individual MSBuild failures and preserves diagnostic logs/binlogs under the
reported temporary directory.

Reproduction source:
bugale/wcifs-sharing-violation-repro.
The original source archive is wcifs-public-repro-17913341f5.zip, 17,087
bytes, SHA-256
7CE528E2E8ACB15DF61F7CF212DD81B3A369083FB0E0EE10C7E81F9BE01C7561.

Expected behavior

Every read-only wildcard expansion should enumerate all 256 target files. An
unrelated copy-up in another image-layer path should not make a share-all open
of the immutable target fail with STATUS_SHARING_VIOLATION.

Configuration:

• Edition: Windows Server 2025 Datacenter, host build 26100.32995
• Host wcifs.sys: 10.0.26100.32995
• Isolation: process
• Base image:
  mcr.microsoft.com/dotnet/sdk:10.0-windowsservercore-ltsc2025
• Reproducing image digest:
  sha256:a00e1eefeec928a583a388a39fe726853ae96118c8e7cca11e017501c83064be
• Container image OS metadata: 10.0.26100.33158
• Container SDK/runtime/MSBuild: 10.0.302 / 10.0.10 / 18.6.11
• Container engine: Docker
• Container engine version: client/server 24.0.7

Additional context

The failed native trace correlated 24 target-tree FileIO/OperationEnd events
to their originating creates:

• All 24 returned 0xC0000043 (STATUS_SHARING_VIOLATION).
• All 24 opened
  \Device\VhdHardDisk{...}\wcifs-target\contract-0134 with
  OPEN_EXISTING and ShareAccess=ReadWrite, Delete.
• The 24 operations originated in 24 distinct dotnet processes and completed
  between 2026-07-16T23:32:12.8465047Z and
  2026-07-16T23:32:12.9427440Z.
• All 24 stacks contain fileinfo.sys and fltmgr.sys; 16/24 contain
  wcifs.sys in the originating-create and completion stack.
• The same iteration contains 24 matching managed System.IO.IOException
  records, 24 literal-wildcard errors, and failures from all four parent
  MSBuild processes.

A representative captured stack segment is:

ntoskrnl
fileinfo.sys
fltmgr.sys
wcifs.sys
fltmgr.sys
ntoskrnl
ntdll
kernelbase
System.Threading.Tasks.Parallel
System.Private.CoreLib
CoreCLR

Evidence attachment:
wcifs-public-native-evidence.zip,
207,044 bytes, SHA-256
83029E67ABA6A3891D1E9A847F038F4E9F12F558BD418AB71DA06628A6083F4F.
It contains the native FileIO export and stacks, four MSBuild diagnostic logs
and binlogs, the container log, and sanitized host metadata.

This proves the failed native status, target path, requested permissive share
mode, and wcifs.sys participation in 16 failed samples. It does not prove
that wcifs.sys created the conflicting handle. The traced host did not have
xperf/Windows Performance Toolkit installed, so the compact evidence does not
include authoritative Minifilter callback decoding.

Changing only the container base image does not fix this on the affected host:
the reproducing .NET 10 image already has container OS metadata for July build
26100.33158, while process isolation continues to use the host kernel and
wcifs.sys build 26100.32995. Hyper-V isolation passed local controls but is
not available on the affected virtualized host class because nested
virtualization is unavailable. MSBuild also has no switch for serializing only
its internal recursive-glob Parallel.ForEach.

Questions:

1. Can the container layer path temporarily create an incompatible handle for
   an immutable directory while another path is being copied up?
2. Do the failed stacks match a known race in wcifs directory merge,
   first-touch, or copy-up handling?
3. Is this fixed in a later Windows Server 2025 cumulative update, including
   July 2026 KB5099536/build 26100.33158, or is there another supported generic
   host/container configuration that avoids it?
4. Would Microsoft prefer the raw Minifilter ETL, or a new capture from a host
   with Windows Performance Toolkit, to identify the conflicting handle or
   failed callback?

[github-actions]

Thank you for creating an Issue. Please note that GitHub is not an official channel for Microsoft support requests. To create an official support request, please open a ticket here. Microsoft and the GitHub Community strive to provide a best effort in answering questions and supporting Issues on GitHub.