SMB Client Behavior (Windows)

We do quite a bit with the SMB protocol at work, and occasionally we uncover little things that have haunted us for weeks or months. Before I jump into the interesting stuff, I want to explain what I mean by client behavior.

Client behavior is just what it sounds like. It is the behavior exhibited by a client using your application, server, service, etc. This cannot be controlled in any way since you have no presence on the system beyond the application or service used by the client. Most of the time this isn't an issue, but occasionally presents itself as a problem to solve form the server/application side.

During testing, we found that a Windows client that we used for mounting SMB shares would cache the share connection information even after the share was disconnected using something like 'net use /d.' But how did we figure this out? While getting a packet capture, we mounted a share to the Windows client, disconnected it, and then reconnected a few minutes later. The session information for the multiple mapping attempts were the same. After looking into it more, it turns out that a Windows client's Explorer.exe process will cache the connection information when shares are mapped. We have not been able to figure out when this cache is cleared, but since we use automation to perform testing, we can't afford to wait minutes or hours for the cache to clear to ensure new session information.

So, after a few talks about 'client behavior' I found a method of preventing this kind of 'convenience' from impeding our testing efforts. I present to you, the fix:

taskkill /IM explorer.exe /F; explorer.exe

Killing explorer?! Absolutely. Running this inside powershell took less than a second on the test machine and solved the unique problem.