SOLVED

Storage service StorSvc in Win 10 multi-session causing high CPU

Brass Contributor

Hello,

 

in AVD host of Windows 10 multi-session that has FSLogix installed, stroage service (StroSvc) sometimes causing very high CPU and it stay like that for few hours.

This also happen immediately when open Storage settings by any user.  

 

I have checked the setting to "Configure Profile Container to roam the Windows Search database" in MS docs Roam the windows search database with Profile Container - FSLogix | Microsoft Docs but this setting is not applicable for Windows 10 multi-session.

 

any advice on how to solve this issue please ?

 

Thanks,

Bachar

9 Replies
I have discovered that the issue is related to FSLofix app masking. when I add .fxa and .fxr files to "C:\Program Files\FSLogix\Apps\Rules". storage service will not be able to calculate the sizes in the user's profile folders and the process will consume high CPU.
Any advice ?
best response confirmed by bacharbader (Brass Contributor)
Solution
I found the problem. it is when using FSLogix app masking. when creating the rules files we should not depend on the automatic scan that the tool does. we need to modify this scan and remove hiding unneeded registry keys.
I'm trying to understand what you've written as a reply as I'm seeing similar issues, this time in Citrix VADS and I'm using both FSLogix Profiles and App Masking. The rules were already created in a reference image. Are you saying that you remove the registry entries that are being hidden by the rule set? Leaving just directories that get hidden by the rule set?
Yes, in the FXLogix app masking rule, I kept only the folders and exe files that I need to hide... no need to hide registry keys or other system files because normal users cannot access or change them anyway.
Hi Bacharbader. Just found this thread as I am experiencing the same issue.
Have you had any re-occurrence since you "simplified" your FSLogix rules?

I am getting the issue on all fresh built AVD's (takes about an hour for the Storage Service to start - then it just ramps up over the next few hours to 100%.

I have gone through all my App Making rules applied to my AVD's and removed all registry values etc, so my rules are now very simple folder structure and Start menu shortcuts etc that get masked.

Everytime I think I have fixed it (with simplified Masking Rules), I build fresh AVD's and it returns. I also find that removing ALL the masking rules, creates an instant fix, and re-applying them - t doesn't return, but clearly this can't be the solution.

Would appreciate to hear if you fully resolved your issue?

Thanks

Nick

@Nick-S not any more. issue is fixed as i mentioned above.

@Nick-S 

I am working through a similar issue in a Citrix non-persistent environment with FSLogix VHD profiles and application masking.  I created a lot of my rules using the rules wizard, but I am unsure which of the 11 rule files is the culprit.  I have to wait until a machine is in 100% CPU state before I can troubleshoot again.  I pulled out a single rule, the one I think is the most messy / complicated (Adobe Acrobat DC), CPU went down, but I need to clean up the rule and test again.

This just happened to me. All 8 cores had 100% cpu from the storage service. What is that service for, anyway? Disabling it didn't seem to affect anything.  We have the app masking too.

@jszabo_98 

 

I narrowed it down to an app masking rule for Adobe Acrobat that was causing the high CPU usage.  I recreated the masking rule on a reference computer with Adobe Acrobat Pro DC and the problem never returned.  I can just speculate that I built the (problematic) rule on an old version, and FSlogix was puking on something.

 

To test - just remove all the rules from the folder - then add one at a time back in and see what happens.

1 best response

Accepted Solutions
best response confirmed by bacharbader (Brass Contributor)
Solution
I found the problem. it is when using FSLogix app masking. when creating the rules files we should not depend on the automatic scan that the tool does. we need to modify this scan and remove hiding unneeded registry keys.

View solution in original post