After moving client machines from Windows 11 23H2 to 24H2—and still reproducing the problem on 25H2—mapped SMB drives can cause Explorer and browser downloads to hang for roughly 1–3 minutes. A browser download may sit at 100%, Explorer stops refreshing directory contents, newly created files do not appear until a manual refresh, and SMB copy operations stop updating. Closing the SMB Explorer window sometimes helps, while restarting explorer.exe resolves the problem consistently.
WPR traces show Explorer waiting on directory notifications for about 61–62 seconds: explorer.exe DirNotify operations end with 0xc0000120, while the SMB path reports STATUS_IO_TIMEOUT (0xc00000b5) for approximately the same duration. Setting NoRemoteChangeNotify=1 prevents the hangs, but it also disables automatic refresh for mapped SMB folders.
The clients use SMB 3.1.1, require signing and encryption, and have SessionTimeout set to 60 seconds. The environment also recently adopted CIS SMB policies. Could the 60-second session timeout, a change-notify problem on the file server, SMB security settings, caching, or Explorer process behavior introduced in 24H2 be responsible?
3 Answers
For testing, compare the SMB security and timeout settings rather than changing everything permanently. Check RequireSecuritySignature, EnableSecuritySignature, RequireEncryption, and SessionTimeout, then test one change at a time. You can also temporarily lower the directory, file-info, and missing-file cache lifetimes. Disconnect and remap the drives between tests so existing SMB sessions do not hide the result. Separately, enabling Explorer's “Launch folder windows in a separate process” option may isolate Explorer from file-dialog or endpoint-security interference.
Did the separate Explorer process option help with any SentinelOne-related Explorer problems? We also use that endpoint-security product and I am curious whether it can affect these file operations.
The error combination is consistent with ReadDirectoryChangesW waiting on an SMB directory handle and eventually being canceled after the I/O timeout. A browser's common file dialog or file-completion operation can involve Explorer, so it is plausible that the browser exposes the problem without being the underlying cause. Testing Explorer in a separate process is worthwhile, but the server or an intermediate network device should still be investigated because the directory-notification request is the operation that actually stalls.
The matching 60-second durations strongly suggest a long-lived CHANGE_NOTIFY request is not being answered by the file server, filer, firewall, or load balancer before the client gives up. I would capture traffic and WPR data while reproducing it, comparing the server-side behavior before and after the timeout. NoRemoteChangeNotify is a valid workaround, but it works by preventing Explorer from registering the notification in the first place, which explains the loss of automatic refresh.
Disabling RequireEncryption did not resolve it, although signing settings and the cache lifetimes still need testing. I also plan to investigate SessionTimeout, even though the issue can occur immediately after opening the mapped folder.