BES Client and TrustedInstaller spikes on Win2008R2?

Hi All,

We only have a few hundred Windows 2008 servers left in our fleet, however we have an “issue” common across all of them where it appears the BES Client is initiating the TrustedInstaller.exe process which then consumes 100% of the CPU for about 5 minutes. This appears to be happening once every hour, and does not occur if we stop the BES Client.

I’m guessing the BES Client is initiating this to process patch relevance. Just wondering if anyone knew of anyway to lessen this impact or have any other tips on what can be done here? I tried using WSRM to limit the CPU usage for the TrustedInstaller.exe process, however it appears to ignore the limits and just do whatever it wants.

I’ve compared some Perfrmon data with BES debug logs and it looks as though every time TrustedInstaller is spiking CPU there are a bunch of entries checking for pending restarts that refer to IsAnyRestartPending() . Just looks like it is checking a bunch of registry keys however.

Does anyone know if and why this would be potentially invoking TrustedInstaller?

I don’t know whether that’s invoking TrustedInstaller, but I doubt it (else we’d all be seeing issues with it).

There are definitely some things in Relevance you could do that impact system performance / invoke TrustedInstaller. I’d point at this thread for an example of how a WMI query can cause MSInstaller to execute repeatedly due to a WMI query for the Win32_Product class Windows event viewer id 1035

I’d suggest using Sysinternals’ Procmon ( to see whether you can identify the fixlet/analysis (.fxf file) that BESClient is referencing just prior to the TrustedInstaller activity. You may find that a custom fixlet/task/Analysis is triggering some TrustedInstaller activity. The most likely way for that to happen would be a WMI query, as there aren’t many other ways for the BESClient to trigger another process on the system outside of running an Action.

Here’s another reference, it looks like a WMI query for “Win32_QuickFixEngineering” may launch TrustedInstaller.

Armed with that knowledge, you could reference the first thread I posted for a Session Relevance method to query the fixlets/tasks/analyses and search for Win32_QuickFixEngineering.

1 Like

Thanks all, looks like it was due to Win32_QuickFixEngineering being used. Have removed / disabled all content referring to this class and TrustedInstaller no longer spikes the CPU.