2
0
This issue has been going on for a while now and has started approx. 2 months ago.
I am a user of the Steam gaming platform, the client of which I use on my Windows 7 Workstation comes with a executable called Steam.exe.
All good so far - since a few Windows updates back, starting said binary takes much longer than usual, up to 20 seconds during which the executable just sits doing nothing (checked with process monitor, the main thread of program just sits at the entry point doing nothing).
The tricky part is, it can be any binary - the only criteria is the name, if its called Steam.exe, it takes ages to start executing. If it's not, everything's dandy. If I rename the same executable to Steam_.exe, it runs fine - instantly.
What the hell is this? A clean reinstall didn't fix the issue, BUT it's not happening in a virtual machine with the exact, identical Windows 7 setup.
Surely the Steam Client is setting some flag or setting, somewhere, which makes all of the processes named "Steam" take ages to start executing?!
Or... what else can this be, anyone experienced something similar? Some longer Google Search sessions came up with basically no useful results, I could just wait it out every time I start the application but my OCD won't let me, I want it fixed.
My system is a Windows 7 with SP1 + all recommended updates installed, defender disabled, firewall disabled, literally no other software except for Firefox, EMET 5.52 and Steam.
Best Regards
Jessica Wright
Posted 2017-06-05T16:38:09.557
Reputation: 21
1Do you have an AMD graphics card? In that case check whether
AMD External Events Utilityservice is running (if not, just try to reinstall AMD drivers). I've had the same problem and figured out that I've disabled that service manually (looked unnecessary to me). When I've enabled it again the problem was gone. – ge0rdi – 2017-06-05T17:47:55.313ge0rdi, thank you very much, that was indeed the cause of the issue! However, an additional tweak was needed - we use VeraCrypt for full disk encryption, and the service responsible for mounting "system favorite" (external, non system) volumes had to be made a dependency of the external events service, so external events would not start before VeraCrypt had finished its (time intensive) task. Weird, because the service does not rely on any volumes not available at boot. Windows..hate it at times :) Thanks. – Jessica Wright – 2017-06-05T21:17:32.170