Windows 11 25H2 SMB Client Directory Cache Regression

- QUERY_DIRECTORY Increased 95x, "dir" ETW Events Dropped to Zero -

Hi SMB Team,

I've identified a significant performance regression in the SMB client on Windows 11 25H2 affecting network file share operations. I have comprehensive data from a controlled comparison between clean installations of 23H2 and 25H2.

Environment

- Two clean-installed PCs (23H2 vs 25H2) connected to the same file server on the same network

- Application: Python-based tool loading .py files from SMB file shares

- Both PCs have identical SMB client configuration defaults for all cache-related parameters

Measured Impact

| Metric | 23H2 | 25H2 | Ratio |

|--------|------|------|-------|

| Application startup time | 26 sec | 80 sec | 3.1x slower |

| Total SMB2 packets | 12,544 | 227,796 | 18.2x |

| QUERY_DIRECTORY packets | 1,128 | 107,382 | 95.2x |

| READ packets | 586 | 570 | ~1.0x (identical workload) |

| PerfMon Metadata Requests/sec (avg) | 87.10 | 1,185.52 | 13.6x |

The READ count is virtually identical (586 vs 570), confirming the actual workload is the same. The 25H2 client is issuing 95x more directory enumeration requests to the server for the same set of files.

Root Cause: ETW "dir" Cache Events Dropped to Zero

I captured ETW traces from the Microsoft-Windows-SMBClient provider on both systems and extracted cache-related events. This is the definitive finding:

| ETW Event Type | 23H2 | 25H2 |

|----------------|------|------|

| file | 151,667 | 185,365 |

| dir | 93,917 | 0 |

| performance | 0 | 106,557 |

On 23H2, the SMB client generated 93,917 "dir" events, indicating active directory cache usage. On 25H2, this event type is completely absent — zero occurrences. A new "performance" event type (106,557 occurrences) appears in 25H2 but does not serve as a cache mechanism.

This indicates that the directory cache code path in the SMB client driver has been removed or disabled in 25H2.

SMB2 Command Breakdown (Wire shark)

| SMB2 Command | ID | 23H2 | 25H2 | Ratio |

|--------------|----|------|------|-------|

| CREATE | 5 | 3,278 | 56,536 | 17.2x |

| CLOSE | 6 | 2,274 | 54,462 | 24.0x |

| READ | 8 | 586 | 570 | 0.97x |

| QUERY_DIRECTORY | 14 | 1,128 | 107,382 | 95.2x |

| QUERY_INFO | 16 | 4,284 | 8,846 | 2.1x |

| IOCTL | 11 | 10 | 0 | — |

| CHANGE_NOTIFY | 15 | 0 | 0 | — |

| Total | | 12,544 | 227,796 | 18.2x |

99.7% of all 25H2 SMB2 traffic is file discovery overhead. Only 0.25% is actual data reads.

Additional Verification: Minimized Search Path (25H2)

I also tested a minimized configuration on 25H2 using explicit path specification to reduce directory traversal:

| Pattern | Startup | Total Packets | QUERY_DIRECTORY |

|---------|---------|---------------|------------------|

| 23H2 default | 26 sec | 12,544 | 1,128 |

| 25H2 minimized paths | 30 sec | 119,153 | 57,888 |

| 25H2 default | 80 sec | 227,796 | 107,382 |

Even with minimized search paths, 25H2 generates 9.5x more packets than 23H2 and the ETW "dir" events remain at zero. This confirms the issue is in the OS driver, not the application.

SMB Client Configuration (Identical Defaults)

All cache-related parameters are identical between 23H2 and 25H2 at clean install:

- DirectoryCacheLifetime: 10 (both)

- DirectoryCacheEntriesMax: 16 (both)

- FileInfoCacheLifetime: 10 (both)

- FileInfoCacheEntriesMax: 64 (both)

- FileNotFoundCacheLifetime: 5 (both)

- FileNotFoundCacheEntriesMax: 128 (both)

I also tested increasing all cache parameters significantly (DirectoryCacheLifetime=60, FileInfoCacheEntriesMax=65536, etc.) with no improvement. Additionally, setting RequireSecuritySignature=False (changed to True by default in 25H2) had no effect.

Affected Driver Versions

| Driver | 23H2 | 25H2 | Size Change |

|--------|------|------|-------------|

| mrxsmb.sys | 10.0.22621.6133 (685 KB) | 10.0.26100.8246 (931 KB) | +35.9% |

| mrxsmb20.sys | 10.0.22621.6133 (333 KB) | 10.0.26100.8115 (390 KB) | +17.2% |

| rdbss.sys | 10.0.22621.6133 (505 KB) | 10.0.26100.8115 (562 KB) | +11.4% |

The 35.9% size increase in mrxsmb.sys suggests substantial implementation changes beyond routine patches.

Questions

1. Is the removal of directory cache events ("dir") in 25H2 an intentional design change or a regression?

2. If intentional, what is the recommended mitigation for applications that perform heavy directory enumeration over SMB?

3. Is there a hotfix or upcoming update that addresses this behavior?

Thank you for your time.