All Steam Proton games hang with faketime

[Arcitec]

Edit: The cause has been narrowed down to a change in Proton/Wine during the 10.x development cycle. See the linked post.

• Distro: Fedora Workstation 44
• Package: libfaketime-0:0.9.12-12.fc44.x86_64
• I also built the latest libfaketime from source code.

Verified that faketime works via terminal (both work for me):

• faketime -f '-415d' /bin/date
• LD_PRELOAD="libfaketime.so.1" FAKETIME="-415d" /bin/date

Steps to reproduce the Proton game hang:

1. Have the native Steam package.
2. sudo dnf install libfaketime to get faketime (or install it from latest source).
3. Change a Steam Proton-based game's launch options to faketime -f '-415d' %command%
4. Try to launch the game. It will probably just hang immediately like all games do for me. I tried multiple different games and everything hangs without any game window appearing at all.

Workarounds I've tried (all fail):

• I also tried the library variant, which still hangs: LD_PRELOAD="libfaketime.so.1" FAKETIME="-415d" %command%
• I even tried using an offset of "+0s" meaning same time as the real clock, just to see if Proton and Steam somehow need to be in sync with the same date, but nope, it still hangs.
• I also tried installing the 32-bit version of faketime, but it doesn't get loaded by Proton and says wrong ELF class: ELFCLASS32, which makes sense since Proton is 64-bit.
• Oh and I also disabled SELinux with sudo setenforce 0 just in case, but every game still hangs.
• I launched steam via a terminal and looked at the logs, but everything looks normal there when it hangs.

I can see that other people have successfully ran games with faketime: https://steamcommunity.com/sharedfiles/filedetails/?id=3584066222

Any ideas why it's hanging every Proton game?

[wolfcw]

Thanks for the report, and as usual, it's hard to tell. (tm)

The next step is usually to apply a tool like strace to figure out where it hangs exactly, and what leads to that situation.

Hangs like that unfortunately can have many different causes, but your test with zero faketime (as in +0s) it's not based on different time values in different parts of the program (such as threads or subprocesses), but a more fundamental issue. It's often seen when programs use libraries that are inherently incompatible with libfaketime or use run-time environments that partially bypass how libfaketime works (by intercepting system calls as a preloaded library), and in those cases, the problem cannot be fixed on the libfaketime end at all.

I don't know Steam Proton, but it seems to be Wine-based, and run-time environments of that complexity are probably never on the happy path of LD_PRELOAD-based approaches. Not sure whether that's a supported use case at all or how it might affect performance and other compatibility aspects, but it might be a quicker solution to put Steam Proton or just the game into a container (as in Docker) or a lightweight VM and use libfaketime system-wide for that whole environment instead of just applying it to the game.

Not sure how it worked for others, but given your linked post is from October 2025, things may have worked back then but changed meanwhile. Various run-time environments have a kind of hop-on hop-off relationship with libfaketime, as compatibility with libfaketime is a non-issue for them (as in "unknown") or no real priority, and that's apparently something we have to live with here. :-)

[Arcitec]

@wolfcw Thanks for the advice! Yeah, Proton is a variant of Wine. :)

I've tried a few more things:

1. I tried running the entirety of Steam with faketime -f '-438d' steam. Steam itself sees the old date and complains about invalid HTTPS certificates for their own store as a result. But the date doesn't pass onto games, because Steam is 32-bit and the games are 64-bit, so I got a LD_PRELOAD architecture mismatch. So that's a dead end. Besides, nobody else needs to do this.

2. I tried running with strace by setting a game's launch options like this:

strace -f -o /home/johnny/game_trace.log faketime -f '-438d' %command%

Unfortunately I have no idea how to decipher the trace. I could see faketime being loaded, and saw it set up some shared memory, but that's the only thing I understood.

3. I kept wondering if the issue was that an older version of faketime is required for this; but when trying to downgrade via building older versions from source, there's a bunch of compilation errors.

4. I then used Fedora's old packages to install precompiled older versions:

• Uninstalled the latest package: sudo dnf rm libfaketime (removes libfaketime-0:0.9.12-12.fc44).
• Viewed older versions: https://bodhi.fedoraproject.org/updates/?packages=libfaketime
• To install an older version, use the full package name, as follows: koji download-build -a noarch -a $(uname -m) libfaketime-0.9.10-7.fc39 and then sudo dnf in ./libfaketime-0.9.10-7.fc39.x86_64.rpm
• Afterwards, I used faketime --version to verify that the older version had been installed.
• Tried:
• ❌ libfaketime-0.9.12-13.fc45 (4 weeks old)
• ❌ libfaketime-0.9.12-12.fc44 (2 months old)
• ❌ libfaketime-0.9.10-7.fc39 (2 years old)
• ❌ libfaketime-0.9.8-10.fc34 (5 years old)
• This covers a very large time span, so I can conclude that the version of faketime is not the issue.

5. Regarding other people running Steam games with faketime, I did a search and found references from the past and present:

• August 2023: https://forums.terraria.org/index.php?threads/king-slime-despawns-after-being-summoned-slime-rain-crown.122921/
• October 2025: https://steamcommunity.com/sharedfiles/filedetails/?id=3584066222
• March 2026: https://www.reddit.com/r/Steam/comments/1rvzcsy/comment/oaznbkj/

I'll try to think of something else that can be tested... if not, I'll either install Windows to dual boot to fix that game, or try to make a distrobox container that has a different date than the host (may be hard).

[Arcitec]

@wolfcw I've narrowed it down a lot now! I figured out that Wine 10.x broke faketime support sometime during the middle of the Wine 10.x development cycle.

Proton version numbers correspond to the Wine version they were built from. The dates listed here are the release dates of the runner.

To simplify installation, I used native Steam and used ProtonPlus to easily install runners (Steam must be closed during installs).

Results:

• ❌ 20260728 Proton Experimental (based on Wine 11 at the moment)
• ❌ 20260703: proton-cachyos-11.0-20260703-slr
• ❌ 20260624: GE-Proton11-1
• ❌ 20260323: GE-Proton10-34 (final version of the Wine 10.x based branch)
• ❌ 20250924: GE-Proton10-17
• ❌ 20250827: GE-Proton10-13
• ❌ 20250719: GE-Proton10-10
• 🆗 20250711: GE-Proton10-9 (this is the last version that still works with faketime)
• 🆗 20250702: GE-Proton10-8
• 🆗 20250602: GE-Proton10-4
• 🆗 20250514: GE-Proton10-1 (earliest version of the Wine 10.x based branch)
• 🆗 20250401: GE-Proton9-27 (final version of the Wine 9.x based branch)
• 🆗 20241211: Proton 9.0-4 (final version of the Wine 9.x based branch)
• 🆗 20240122: Proton 8.0-5 (final version of the Wine 8.x based branch)

This means that Wine became incompatible with faketime due to one of the source code changes in this diff:

GloriousEggroll/proton-ge-custom@GE-Proton10-9...GE-Proton10-10

• Either it's something that Valve implemented in Proton and carried forward after that.
• Or it's due to the bottom of that page, which says that submodule wine was updated and changed some source code (not much).
• Overall, the diff is pretty small, but I have no idea what part of it is the issue.

To narrow this down, it would be interesting to install a modern wine on the system (11.x based) to see if that's broken too, or if only Proton is broken. Could you think of a test to see if plain faketime wine <something> is working? I never use plain wine, don't have it installed and don't have any applications to test with.

[Arcitec]

Because I lack the technical skills to diagnose the exact change that broke Wine/Proton, and I understand that it may never be possible to fix this issue, people who want to faketime in Steam games will be using GE-Proton10-9...

But I still wanted modern advancements in Direct3D to Vulkan graphics translations, to improve game performance and compatibility, so I manually updated the graphics API DLL files.

I am putting these instructions here for anyone else who comes across this and wants the same improvement.

• Install GE-Proton10-9 (easiest done via the ProtonPlus app).
• Download the latest DXVK: https://github.com/doitsujin/dxvk/releases
• Download the latest DXVK-NVAPI: https://github.com/jp7677/dxvk-nvapi/releases
• Download the latest VKD3D-Proton: https://github.com/HansKristian-Work/vkd3d-proton/releases
• Extract and overwrite the old DLLs:

tar -xvzf dxvk-*.tar.gz
mkdir nvapi
tar -xvzf dxvk-nvapi-*.tar.gz -C nvapi
tar --zstd -xvf vkd3d-proton-*.tar.zst

PROTBASE="$HOME/.local/share/Steam/compatibilitytools.d/GE-Proton10-9/files/lib/wine"

mv -f dxvk-*/x32/*.dll "$PROTBASE/dxvk/i386-windows/"
mv -f dxvk-*/x64/*.dll "$PROTBASE/dxvk/x86_64-windows/"

mv -f nvapi/x32/*.dll "$PROTBASE/nvapi/i386-windows/"
mv -f nvapi/x64/*.dll "$PROTBASE/nvapi/x86_64-windows/"

mv -f vkd3d-proton-*/x86/*.dll "$PROTBASE/vkd3d-proton/i386-windows/"
mv -f vkd3d-proton-*/x64/*.dll "$PROTBASE/vkd3d-proton/x86_64-windows/"

To verify that the version has been updated, I used DXVK_HUD=version %command% as my launch argument, which adds an overlay to the top left of the game window. Indeed, the latest version of DXVK was being used.

And for the grand finale, I was able to run Grounded with PULSE_LATENCY_MSEC=30 faketime -f '-438d' %command% -dx11 which makes it think it's May 20th, 2025. I can finally resume the save I had abandoned a year ago, and grab past seasonal content for this single player game without needing to wait a whole year again! I had to put Steam into Offline Mode though, because this particular game tries (and fails) to connect to Microsoft's game services when faking time.

This is overall a satisfactory solution. It would be even better to fix the bug in Wine/Proton to make the newest versions work with faketime, but I understand that this may never happen. So for everyone else who gets stuck in the future - this is the workaround.

[wolfcw]

To narrow this down, it would be interesting to install a modern wine on the system (11.x based) to see if that's broken too, or if only Proton is broken. Could you think of a test to see if plain faketime wine <something> is working? I never use plain wine, don't have it installed and don't have any applications to test with.

https://gist.github.com/rmi1974/51244c06dbe1a84e052c09c5e142358a might be interesting in this context, basically running something like wine cmd.exe /c time /t through libfaketime.

[Arcitec]

@wolfcw Thanks a lot for the idea of how to test Wine! I installed Wine 11 native but wasn't able to test it, because it hangs forever on the "updating configuration" popup window, no matter how many times I delete ~/.wine and try wineserver -k to retry.

But I may have found the Wine component that hangs. It seems to be this, which starts appearing after messing with the time a few times:

0048:err:sync:RtlpWaitForCriticalSection section 0000000000039320 "../src-wine/programs/services/services.c: scmdatabase" wait timed out in thread 0048, blocked by 00e0, retrying (60 sec)

Detailed analysis about how it breaks

All tests below done via GE-Proton 11-1.

Commands used for testing:

• Kill command:

~/.local/share/Steam/compatibilitytools.d/Proton-GE\ Latest/files/bin/wineserver -k

• Regular command:

~/.local/share/Steam/compatibilitytools.d/Proton-GE\ Latest/files/bin/wine cmd.exe /c date /t

• Faketime command:

faketime -f '-415d' ~/.local/share/Steam/compatibilitytools.d/Proton-GE\ Latest/files/bin/wine cmd.exe /c date /t

Results:

All commands are executed in the order below:

1. Faketime command: Works, gives me a date in 2025.
2. Faketime command again: Works.
3. Faketime command again: Works.
4. Regular non-faketime command: Works. Gives me the current date.
5. Faketime command again: Hangs with the log below:

faketime -f '-415d' ~/.local/share/Steam/compatibilitytools.d/Proton-GE\ Latest/files/bin/wine cmd.exe /c date /t
ERROR: ld.so: object '/usr/lib64/libfaketime.so.1' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ntsync: up and running.
002c:fixme:winediag:loader_init wine-staging 11.0 is a testing version containing experimental patches.
002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
0050:fixme:ntoskrnl:kernel_object_from_handle No constructor for type L"Token"
00a8:fixme:ntoskrnl:kernel_object_from_handle No constructor for type L"Token"
00b0:err:hid:get_container_id_for_usb_udev_device Failed to get parent device.
00ac:fixme:xinput:pdo_pnp code 0xc, not implemented!
00ac:fixme:xinput:pdo_pnp code 0xc, not implemented!
00ac:fixme:xinput:pdo_pnp code 0xc, not implemented!
00ac:fixme:xinput:pdo_pnp code 0xc, not implemented!
00ac:fixme:wineusb:query_id Unhandled ID query type 0x5.
00ac:fixme:wineusb:query_id Unhandled ID query type 0x5.
00ac:fixme:wineusb:query_id Unhandled ID query type 0x5.
00f8:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded.
00f8:err:winediag:nodrv_CreateWindow L"The explorer process failed to start."
0048:err:sync:RtlpWaitForCriticalSection section 0000000000039320 "../src-wine/programs/services/services.c: scmdatabase" wait timed out in thread 0048, blocked by 00e0, retrying (60 sec)
0048:err:sync:RtlpWaitForCriticalSection section 0000000000039320 "../src-wine/programs/services/services.c: scmdatabase" wait timed out in thread 0048, blocked by 00e0, retrying (60 sec)
0048:err:sync:RtlpWaitForCriticalSection section 0000000000039320 "../src-wine/programs/services/services.c: scmdatabase" wait timed out in thread 0048, blocked by 00e0, retrying (60 sec)

6. Regular non-faketime command: Hangs too. No terminal output at all except if you wait, then it starts doing the "wait timed out" messages too. Indicates that the previous faketime command (step 5) hung a critical Wine process.

0048:err:sync:RtlpWaitForCriticalSection section 0000000000039320 "../src-wine/programs/services/services.c: scmdatabase" wait timed out in thread 0048, blocked by 00e0, retrying (60 sec)

7. Kill command: By killing the Wine server, the hang ends.
8. Regular non-faketime command: Works. Gives me the current date.
9. Faketime command: Hangs. Exact same log as step 5.
10. Kill command: By killing the Wine server, the hang ends again.
11. Faketime command: Works, gives me a date in 2025.
12. Regular non-faketime command: Works. Gives me the current date.
13. Faketime command: Hangs. Exact same log as step 5.

For good measure, I did one more test where I tried -415d to start Wine, and then tried -400d on the next command to "bring the time a bit forwards". It hangs with the same log as step 5. This surprised me.

Conclusion about Proton 11.x

• Proton 11.x allows you to start with an old, fake time if that's the first command you run. But it hangs if you jump to today and then back to the past.
• Just to check, I ensured that ps aux | grep wine had NOTHING, and then ran the latest Proton with faketime INSIDE Steam again. It unfortunately hangs immediately even on the first run. So it doesn't have the same luxury as the command-line version of the same runner which was used by these tests. Maybe because a lot more processes are involved.