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

25 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!

  14. John Colton April 18, 2017 at 21:02 #

    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.

    So far this fix appears to be working, although only time will tell.

  15. sven May 5, 2017 at 09:02 #

    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

    • John Colton June 5, 2017 at 17:36 #

      @Sven – Can you provide more specifics about your solution? I looked for the group policy setting you mentioned, but wasn’t able to find it.

    • hangloose72 June 19, 2017 at 07:43 #

      Hi Sven
      have you more information about this? Which GPO Setting you mean?

      • sven June 23, 2017 at 08:01 #

        Hi,

        in englisch called the gpo:

        do not forcefully unload the users registry at user logoff

        you find it under computer configuration, administrative templates, system, user profiles :)

        • Alex July 19, 2017 at 09:07 #

          HI!

          Is sven solution work for someone?

          R.
          A.

          • Johan Pronk November 14, 2017 at 09:43 #

            I have the setting enabled, but unfortunately it didn’t solve the problem.

  16. Alex June 14, 2017 at 15:50 #

    Hi there.

    We have the same problem, i want to ask you John Colton everything working well in your workaround?

    o7

  17. Didi June 22, 2017 at 13:05 #

    Hi there

    We still got the same Problem aswell so i would be interested aswell in Svens solution.
    Could you be more specific about the gpo Setting?

    greets
    Didi

Leave a Reply to Jörg von der Ohe Click here to cancel reply.