VMware Horizon Community
b34ny
Contributor
Contributor
Jump to solution

COM Surrogate (dllhost.exe) spending significant CPU scanning flexhook64.dll

I've been doing a deep dive into Office 365 Activation in non-persistent VDI issues and while looking at processes I've noticed a COM Surrogate process consistently taking up ~33% CPU.  The process will finish, close and then re-open looking at the same file, repeat, repeat, repeat.  This happens on each machine in the pool, needless to say this is a major drain on CPU resources for the hosts.  Any thoughts?

Capture.PNG

1 Solution

Accepted Solutions
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi b34ny,

Is this on Windows 10 v1703? There is a known issue with our DLL injection in certain dllhost.exe processes, and you can use the DirectFlex blacklist feature to address this.

To configure this, create a Blacklist.xml file in the ...\General\FlexRepository\DirectFlex folder (which does not exist by default), with the following content:

<?xml version='1.0' encoding='utf-8'?>

<userEnvironmentSettings>

    <setting type='blacklist' list='dllhost.exe'/>

</userEnvironmentSettings>

If you already have this Blacklist.xml file, just update its list attribute by adding |dllhost.exe at the end of the current value (note the '|' (pipe character), which acts as a separator).

The next release of UEM will address this issue.

View solution in original post

2 Replies
DEMdev
VMware Employee
VMware Employee
Jump to solution

Hi b34ny,

Is this on Windows 10 v1703? There is a known issue with our DLL injection in certain dllhost.exe processes, and you can use the DirectFlex blacklist feature to address this.

To configure this, create a Blacklist.xml file in the ...\General\FlexRepository\DirectFlex folder (which does not exist by default), with the following content:

<?xml version='1.0' encoding='utf-8'?>

<userEnvironmentSettings>

    <setting type='blacklist' list='dllhost.exe'/>

</userEnvironmentSettings>

If you already have this Blacklist.xml file, just update its list attribute by adding |dllhost.exe at the end of the current value (note the '|' (pipe character), which acts as a separator).

The next release of UEM will address this issue.

DEMdev
VMware Employee
VMware Employee
Jump to solution

Just wanted to let everyone know that this bug has been fixed in UEM 9.2.1, which was released a few days ago. If you already configured the Blacklist.xml workaround: that still works fine as well and does not conflict with the fix, so there's no urgent need to remove that workaround after you've upgraded (but I still suggest to do so at some point in time, just for "configuration hygiene" purposes 🙂

0 Kudos