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 *

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.

Did you try this with the April 12 updates installed? Looks like there’s a fix of sorts which deals with hooks into the profile after the user has logged off. I can confirm mandatory profiles now work OK whereas they didn’t previously.

Thanks for the info, James. I had disabled automatic updates in order to test with a consistent state, so the April 12 updates had not been installed. However, I have installed those updates including KB3147458 now and the problem is still there.

Interesting article and an issue that we have faced ourselves (and still do) on Windows 7 (no fix as Win7 is too old now).

We can reproduce the issue and concluded that it was due to SMB2 opportunistic locking behaviour timeout and SMB2 design

Reproduction:
This issue can be reproduced if we restart workstation and login in quick succession ( user has roaming profile). For example if we capturing 5 iterations for boot trace with Windows performance toolkit.

Delay was happening because svchost.exe was not able to acquire lock on ntuser.dat on the server for profile merge for every alternate logon.

We were not able to rename ntuser.dat on filer for every second logon ( from different machine)

Previous handles on ntuser.dat are not getting close on first reboot. This is probably due to smb2 design which enables the filer to maintain a handle active for certain duration if the connection to client is lost. On the second logon, when svchost.exe is trying to acquire lock, the filer is sending the client an oplock break notification but no response from client. 35 sec is default timeout for oplock break notification. This value matches what we have seen in event vwr , procmon, netmon trace.

Unfortunately, we have not tried Win 10 yet, but I suspect the same exists given the nature of the issue.

Also, I noticed issues with Roaming Profiles – Windows store app would crash upon launch for any user with roaming profile. Only error in Event Log was lots of the following, doesn’t seem to even reference the store app.

Activation of application Microsoft.WindowsPhone_8wekyb3d8bbwe!CompanionApp.App failed with error: The specified module could not be found. See the Microsoft-Windows-TWinUI/Operational log for additional information.

The fix…

Change shared folder: \\fs01\RoamingProfiles$ to \\fs01\Users$ and it works. I suspect it’s a folder path length issue with the store app in AppData. Worked as soon as either roaming profiles disabled or folder name changed (permissions same).

Windows 10 seems to have a number of odd issues with Roaming Profiles, but all we can do is keep testing the updates I guess.

We are faced with the same issue. We connect to terminal servers (RD Client – Windows Server 2012 R2) with roaming profiles. We have a handful of users where their profile does not unload, leaving hundreds of files opened. To the user, their session logs off just fine, but, when you look at the fileserver where their roaming profile is saved, there are hundreds of files left opened. When these files do not close, and the user logs in the next day, they get the dreaded temporary profile. I have been working with Microsoft on this and they are making me jump through hoops, i.e., uninstall anti-virus on all my terminal servers and fileserver. I already performed a clean-boot on all my servers, tested, and got the same outcome. They are aware of the issue but have not found a fix. This issue started when we implemented Windows Server 2012 R2. Everything worked fine on Windows Server 2008.

There has been a fix of sorts for roaming profile issues in the latest fully patched builds from MS, assuming you don’t use the “Delete cached copies of roaming profiles” GPO (although this may well be fixed now too)

I’ve also observed file lock issues using User Profile Disks, in the interests of completeness.

Any resolution for this yet? I have the same problem but I don’t know if my problem is that I am running the profiles on a DFS share or if this is more of a client side issue. I have tried deleting the local profile with no luck.

Still having this issue with fully patches Server 2016 (state Feb. 18.2017) and using GPO for folder redirection and roaming profiles to a dfs share. If I reboot the server, the first login of the user is ok, at second login the user gets an temp profile.

I’ve come to light of this issue today after it’s started appearing. I can confirm it’s still a bug in a fully updated Windows 10 install. If files are left open on the roaming profile server, but if the session (with the files) are closed the user logs in fine.

We’ve been struggling with this issue for a couple of years now despite keeping both the Windows 10 clients and servers running Windows Server 2012 R2 up-to-date and fully patched. The issue appears to primarily impact users who immediately log on after restarting their computers. We recently noticed an interesting coincidence which might be contributing to the problem. In nearly all cases, users affected by this issue will get a pop-up warning them that Windows could not reconnect all network drives. The curious thing about that message was that Windows appeared to reconnect one more of those drives, but not the full contents of those drives. It turns out that Windows was attempting to cache those drives locally which I suspect was wrecking havoc with the user profile loading/unloading process. All of our clients are using roaming profiles in conjunction with folder redirection so it’s not that we didn’t want to use offline files, just that Windows was attempting to cache files that were not part of the user’s redirected folders. We reviewed all of shares on the respective servers and deselected the option to allow caching on all of the shares we did not want users to cache locally. This is particularly important for the share holding the users’ roaming profiles. (We never allowed users to cache the profiles share, but the default setting is to allow caching.) After reviewing the shares on the server, we then ran a “sync all” on each user’s workstation to ensure that the content of their redirected folders was in sync with the server, then set the FormatDatabase flag under HKLM\System\CurrentControlSet\Services\CSC\Parameters and restarted each user’s workstation to reset the offline folders database. All of this was done to ensure that only the user’s redirected folders would be cached locally and that Windows would no longer cache the user’s profile or recently accessed drives.

Hello I know what caused the problem, it is the service of the windows firewall. In the gpo you must aktivi the Setting the user’s self-declaration is not necessarily unloaded activated, microsoft recommends this setting but so far I have no disadvantages can recognize