https://bugs.winehq.org/show_bug.cgi?id=49564 Arek Hiler <ahiler(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ahiler(a)codeweavers.com --- Comment #3 from Arek Hiler <ahiler(a)codeweavers.com> --- I've been debugging the same issue that happens with Doom II from Steam (also ships with dosbox.exe). The problem got introduced with cd215bb49b ("kernel32: Use the user shared data to implement GetTickCount().") - instead of 1ms resolution we started slipping into 16-17ms. Windows apparently provides resolution of 10-16ms (according to doc), which turns out to actually be 15-16ms with occasional hiccups https://testbot.winehq.org/JobDetails.pl?Key=76665 This was easy to fix but decreasing the update time to 15 ms: -static const timeout_t kusd_timeout = 16 * -TICKS_PER_SEC / 1000; +static const timeout_t kusd_timeout = 15 * -TICKS_PER_SEC / 1000; Doom II worked reliably. Since then another change got introduced - 1ae1088964 ("server: Update shared user data timestamps on every request.") - apparently to address https://bugs.winehq.org/show_bug.cgi?id=49228 So I have tried: -static const int user_shared_data_timeout = 16; +static const int user_shared_data_timeout = 15; Sadly, the game sill crashes. My current guess is that dosbox.exe doesn't like very unstable deltas between ticks, which we have now because we update timestamps at "random" intervals - on each server request. I am yet to verify that -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.