none
Explorer.exe High CPU with redirected Desktop folder RRS feed

  • Pertanyaan

  • Hi!

    Have anyone else experienced this behavior in Windows 10?

    We have a VDI environment based around VMware Horizon 7.9 with Windows 10 LTSB (build 1607).
    Desktop and Home folders are redirected to the non-persistend VDI during logon. On some occations, we see that Explorer.exe and Services.exe is using around 100 % of the virtual CPU right after logon and this last until the user logs off. If you start Process Explorer/Monitor you see a series of non stop queries for files and registry items for Explorer.exe. It's like this searching for something.

    If you then proceed to clean up your Desktop, eg. move folders/files to your home folder, then this stops. Now, we could send emails to users and make them clean up the Desktop folder, but this is also a very strange behavior if you ask me.

    Does anyone know why this is an issue and if Microsoft has a KB about it? I could not find anything about it.

    Kind regards
    Kjell

    Senin, 05 Agustus 2019 12.37

Jawaban

  • Hi,

    Microsoft identified the issue, it is related to a missing registry key:

    Quote from Microsoft:
    "These problems occur when there is no CLSID key under the HKEY_USERS\{USER SID}_Classes key.
    A CLSID is a globally unique identifier that identifies a COM class object. If your server or container allows linking to its embedded objects, you need to register a CLSID for each supported class of objects. 
    The CLSID is a 128-bit number, in hex, within a pair of curly braces.
    The high CPU usage / desktop refresh is caused by explorer's Registry Watcher functionality, which is added in explorer starting from Windows 10.  Previous versions of Windows do not have this problem."

    I've implemented a simple script to create this key during logon for our users in Powershell:

    Add-Type -AssemblyName System.DirectoryServices.AccountManagement
    $Path = "Registry::HKEY_USERS\{0}_Classes" -f ([System.DirectoryServices.AccountManagement.UserPrincipal]::Current).SID
    if (-not(Test-Path -Path $Path\CLSID))
    {
        New-Item -Path $Path -Name CLSID
    }

    Hope that helps anyone else experiencing this issue!

    Kind regards
    Kjell





    • Ditandai sebagai Jawaban oleh Kpropell Jumat, 16 Agustus 2019 11.21
    • Diedit oleh Kpropell Jumat, 16 Agustus 2019 11.42
    Jumat, 16 Agustus 2019 11.19

Semua Balasan

  • Hi,

    This is a quick note to let you know that I am currently performing research on this issue and will get back to you as soon as possible. I appreciate your patience.<o:p></o:p>

    If you have any updates during this process, please feel free to let me know.

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Selasa, 06 Agustus 2019 09.56
    Moderator
  • Hi,

    May I ask more information about your current situation?

    Have you tried another user or a new VDI?

    Please also use Performance Monitor to check the CPU utilization in the VDI. We can refer to this blog, 

    https://www.windowscentral.com/how-use-performance-monitor-windows-10

    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.

    Hope this helps. 

    If you have any question or concern, please feel free to let me know.

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Rabu, 07 Agustus 2019 07.33
    Moderator
  • Hi Michael!

    The issue is still present. I see around 20-30 VDI's with critical CPU usage warnings in vCenter each day with ~1500 users logging in and out. Users get's a random VDI when they log in, and the VDI is refreshed at logoff.

    When I do a check on the VDI to see what processes are using CPU, it is explorer.exe and services.exe. If you kill explorer.exe, the vCPU usage goes down from around 4,5 GHz to 1,* GHz. Start Explorer.exe again and the vCPU goes up again.

    I had this issue also and spent lots of time with Process Monitor and Process Explorer trying to figure out what Explorer.exe and Services.exe was doing. All I could see was an endless queries for files all over the drive, and endless queries in the registry. 

    One of my colleagues found a forumpost (that he can't seem to find again for some reason) that Explorer.exe uses high CPU when you have a broken shortcut or some files without extentions on your Desktop. So I moved all my files and folders on my Desktop to my Home folder and then the issue was gone.

    I am trying to reproduce the issue while I search for a good candidate to troubleshoot with (the affected users seems to be using Desktop as My Documents, I want to find one with less on the Desktop). Sadly I renamed many of my folders because I also had more than 255 characters in one folder. That could also have been a factor.

    Kind regards
    Kjell

    Rabu, 07 Agustus 2019 08.29
  • Hi,

    I've managed to reproduce the issue.

    1. Create one folder on the Desktop
    2. Create 10 text files in this folder
    3. Copy this folder to the Desktop 10 times, so that you have 11 folders each with 10 text files.
    4. Explorer will start to constantly use CPU:

    To make it stop, I remove one folder at a time until you see Explorer stop using CPU:

    Really strange!

    Edit:
    I've also managed to reproduce it on a Windows 10 LTSC 2019 VDI (Windows build 1809, fully patched). I had to enter one of the folders first to make it trigger.

    Kind regards
    Kjell




    • Diedit oleh Kpropell Kamis, 08 Agustus 2019 09.59
    Kamis, 08 Agustus 2019 09.53
  • Hi,

    Thanks for your update.

    We can create dump file for Explorer.exe in the task manager as below. 

    Furthermore, I suspect when you redirect to homefolder which locates in the root directory of the OS, it will consume less resource like CPU, Memory. But if redirect to multi-layers folder, it will consume more resources like your condition.

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Jumat, 09 Agustus 2019 10.12
    Moderator
  • Hi Micheal,

    I have a dump file, was it so that you would like to analyze it? Where would the best place be to upload it?

    Kind regards
    Kjell

    Jumat, 09 Agustus 2019 11.02
  • Hi,

    Thanks for your update.

    Unfortunately, I'm sorry to notify that debugging the crash dump files is beyond what we can do in the forum. We can only provide some general suggestions here. 
    If the issue still occurs, a support call to our product service team is needed for the debugging service. We'd like to recommend that you contact Microsoft Customer Support Service (CSS) for assistance so that this problem can be resolved efficiently. To obtain the phone numbers for specific technology request please take a look at the web site listed below:

    https://support.microsoft.com/en-us/gp/customer-service-phone-numbers  

    Highly appreciate your effort and time. If you have any question or concern, please feel free to let me know.

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Selasa, 13 Agustus 2019 08.56
    Moderator
  • Hi,

    I have requested a support case from Microsoft today and will post the solution if they can fix it.

    Thank you for the help so far!

    Kind regards
    Kjell

    Selasa, 13 Agustus 2019 12.04
  • Hi,

    Thanks for your update.

    I'll stand by with you, if you have any update or concern, please feel free to post here.

    Have a nice day!

    Best regards,

    Michael


    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Rabu, 14 Agustus 2019 02.52
    Moderator
  • Hi,

    Microsoft identified the issue, it is related to a missing registry key:

    Quote from Microsoft:
    "These problems occur when there is no CLSID key under the HKEY_USERS\{USER SID}_Classes key.
    A CLSID is a globally unique identifier that identifies a COM class object. If your server or container allows linking to its embedded objects, you need to register a CLSID for each supported class of objects. 
    The CLSID is a 128-bit number, in hex, within a pair of curly braces.
    The high CPU usage / desktop refresh is caused by explorer's Registry Watcher functionality, which is added in explorer starting from Windows 10.  Previous versions of Windows do not have this problem."

    I've implemented a simple script to create this key during logon for our users in Powershell:

    Add-Type -AssemblyName System.DirectoryServices.AccountManagement
    $Path = "Registry::HKEY_USERS\{0}_Classes" -f ([System.DirectoryServices.AccountManagement.UserPrincipal]::Current).SID
    if (-not(Test-Path -Path $Path\CLSID))
    {
        New-Item -Path $Path -Name CLSID
    }

    Hope that helps anyone else experiencing this issue!

    Kind regards
    Kjell





    • Ditandai sebagai Jawaban oleh Kpropell Jumat, 16 Agustus 2019 11.21
    • Diedit oleh Kpropell Jumat, 16 Agustus 2019 11.42
    Jumat, 16 Agustus 2019 11.19
  • Excellent find. Thank you for sharing. I was having the same problem on a number of our VDI pools (thought not all), and found that indeed the desktops having this problem were missing this key. Your script has been most helpful.
    Rabu, 18 September 2019 18.36
  • I appreciate the fix posted, but does anyone know what the root cause is that's not allowing the CLSID to be created as it normally would?  It appears to affect VDI environments and not physical desktops.  Scripts are great for quick fixes, but is this something that will always require a script to get around?

    One thing I'll note is that I use the VMWare optimization tool (we use Horizon for our VDI). What I'm noticing about that tool is that a number of default items in the Windows 10 profile that get disabled actually degrade performance in the desktops.  There was another key that was set as "deny" that caused very long delays in the start menu opening.  Another vmware post pointed out that we shouldn't be applying that specific optimization and once I removed it the start menu worked perfectly.

    So I don't know if this particular issue is also caused by the optimization tool as I haven't done testing for this yet.  But it would be nice to know what might be causing the issue to begin with so a script isn't necessary. If anyone has any idea or more insight on this issue that would be great.

    Kamis, 17 Oktober 2019 10.57