I was troubleshooting a user's VPN connection when I noticed that File Explorer had been crashing repeatedly over the previous few days. The system reported a LiveKernelEvent 0x1CC, EXRESOURCE_TIMEOUT_LIVEDUMP, indicating that a kernel ERESOURCE had been contended for longer than the configured 45-second timeout.
The dump's failure bucket points to mrxsmb!SmbCeWaitForCompletionAndFinalizeExchangeEx, with the stack passing through mrxsmb20, CSC, RDBSS, MUP, and File Explorer's directory-query path. The affected system is running Windows 10 build 10.0.26100 under Hyper-V. Since mrxsmb.sys is involved in SMB networking, I'm wondering whether this points to a faulty network driver, a stalled VPN connection, or an inaccessible network share. Could the dump explain both the VPN symptoms and Explorer crashes, and is there any worthwhile troubleshooting beyond rebuilding the machine?
3 Answers
This is a live kernel dump rather than a normal system crash. It says a kernel resource had been heavily contended for 45 seconds, and the waiting thread was handling an SMB directory query. That can result from a disconnected VPN, an unavailable file server, a broken cached network path, or third-party software such as a file-system filter.
I would check whether Explorer was browsing a mapped drive or UNC path when it stopped responding, review SMB and VPN client logs, test the machine with the VPN and mapped shares disconnected, and update or remove any third-party network or file-system filter drivers. Also verify that Windows and the VPN client are fully patched. The dump does not provide enough evidence to call this a hardware failure.
If this is one user's machine and you have limited time, rebuilding it is a reasonable operational decision, especially if the symptoms are widespread or the device has other unexplained instability. Before doing that, preserve the dump and event logs and record whether disconnecting the VPN or removing mapped drives stops the Explorer crashes.
Randomly replacing drivers based only on the module named in a dump can send you down the wrong path. If the issue returns after a rebuild, then investigate VPN software, SMB access, offline files, shell extensions, and file-system filter drivers rather than assuming the Microsoft SMB component is the root cause.
The stack is showing a wait timeout in the SMB client while it is enumerating a directory on a remote share. In plain terms, Explorer asked Windows to list files on a network location, and the SMB operation got stuck waiting for a response or resource. The presence of mrxsmb.sys identifies the subsystem handling the request; it does not by itself prove that mrxsmb.sys or a network driver is defective.
Given the VPN problem, the most likely relationship is that the VPN or remote share became unreachable or stalled. Explorer may then appear to crash or hang because it is synchronously waiting on that network operation. The dump alone probably cannot identify the exact share without deeper SMB debugging and additional context.
That matches what I was seeing. I suspected the dump was more of a symptom of the connectivity problem than proof of a bad driver, but I wanted to understand what the stack was actually telling me.
That is probably the practical answer here. I was mainly using the incident as a chance to learn how to interpret these dumps, but there is not enough time to debug the kernel path extensively on a single workstation.