Alan_S

Computer sluggish at startup - TrustedInstaller seems to be involved

Recommended Posts

For a long time I've noticed that, on start-up, both my computers are very sluggish for the first minute or two.  Investigation points to EAM startup:  The sluggishness doesn't occur if “Start on Windows startup” is disabled, but then does on starting EAM manually.  The 'culprit' appears to be TrustedInstaller.exe running on EAM starting.  I investigated this morning using Process Explorer, Task Manager and a stopwatch and got the following:

09:13:20 TrustedInstaller started.
09:15:00 TrustedInstaller ended its chore (i.e. no cpu being used)
09:26:00 (about) TrustedInstaller terminated
Task Manager reported that TrustedInstaller used 40 sec CPU.

It has nothing to do with EAM updating as I've turned off auto update.
Naturally, I've run a Malware Scan and nothing was detected.

Of course, my question is whether this is normal or not.

And if it is normal, what is TrustedInstaller installing?

OS is Windows 7 Pro, 32 bit
 

Share this post


Link to post
Share on other sites

I'm not aware of any need for TrustedInstaller to run on startup (at least not for EAM). Can you try monitoring with Process Hacker and let me know what the parent process for TrustedInstaller is?

Share this post


Link to post
Share on other sites

The parent is services.exe, which has parent wininit.exe.

That doesn't sound as if it is coming from EAM, at least not directly. But the fact remains that it only runs when EAM is started, either manually or on Windows start-up.

I'm not familiar with Process Hacker but I documented screenshots.  I also had debug logging turned on - perhaps that can shed some light?  I'll PM the lot to you , GT500, referring to this thread.

I also ran an experiment.   I have a collection of old image copies and did the following:

  • Restored the C drive to 2017-12-21
  • Disconnected the network to prevent any automatic updating
  • Started Windows (and thereby EAM) – TrustedInstaller.exe did NOT launch
  • Turned off EAM automatic updating, connected the network and restarted Windows
  • Clicked EAM 'Update Now' and permitted the computer restart request
  • On the restart completing, TrustedInstaller.exe DID launch

So, in spite of the parentage of TrustedInstaller.exe, I think this says that the problem does involve EAM - something that has changed in the last couple of years...

Continued, restoring to other old image copies and found

  • 2019-06-02 the problem (i.e. TrustedInstaller.exe getting launched) did not exist
  • 2019-06-23 it did

Between these dates (on 2019-06-10) EAM updated itself to 2019.5.0.9476 . 

Then, yet a further experiment:  I re-installed EAM to see if TrustedInstaller.exe gets launched in a freshly installed environment with "as installed" settings.  Yes, it does.

 

Share this post


Link to post
Share on other sites

I'm not sure that your conclusion follows.  You saw TrustedInstaller.exe run after a restart on an outofdate version of Windows, as soon as the network was available - that's perfectly understandable when you consider what it's meant to do.   In the earlier instance when the network wasn't available maybe either TrustedInstaller started and stopped immediately - or just wasn't started?   [You say that it didn't launch ... but how do you know?  - do you (audit-)log process creation & termination?  Maybe it never starts if the network is unavailable.]

Lots of people seem to have problems with TrustedInstaller.exe, if one googles for info about it.  But beware, many of the sites which offer advice are generic ones offering possibly-dodgy replacement copies of .exe's etc.

Share this post


Link to post
Share on other sites

@Alan_S from the debug logs, it appears to be the Windows Servicing Stack that's calling TrustedInstaller. This is more than likely related to Windows trying to install updates. The section in the debug logs that shows it starts with nlaapi.dll (Network Location Awareness API), which is capable of notifying applications (in this case probably the Servicing Stack) of network location changes.

What I saw started on line 7,417 of the a2service log.

Share this post


Link to post
Share on other sites

Arrg,  It indeed is EAM that is the culprit.  It does this on all Win 7 installations.  There is one KB that has to be installed for  updates  to be successful.   The really stupid thing is it doesn't just check for that KB it goes thru everyone of the ones installed on your system.

I've solved the problem with a selective block on Trustedinstaller.exe

Pete

Share this post


Link to post
Share on other sites
14 hours ago, Peter2150 said:

Arrg,  It indeed is EAM that is the culprit.  It does this on all Win 7 installations.  There is one KB that has to be installed for  updates  to be successful.   The really stupid thing is it doesn't just check for that KB it goes thru everyone of the ones installed on your system.

As far as I know it's only supposed to check for that during installation. I'll ask QA for confirmation about that.

Share this post


Link to post
Share on other sites

Peter, you are a champ!  It all falls into place now. I assume it's the requirement of the SHA-2 signing support patch, 4474419. I didn't make the connection between the requirement of a Windows patch and TrustedInstaller.

Apart from the annoyance of the 2 minutes virtual standstill I was concerned about not knowing what was (perhaps) being installed but now I know what's happening I suppose I can live with it until making the dreaded leap to Windows 10.  Or an iMac, perhaps Linux...

Anyway, thank you all!

 

Share this post


Link to post
Share on other sites
9 hours ago, GT500 said:

As far as I know it's only supposed to check for that during installation. I'll ask QA for confirmation about that.

Arthur

 

Thanks for checking.  I hope you are correct but fear not.   Still don't see why they can't just check for that one KB instead of going thru the whole list.

Share this post


Link to post
Share on other sites
7 hours ago, Peter2150 said:

Thanks for checking.  I hope you are correct but fear not.   Still don't see why they can't just check for that one KB instead of going thru the whole list.

I've been told that EAM does check for the presence of the Windows Updates that added SHA-2 code signing support to Windows 7 on each startup. It first checks the registry (which is quick and painless), however if that registry check fails to verify the presence of the update then it checks with WMI. Unfortunately when you query WMI to see if an update is installed, it has to check with Windows Update (which calls the services stack, which launches TrustedInstaller, etc).

We've been discussing ways to make this less painless, however please note that it might take some time to implement any such changes, and with Extended Support for Windows 7 ending in a few months (at least for those who don't pay Microsoft for continued security updates beyond the January 14th, 2020 deadline) we may find it difficult to devote development time to changes we may be removing within the next year or two anyway.

Share this post


Link to post
Share on other sites

Perhaps you could find out specifically what EAM looks for in the Registry, then?   In @Peter2150's case, he says that KB /is/ installed on his system.  So if something's missing from the registry on his system couldn't he just add that manually so that the whole WMI/TrustedInstaller rigmarole never happens?

I suppose anyone who doesn't have the KB in question installed could also fake it... but that might not be safe?

Share this post


Link to post
Share on other sites

As I said it isn't a problem for me.  For trusted installer to run I have to turn off Appguard, which I do for installs, but when EAM updates is on Appguard blocks it and so it doesn't bother me. 

Share this post


Link to post
Share on other sites
22 hours ago, JeremyNicoll said:

I suppose anyone who doesn't have the KB in question installed could also fake it... but that might not be safe?

EAM can't function without the KB being installed. The drivers wouldn't be able to run at all on 64-bit editions of Windows, and the service may not run either.

Anyway, there might be a good reason for the registry entry being missing (or perhaps the value being different than what was expected).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.