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?
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.
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.
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 🙂