Linux/Proton: GT.Launcher.exe crashes on unimplemented ntdll.NtCreateWaitCompletionPacket

[HouseoftheHollowSun]

Linux/Proton: GT.Launcher.exe crashes on unimplemented ntdll.NtCreateWaitCompletionPacket

I understand Linux/Proton may not be officially supported, but I wanted to document the exact blocker in case it helps with future compatibility or a possible fallback launcher path.

Environment

• OS: CachyOS / Linux
• Game: Dune: Awakening
• Steam AppID: 1172710
• Tested Proton versions:
  • Proton Hotfix
  • Proton Experimental
  • GE-Proton11-1
• Companion versions tested:
  • v0.1.50
  • v0.0.30

Issue

GT.Launcher.exe starts briefly under Proton/Wine, then crashes before showing a UI.

The consistent crash is:

wine: Call from 00006FFFFFF5C540 to unimplemented function ntdll.dll.NtCreateWaitCompletionPacket, aborting
Unhandled exception: unimplemented function ntdll.dll.NtCreateWaitCompletionPacket called in 64-bit code

From Wine tracing, the failure path appears to be:

GT.Launcher.exe
-> Microsoft.WindowsAppRuntime.dll
-> Microsoft.UI.Xaml / WinUI
-> CoreMessagingXP.dll
-> ntdll.dll.NtCreateWaitCompletionPacket

The backtrace includes coremessagingxp, and CoreMessagingXP.dll imports these related APIs:

NtCreateWaitCompletionPacket
NtAssociateWaitCompletionPacket
NtCancelWaitCompletionPacket

Things tested

I tried the following, but the same crash remained:

• Proton Hotfix / Experimental / GE-Proton11-1
• Steam shortcut launch with Proton logging
• Clean throwaway Proton prefix
• Older Companion version v0.0.30
• Windows 7 compatibility mode
• Disabling ntsync, fsync, and esync
• Launching GTBridgeHost.exe separately
• Replacing CoreMessagingXP.dll with the official Microsoft.WindowsAppSDK.Runtime 2.2.0 version

GTBridgeHost.exe does appear to start and wait for a client, so the first blocker seems to be the launcher UI rather than the bridge host.

Conclusion

This looks like a Wine/Proton compatibility issue with the WinUI / Windows App Runtime launcher, specifically through CoreMessagingXP.dll calling NtCreateWaitCompletionPacket.

Possible paths forward might be:

1. Wine/Proton implements the missing wait-completion-packet APIs.
2. Companion provides a non-WinUI / non-WindowsAppSDK launcher.
3. Companion provides a minimal/headless/fallback launcher path that avoids the WinUI startup dependency.

Thanks for the work on the tool. I wanted to document the Proton blocker in case it helps.