MSEndpointMgr
Home » Remote Desktop » FSLogix slow sign-in (fix) redux

FSLogix slow sign-in (fix) redux

FSLogix slow sign-in caused by the App Readiness service can be fixed without workarounds. In this post you will learn what goes on with this service during any Windows login.

Debugging FSLogix slow sign-in issues can be a stern reminder of just how many things interact with each other during the Windows login sequence. Most of the time, it might not even be FSLogix that’s at fault – or at least not entirely, which you can read about in this post where we must once again fix the OS and not FSLogix (*Psst* it’s all about App Readiness this time).

If you missed the previous post that this one extends, then do yourself a solid, and check it out in case you are going mad googling through all sorts of solutions: FSLogix slow sign-in (fix)

The problem

Imagine running a large RDSH farm, either on-prem or using Azure Virtual Desktop (formerly Windows Virtual Desktop). Now, imagine that all your users have to wait several minutes the first time and perhaps each subsequent login. And all they have to look at is a black screen with a cursor, no progress indicators; add to that, once the desktop finally renders, the CPU is tied up for several minutes!

This black screen during sign-in is NOT the best way to start your users day.

This is what I had to deal with recently. And since solutions were nowhere to be found, I decided that sharing the cause and resolution with you good folks reading this blog was my duty to the community.

The cause

The internet is overflowing with issues surrounding this phenomenon in both persistent and non-persistent VDI/RDS environments. It is not even isolated to Windows servers because the culprit is actually the App Readiness Service, which is responsible for initializing the user profile with, among other things, AppX packages.

Q: How do you know it is the App Readiness service?

A: I used the awesome ProcMon: Process Monitor – Windows Sysinternals

Anyway, the App Readiness service is required for any modern desktop or multi-session host, so please don’t just take for granted that you can disable this service, and all your problems disappear (even though it might seem so).

The App Readiness service

As I said, this service is important, and without it, Windows Update will not work properly, your AppX packages will start to vanish, and rot will set into the deepest corners of Windows.

App Readiness Service
App Readiness Service

But this post is not about why you should have the service enabled. It is more of why it might be slowing you down, especially with FSLogix in the mix.

You see, the FSLogix container, and others like it, seem to insist on re-enumerating the AppX installations. So, basically, reinstalling them each time a user signs in to their desktop.

Normally the process is cached by the AppX Deployment Service. And should only happen once in a while for a regular user profile. So you might dismiss even doing anything about such an intermittent slow sign-in issue.

AppX Deployment Service

From the learnings in the previous blog post, we know that FSLogix does not do too well if too many things need to be enumerated/evaluated etc., during the sign-in.

The reason App Readiness is especially hard on FSLogix sign-ins

As it turns out, the App Readiness service will actually start the AppXsvc, which will then do the work with the AppX packages needed in the user’s profile. And this, in turn, kicks the StateRepository service into gears, which is where things might start to go really bad.

What is this StateRepository service, you say? Well, there is not a whole lot of information about it online. For this blog post, all you need to know is that it’s a service that on the backend operates an SQLite database that stores information about all the AppX packages. And it is the same file/database for all users!

State Repository Service

The database file is located in “%SystemDrive%\ProgramData\Microsoft\Windows\AppRepository”. If you want to take a look, you can open up an elevated prompt and run the following commands.

cd %SystemDrive%\ProgramData\Microsoft\Windows\AppRepository
dir state*

Now imagine that this database grew too large, and the system had to work with that database for each user sign-in. That could, at some point, cause fatigue of system resources.

The StateRepository database size

Now, if you have a single environment, you might not notice that this database had become too large because “what is the normal size anyway?”.

Let’s see about the output from the command I showed you in the previous section…

StateRepository service files that App Readiness gets bogged down by
StateRepository files

The screenshot above is from my Windows 11 computer with a bunch more AppX packages than your average RDS Farms. As you can see, the files are only a few MB in size.

I have not been able to find a document that states what the normal size is. So let’s see what the size is on a server that is suffering from FSLogix slow logon with a black screen:

FSLogix slow sign-in caused by bloated StateRepository database used by App Readiness
StateRepository files on a Remote Desktop Session Host server

Quite a difference, right? Poor server! Having to process this database file simultaneously for several user logins. Mornings must be hell…

Q: Why did this happen?

A: I don’t know.

Q: So, do we dare delete this?

A: Sure we do!

Since the StateRepository service will automatically recreate a new database at startup.

We have backups of our servers/workstations (right?).

The script to fix the StateRepository database bloat

So, since there is good reason to believe this action has to be done on several servers. I wrote a quick script to delete the StateRepository database (which could be locked by services). You can fetch a copy from my GitHub repository here:

invoke-StateRepositoryReset.ps1 (github.com)

In short, this script will attempt to stop the associated services and delete all the StateRepository database files.

This bit of PowerShell is a straightforward version of the script. You should use the full version from the GitHub repo.

Get-Service -Name StateRepository | Stop-Service -Force
Get-Service -Name AppReadiness | Stop-Service -Force
del C:\ProgramData\Microsoft\Windows\AppRepository\StateRepository*
Get-Service -Name StateRepository | Start-Service

After having completed the database reset, FSLogix slow sign-in should be a thing of the past. That is, unless you are running your farm on a dumpster with spinning disks, then nobody can save you.

Conclusion

StateRepository bloat/corruption is bad for FSLogix, Mmmkay?

Please bear in mind that this knowledge is shared for learning purposes only. So, do your own tests etc., before deploying this fix into production environments.

Respect each other out there – we can get through this – we are meaningless without each other.

(2775)

Michael Mardahl

Michael works as a Microsoft Certified Cloud Architect with APENTO in Denmark. He specializes in customer journeys from classic Infrastructure to Cloud consumption with a strong focus on security. And has been working in the IT industry for more than 20 years, where he started as a Network Administrator in the logistics industry. He has gained experience through a broad range of IT projects throughout the years and was very early to embrace and share his cloud technology passion. When not at work, Michael enjoys the value of spending time with family and friends and BLOG's passionately about Microsoft cloud technology whenever he has time to spare - this has earned him the title of Microsoft Most Valuable Professional (MVP) in the Enterprise Mobility category.

8 comments

  • Out of interest what is the state of your AppReadines Service – Manual/Automatic? In my case, it is this service that eliminates the black screen if disabled but I cannot do this as it introduces lots of other issues.

    • Everything is at default.
      You need the app readiness service unfortunately.
      I have hear word that the FSLogix team will look into this along with the app readiness team. so hopefully one day…

  • Hi Michael, I have applied this fix and if anything the black screen appears to be longer. Will do more testing but so far no gain on windows 10 20h2. Will come back to you soon.

    • In my case it was on a server and not a windows client. so you might also have other issues. there are many things that relate to the black screen.
      Modern Apps from the store being one of them, so if you have something else that is interfering with the deployment of those, that could also cause the black screen with a cursor.

  • Hi Michael,
    Trying you script but getting access denied on delete
    del : Cannot remove item
    C:\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Deployment.srd: Access to the path
    ‘C:\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Deployment.srd’ is denied.
    At C:\bhpinstall\invoke-StateRepositoryReset.ps1:46 char:5
    + del C:\ProgramData\Microsoft\Windows\AppRepository\StateRepositor …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : PermissionDenied: (C:\ProgramData\…-Deployment.srd:FileInfo) [Remove-
    Item], UnauthorizedAccessException

  • This is fantastic work, Michael! Thanks for sharing. With the amount of Black Screen posts on the web, this is the best!

Sponsors

Subscribe

Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories

MSEndpointMgr.com use cookies to ensure that we give you the best experience on our website.