@Yorok0 Yeah, your particular case seems a bit different because the lag happens in between clicking the button in Steam and the splash screen showing up at all. Some of the replies seems to be describing the other issue, so I figured it’s worth mentioning it here.
If this bothers you enough and you are willing to dig around a bit, the process I used to uncover the other bug may give you some insights into what kind of work is going on behind the scenes, thus giving you a shot in finding a workaround.
What I did is use Process Monitor to spy on the game. It is a debugging tool by Microsoft that shows you what Steam or the game is asking the operating system to do – opening/reading/writing files, network requests, etc.
First, launch Steam and get it to a “steady state” – let it finish checking for updates, close any welcome screens and navigate to the Age Of Empires II page where you can click the start button (but don’t click it yet).
Then download the tool from Microsoft, extract the zip file, right click and run it as administrator.
You should see a screen like this:
At any given moment, there are a lot of things going on in the operating system, so it will be extremely noisy to list every single event. Therefore, the tool gives you an opportunity to narrow down the events you may be interested in.
It comes with a bunch of default filters that excludes things you likely don’t care about, but it’s still going to be quite noisy. What we want to do is to narrowly focus on only things Steam or AOE is doing. As shown in the screenshot, the filters you want to add are:
Image Path is C:\Program Files (x86)\Steam\Steam.exe then Include
Image Path is C:\Program Files (x86)\Steam\steamapps\common\AoE2DE\AoE2DE_s.exe then Include
Here, “Image Path” means the location of the
.exe files you are interested in. You may have to adjust the paths based on where your game is installed.
Press Ok and Process Monitor will start listening for and enumerate events matching your filters. Anything you see now before you start launching the game is probably “normal” Steam events and can be ignored for our purposes. Take a mental note of any events you see so you know to ignore them later (there may not be any – when I tried it on my computer, there were none), then press the “Clear” button (Ctrl + X) to remove them from view. You may also want to turn on Autoscroll (Ctrl + A).
Now press the “Play” button in Steam and observe what happens. It is going to be a firehose and most of the events are probably uninteresting. What you want to look for anything that “stands out” which may give you some clues on what it is spending its time on.
Here are a few rules of thumb:
- Reading from the windows registry (
RegCloseKey, etc) is probably uninteresting, it’s pretty normal and unlikely to be slow. You can make a filter to ignore them if you want.
- It’s going to load a lot of
.dll files (anything with a
.dll in the
Path column), but that is also pretty normal and probably not your problem, unless you observe that it’s spending a lot of time on loading a particular
.dll file. You can also make a filter for it if you want.
You are specifically interested in getting some insight into what it is doing during the time where it’s “stuck”.
If you are lucky there will be a big gap of time where there are no events, which probably means it is waiting for the last event to finish, in which case whatever it is, is likely the problem. An alternative explanation for this is that it is spending time doing non-operating system level stuff, which would be much harder to figure out. It is also possible that it is doing the work in a differently named
.exe so it escaped our filters.
Another possible (and more likely) scenario is that during the time it is stuck, it’s actively doing some work and causing a ton of events. This is what happened in my case, and led me to discover it’s slow because it’s trying to go through all the files in
If you are able to do this, then you can compile a sample of the events, and I can help look into it. Those of us who don’t have the same problem you described can also run the same experiment and tell you what events are found and to be expected in a “healthy” setup, so you can cross-reference them with your list to narrow down the possible suspects.