Since 1.17-pre1 and also in 1.17, Minecraft almost always gets stuck for over a minute very early in the boot process seemingly doing nothing (no CPU usage).
This did not occur in any version prior (confirmed for 21w20a).
Sometimes, this pause only takes 3-4 seconds, but most of the time, it's doing the long con.
This long pause can be seen in the log:
[16:15:46] [main/WARN] [PerfDataUtil]: Failed to add PDH Counter: \Auslagerungsdatei(_Total)% Usage, Error code: 0xC0000BB8
[16:15:46] [main/WARN] [PerfCounterQueryHandler]: Failed to add counter for PDH object: Auslagerungsdatei
[16:15:46] [main/WARN] [PerfCounterQuery]: Disabling further attempts to query Paging File.
[16:17:03] [Render thread/INFO] [YggdrasilAuthenticationService]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
The log line just before the pause stems from oshi, which was updated from 1.1 to 5.3.4 in 1.17-pre1 and it is using the newest version 5.7.4 in 1.17.
Looking into it's code, the very next action after logging "Disabling further attempts to query ..." is to query the WMI as can be seen here:
https://github.com/oshi/oshi/blob/4f56e5ba786121a00779e83af0cbf73ecf57b592/oshi-core/src/main/java/oshi/util/platform/windows/PerfCounterQuery.java#L105-L112
This query is using a timeout value, which is set via the oshi.util.wmi.timeout field inside the oshi.properties file (inside e.g. oshi-core-5.7.4.jar) and that is currently set to -1, meaning no timeout.
This makes me think it is stuck querying the WMI (for some other unknown reason).
I wanted to try and change the timeout, but I'm not sure how, since it's part of oshi-core-5.7.4.jar and modifying it would cause it getting redownloaded (at least with the launcher I'm using).
While this does look like oshi is the cause, I'm not 100% certain, which is why I'm reporting it here first.
Related issues
is duplicated by
relates to
Comments
Fourmisain
Fourmisain
Update:
We (by which I mean dbwiddis) managed to fix the boot pause by fixing a localization bug inside oshi (only non-English Windows machines should be affected by this issue).
The issue was that it couldn't find performance counters due to their localized names (as the warnings suggest) and was falling back to using WMI queries which can be very slow (usually 20+ seconds, 70+ on my system at least) when WMI hasn't "woken up" yet.
The original boot pause issue can be fixed by updating to oshi-core-5.7.5-SNAPSHOT.
That said, there's now a new issue that the same exact pause happens when pressing F3+L due to the use of `getProcessorCpuLoadTicks()`, which causes another slow WMI query.
This new issue should apply to all Windows systems as it doesn't appear to be a localization issue.
It is currently not clear if this can be fixed or if it needs to be worked around.
A possible workaround would be to simply asynchronously call `getProcessorCpuLoadTicks()` while booting, throwing away the answer. This should "wake up" WMI so the next possible F3+L profiling should be fast - but it's no guarantee.
Fourmisain
(Final?) Update:
oshi-core-5.7.5 is now released and updating to it should close this issue.
The mentioned follow-up issue of F3+L freezing the game for a long time might only affect a handful of systems.
For some reason, the "Processor Information" performance counter can't be queried directly on my Win7 system, which is why it ends up querying WMI - but dbwiddis tested this on a Win7 VM and there it wasn't an issue.
For anyone reading:
This pausing/freezing issue can potentially be lessened by rebuilding performance counters. I have to warn however, that this is no easy task, it takes a lot of time, can potentially break things like .NET startup and the instructions don't fully work for Win7. For me it reduced the pause time from over 70s to about 3-7s.
migrated
OSHI maintainer here.
TL;dr:
I recommend you update your `oshi-core` dependency version to 5.7.5 to resolve this issue.
Background:
There's been a longstanding bug in OSHI (since 3.13.0) where performance counter names were localized, but then used in a method designed for the English counter names.
Since there has always been a fallback to (slower) WMI, this didn't cause a failure, just a slower response time.
This only impacted users using non-English versions of Windows
For a small fraction of those users, some experienced significant delays for yet-unknown reasons that seem to be fixed by rebuilding performance counters
This bug has been fixed in 5.7.5 and tested with Minecraft to resolve this report
There are no other significant changes in 5.7.5 that would introduce any additional risk to updating the dependency version
migrated
NOT FIXED IN 1.17.1
migrated
I'm still seeing this behavior in 1.18 and 1.18.1rc2 in both the client and the server. Sometimes either will end up starting after a certain amount of time ranging from 5 seconds to 2 minutes, but usually they do not. I am running a local server and playing at the same time, and the failure rate seems to much higher when attempting to run both. I'm going to try to spin up the server on another machine and see if that changes anything.
ampolive
New issue is tracked in MC-253901.
I think I may have just confirmed it is indeed oshi that is taking up so much time.
Compiling it and running the
SystemInfoTest(like explained here) produces the following log output:As you can see, there's the over a minute long pause checking memory again, just like Minecraft while checking the pagefile.
I therefore went ahead and opened an issue over at the oshi issue tracker as well.