Windows 10 Roaming Profile: Sharing Violation Every 2nd Logon

I came across this problem while preparing my sessions for this year’s conferences. The setup is boringly simple: a user with a roaming profile logging on to a Windows 10 machine. The interesting part: every second time, loading the roaming profile would fail – causing a 35 second logon delay. Every other time, it would work.

When it failed, I would get the following desktop notification:

Looking up the corresponding event in event viewer yields event ID 1521 like the following:

As always, great work on the error message, dear Microsoft developers. It would probably not have hurt to add the file in question!?! In other words: it is certainly nice to know that the error message is

The process cannot access the file because it is being used by another process.

But one – essential – information is missing: which file did the User Profile Service try to access when it got that error?

So I took a boot trace in Sysinternals Process Monitor – once I figured out how you need to tweak it to get that to work. The result was interesting:

As you can see, the User Profile Service tries to open NTUSER.DAT on the profile share and gets back the return code ERROR_SHARING_VIOLATION (which is equivalent to “The process cannot access the file because it is being used by another process.”). Interestingly, that one attempt to open the file takes approximately 35 seconds! What is going on?

Possible Cause

Here is my working theory: it seems, somehow handles to the user profile files and folders on the file server are left open when the machine is rebooted. The roaming profile synchronization at logoff leaks open handles which prevents the roaming profile sync at the subsequent logon from accessing the files. Running the tool openfiles on the file server after rebooting the client shows the following – on every second reboot, when the error happens:

This theory is validated by the fact that you can work around the problem by running the following command on the file server when the client has fully shut down to close the open handles:

openfiles -disconnect -id *

When I closed the handles like that the problem went away – only for the one boot process, of course. It came right back when I stopped closing the handles with openfiles.

What NOT Causes This Error

Among the things I have tried to get this working correctly are:

• Disable Windows Defender by installing a different Antivirus product (Norton Security Deluxe)
• Shut down the machine and turn it on again instead of rebooting.

None of the above helped. If you have additional insight please comment below.

Test Environment

The environment I tested this on was a Windows 10 client (fully patched as of April 2016) accessing file services on a Server 2012 R2 machine (also fully patched as of April 2016).