Basically, resyncing your date and time and checking region settings may help with the long initial load time.
Follow these steps:
Synchronize your Time and Region settings.
1. Press the Start button on the taskbar, type settings, and select Settings. 2. Select Date & Time and toggle the “Set time automatically setting" and “Set time zone automatically” to ON. 3. Click on Synchronize your clock to synchronize your system’s clock with an Internet time server. 4. Then click Region, and double-check that your country or region is correctly set up (for example if you live in Canada, make sure that the region didn’t switch to USA or vice-versa)
I have tested this and it has solved the issue on my end…no more deactivating internet connection before loading the sim.
@ToOlBoY1 … could you modify the topic of this thread to make it easier to find?
Like adding:
“… due to out-of-sync OS system time”
I will use this topic for further collection of information … because it is still very short and focused on that specific “OS time sync” topic.
In order to put some “substance” to this “clock topic” I made some more tests and did also record a “stuck” launch with the … Process Monitor … tool, as it gives the most detailed insight into the activities of a process.
I compared two recordings:
A) A normal quick launch event
… with a clock that was in-sync with “global NTP time”
B) A “stuck at 7% Loading languages” launch attempt
… where the clock was intentionally 2 hours ahead.
The following image may be somewhat hard to read …
When we look at the connection to the server with IP 20.42.182.108 we can see that:
In the success case (A) … only 1 connection was made
In the Stuck case (B) … 14 connections have been made
… and most likely the client did run into some timeout, as it did not receive any actual results from the server
… and so it opened another connect.
Now this is a classical “self inflicted denial of service attack” … due to a connection and “request amplification” pattern.
The client is basically continuously pushing requests into the server message queues … and those messages (apparently) will have to wait for … here 2 hours … in order to reach the front of the queue … and so the client will timeout and decides to send the same message again and again and …
Now during that time it is not that there is no exchange of data … so the network is under continuous usage … but the process simply can not make any progress.
The following is showing the “try a new connection” pattern …
Now I need to stress that the above is just an “educated guess” … as I do not know the Asobo code. But the event pattern is fairly obvious … and somewhat “common”.
