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:

User Profile Service - There was a problem with your roaming profile. You've been signed in with your previously saved local profile.

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

Roaming profile error 1521 in event viewer

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:

Roaming profile boot trace

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:

Openfiles output on the file server

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).

16 Responses to Windows 10 Roaming Profile: Sharing Violation Every 2nd Logon

  1. James Rankin April 14, 2016 at 13:26 #

    Hi Helge

    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.

    Cheers,

    JR

    • Helge Klein April 14, 2016 at 15:02 #

      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.

      • James Rankin April 14, 2016 at 15:15 #

        Unfortunate…I am doing some more testing on roaming profiles this week, will see if I can recreate and offer any insights.

        Cheers,

        JR

        • Constantin Lorenz June 15, 2016 at 15:19 #

          Any news to this Bug?

  2. Jörg von der Ohe April 15, 2016 at 07:51 #

    Give the following FixIT a try:
    https://support.microsoft.com/en-us/kb/3144319

  3. Paul April 15, 2016 at 21:23 #

    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.

  4. didi April 28, 2016 at 12:35 #

    We do have the same issue on Windows 7 Clients and updates April installed.
    The Problem started right after installing April patches.

    Did you anyone find a solution yet?
    Thanks for the article!! So at least it’s not only me facing this Problem.

  5. GG May 10, 2016 at 22:33 #

    Can also confirm, fresh WS2012R2 fully patched, along with Windows 10 fully patched as of May 2016. Only happens after reboot and fast re-login.

  6. GG May 10, 2016 at 22:40 #

    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.

  7. Thilo August 9, 2016 at 08:27 #

    Are there news with build 1607 for roaming profile victims?

  8. Mike September 12, 2016 at 21:57 #

    Hi,

    i had the same error using a synology nas but i found a solution by disabling “Opportunistic Locks” in the advanced settings for windows shares. for windows itself theres a registry key.

    https://bromelkamp.com/resources/Opportunistic%20Locking.pdf

    Hope it will help you

  9. Tina B. September 28, 2016 at 18:45 #

    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.

  10. James Rankin October 10, 2016 at 19:38 #

    Hi Helge

    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.

    Are you still seeing the issue today?

    Cheers,

    JR

  11. Bill November 10, 2016 at 14:24 #

    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.

  12. Andreas Hagendorf February 18, 2017 at 19:32 #

    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.

  13. Martin February 21, 2017 at 20:27 #

    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.

    Need a resolution to this!

Leave a Reply