Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About Alan_S

  • Rank
    Active Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. 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 t
  3. 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
  4. My apologies for jumping aboard, but this happened to me too 2019-06-19 on both my computers. Later Firefox updates went OK, but today (2019-07-22) it happened again, when updating FF from 68 to 68.0.1 This time I had debug logging activated. Events were as follows: Turned on debug logging EAM updated itself (hadn't used the computer for several days) Restarted 13:03 Started Firefox but did nothing with it (home page is a local html file) 13:08 Got the update offer pop-up. Clicked “Download Update” 13:10 Restarted Firefox: it does the actual update on restarting Got t
  5. Sorry, a Sorry, the above should read "... try to launch a daughter window that doesn't have a scrollbar. "
  6. I've sent you some logs by PM. Perhaps the reason you couldn't reproduce it was Windows. I doubt you are using Win 7 32 bit... Having said that, I've found that sometimes, very rarely, It does work OK for me so perhaps you were in luck! Oh yes, as I've mentioned in 'notes' in the material I sent, I've since discovered that the issue can also occur on log list entries that will try to launch a daughter window that doesn't have a sidebar.
  7. Thanks for the tip! But unless you mean other logs than those I was talking about above, no - it's the same. Still, now I've discovered that launching from the sidebar doesn't give the problem I'll use that until a fix surfaces.
  8. Some good news and some sad news. The good news is that the UI response failure I reported right at the beginning has been fixed by version 2019.2.0.9269 The sad news is that it hasn't fixed the 'overlay' problem - see above post of December 9, 2018. I've looked into this further and narrowed it down: The issue seems to concern the 'Logs' section, when selecting 'View Details' for an entry that will cause the daughter pane to have a scrollbar. In practice this only appears to be the case for an 'Updates' entry. The following will demonstrate the problem: Launch the UI by c
  9. Reporting that the situation hasn't occurred for me since the shower of incidents mid December. That's nearly 10 weeks. I haven't noticed any announcement that sounds like a fix, neither in the beta forum nor the Change Blog (though perhaps it's hidden under “Improved stability”) but something must have happened. It took over 6 months but, as the Bard of Avon said, “All's well that ends well”! Thank you all who have got this to happen!
  10. Thank you! That explains it. I suppose I must have “invented” the EAM_yyyy-mm-dd folder name myself and been a bit more vigilant in previous runs.
  11. I wanted to export the settings. I didn't examine the folder suggesed by the tool very carefully, but saw it where I had exported previously so clicked the OK-button. Expecting the name to be today's date, I looked for the backup but couldn't find it. So, tried again and saw that the tool wasn't suggesting a unique folder name but an existing folder – not the latest even, but one from 2016: EAM_2016-11-28, which apparently got overwritten (see 'Date modified'). What I would expect is that the suggestion would be a new folder and I believe that this was what it did when I u
  12. Apologies for the belated response - been a bit busy. In Windows 7, the basic DirectX support is version 11.0. Apparently, the full version of 11.1 is supported by Win 8.1 but https://blogs.msdn.microsoft.com/chuckw/2012/11/13/directx-11-1-and-windows-7/ says that “Portions of the 'DirectX 11.1 Runtime' are being made available on Windows 7 Service Pack 1 via the Platform Update for Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1 (KB 2670838)” https://support.microsoft.com/en-us/help/2670838/platform-update-for-windows-7-sp1-and-windows-server-2008-r2-sp1 describes what K
  13. Regarding my post above "Just taken a look at it and it's a bit different." Of course it's different! I was looking at it on my other computer (the Dell). The HP is still as in my previous experiment. It's a little bit faster than the Dell. Sorry, I wasn't paying attention but it's getting a bit late this side of the pond! As to the motherboards. Neither are Asus. Speccy says the manufacturers are Dell and HP respecively. Both machines are ancient. The Dell is from November 2007 and there is no newer BIOS. The HP is from 2010. Perhaps the installed BIOS is not the best, but the
  14. Just taken a look at it and it's a bit different. With Settings selected, but not doing anything to change etc. a2start is taking a bit more - changing continually between less than 1 up to 7%. But there's still lots of CPU left!
  15. Aha! Yes Marko, I did misunderstand. I haven't experienced any problems when altering the debug logging state. I'll leave it on though as it might give a bit more info for anyone who is working on the problem. Thanks for the clarification.
  • Create New...