Unclean logoff causing locked files until server reboot RRS feed

  • Question

  • Hello. I setup a new FSLogix environment for a three session hosts RDS farm recently. Cloud cache is being used. Occasionally, when a user logs in, they will receive a user profile failed to attach error, with error code 21.

    An example of how this could happen is -

    1. User logs onto RDS farm, user connects to RDS01.
    2. User logs off.
    3. User logs onto RDS farm again, user connects to RDS02 and receives a profile attachment error.

    When I check the log files under RDS02 C:\ProgramData\FSlogix\Logs\Profile, I found the below every time the user fails to login.

    0001d664][ERROR:00000021]   D:\agent_01_work\2\s\libraries\Frx.ServiceLib\Frx.Service.VHDProfileProvider.cpp(452): Frx.Service.VHDProfileProvider.cpp(452): [WCODE: 0x00000021] Could not acquire an exclusive lock for vhd(x): C:\ProgramData\FSLogix\Proxy\SID_Username\Profile_Username.VHDX (The process cannot access the file because another process has locked a portion of the file.)
    [11:26:28.559][tid:00000eb8.0001d664][INFO]             Configuration Read (DWORD): SOFTWARE\FSLogix\Profiles\PreventLoginWithFailure.  Data: 1
    [11:26:28.560][tid:00000eb8.0001d664][INFO]             Replace shell rule added
    [11:26:28.584][tid:00000eb8.0001d664][ERROR:00000021]   LoadProfile failed.  User: Username. SID: SID. (The process cannot access the file because another process has locked a portion of the file.)

    There are no such VHDX files under C:\ProgramData\FSLogix\Proxy.

    I normally can get the user logged in again by disallowing remote access to all except the original RDS server. So with the above example, I would block off access to RDS02 and RDS03 temporarily and force the user logon to RDS01.

    This looks to me something is blocking a clean log off for this user from RDS01 the first time. This user will not be able to logon to RDS02 and 03 until the next server reboot for RDS01 which clears the locked file.

    Another weird thing is, even with the user logged off, the C:\users\username and C:\users\local_username folders remain there.

    I have already used Process Explorer to check if there is a process locking the VHDX file, but there is none across all locations the file could appear. (these locations are mentioned below in my antivirus exclusions list)

    Antivirus exclusions are in place for the followings on each session host -

    \\fileserver\profiles (where user profiles are stored)
    D:\Cache (write cache directory)

    The environment is working perfectly fine for other users. It is just this once in a while problem for a random user that is causing us frustration. It would be greatly appreciated if anyone can provide any assistance.
    • Edited by N_W_NZ Friday, September 25, 2020 2:56 AM Typing error
    Friday, September 25, 2020 2:41 AM

All replies

  • Hi N_W_NZ,

    Did you already found a solution for this?

    I have exactly the same problem.

    Detaching the VHDX didn't work because (invalid signature-error).

    After that the user cannot mount the VDHX, because it is locked.

    Best regards,

    Joost Lauwen

    Best regards, Joost Lauwen

    Friday, October 2, 2020 10:29 AM
  • Hi,

    Solution below worked for me.

    You must change the security settings of FSLogixContainer-folder. I've added COMPUTER\Administrator as Full Controll to the FSLogixContainer-folder.

    Then you can access the user folder and also dismount the VHDX from Diskmanager. When the users login again, the VHDX will mound again.

    Make sure that the user also has enough permissions to access the VHDX.

    Best regards,

    Joost Lauwen

    Best regards, Joost Lauwen

    Friday, October 2, 2020 11:52 AM
  • Hi Spike-NL,

    Thank you for your solution. I will give that a try next time when this issue happens again.

    Last time when it happened a week ago, I ran Process Explorer and found that the VHDX files on the session host were in use by a system process with PID 4. The user has already logged out, it wasn't listed under users list in task manager and wasn't listed under the collection in connection broker either.

    Further checking into this PID4 process showed that it was smss.exe, which is Windows Session Manager. Honestly have no idea why this would be happening.

    Wednesday, October 7, 2020 1:30 AM
  • Hi Joost,

    Where is your FSLogixContainer-folder stored? We have the same intermittent Loadprofile and  lock issues but ours is stored in Azure. Thank you

    Wednesday, October 7, 2020 2:39 PM
  • We have a similar issue with a customer of ours. It effects only some users, sometimes. If the problem occures and the user logs on to a different RDS Host, there is no problem.

    After a user logoff, the "System" Process (PID 4) locks the following folders:


    The user is completely logged of, according to Task Manager.

    In the FSLogix Profile Log file I can see the following:

    [07:53:55.601][tid:00000c90.0000ce44][ERROR:00000020]   Delete profile failed for sid S-1-5-21-3364776539-3721753400-1968955100-1179, Cleaning up manually. (Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.)
    The last sentence means that the process cannot access the file, because another process already uses it.

    Also the whole "local_username" folder cannot be deleted:

    [08:23:15.479][tid:00000c90.0000bcc4][WARN: 00000005]    Failed to delete C:\Users\local_usename (Zugriff verweigert)
    Access Denied

    Does someone have any info on this behaviour?

    Tuesday, October 13, 2020 2:09 PM
  • Do you use Symantec Endpoint Protection? This was the case with locked credentials folder on our side (RDS 5 different hosts / no Citrix). Just google 

    Endpoint Protection 14 prevents graceful Citrix session logoff

    • Edited by Eelco Akker Wednesday, October 14, 2020 9:39 AM
    Wednesday, October 14, 2020 9:36 AM
  • Looking through the release notes of the latest FSLogix build at

    It looks like these locked file issues will (hopefully) be fixed on the next release.

    Thursday, October 15, 2020 11:49 PM
  • I have about the same issue, but I am redirecting a lot of folders which end up in C:\Users\local_username like it should, only these are sometimes not cleaned up when the user logs off. They can't be deleted manually either.

    Anyway we're using non-persistent images, so after a week the Citrix server is full with local_username folders all taking up space, this fills the cache-drive to the max and the server crashes.

    Funny thing is that this doesn't happen on all Citrix servers, only a few each week. Anyway I'm removing Symantec now, will do a test with Windows Defender since we are switching anyway.

    Friday, October 16, 2020 12:29 PM