Skip to content

docs: record what the Epic Games Launcher needs that Wine lacks #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
MotherSphere merged 2 commits into from
Oct 27, 2026
Merged

docs: record what the Epic Games Launcher needs that Wine lacks #40

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
19d25e6
docs: record what the Epic Games Launcher needs that Wine lacks
MotherSphere Oct 27, 2026
0b15481
Merge remote-tracking branch 'origin/main' into epic-launcher-limits
MotherSphere Oct 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions docs/guide/troubleshooting.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,6 +142,59 @@ The same Rufus is still a useful data point: under plain Wine it crashes at
startup before showing a window; against a Raven environment it runs and
renders. Real-Windows worlds sometimes fix programs, not just break them.

## The Epic Games Launcher asks you to sign in at every start

Seen with launcher 20.3.6 under Wine 11.20. The first sign-in works and holds
while the launcher runs. At the next start the saved sign-in is refused, and
the launcher's log
(`%LOCALAPPDATA%\EpicGamesLauncher\Saved\Logs\EpicGamesLauncher.log`) shows
`errors.com.epicgames.common.oauth.invalid_dpop_proof` with "Signatures of
refresh tokens do not match".

The launcher binds its saved sign-in to a named key it creates through CNG in
the Microsoft Software Key Storage Provider, and signs a proof with that key at
every refresh (DPoP). Wine's `ncrypt.dll` keeps a named key only in the process
that created it: `NCryptOpenKey` is a stub that returns `NTE_NOT_SUPPORTED`
(0x80090029). The launcher therefore creates a new key at each start, and
Epic's server rejects the saved token. A .NET probe in a throwaway environment
shows the same: `CngKey.Create` of a named ECDSA P-256 key succeeds, and
`CngKey.Open` of that name from a second process fails with 0x80090029.

The base's own `ncrypt.dll` is no way around it. Loaded as native under Wine
11.20 it unloads again before the first call, and the provider behind it keeps
keys through the KeyIso service in `lsass.exe`, which Wine does not have.

This is Wine's to fix: `NCryptOpenKey` is still a stub on Wine's master branch
in October 2026. Until then, sign in once each time the launcher starts.

## Install Engine does nothing in the Epic Games Launcher

Seen with launcher 20.3.6: "Install Engine" does nothing, and the log shows
`EoshState = WaitingForBuildsAndItemFiles` and `found 0 entitled apps`. This is
not Raven's or Wine's: the same lines were reported on Windows 11 with launcher
20.3.5 in
[Epic's forum](https://forums.unrealengine.com/t/launcher-20-3-5-install-engine-and-do-nothing-0-entitled-apps-eula-never-shown/2840448),
along with an empty Engine Versions list, a greyed-out "+" and no licence
agreement.
The workaround posted there, not yet tried under Raven: in Unreal Engine >
Samples, add a free sample such as the Game Animation Sample to the library and
try to create a project from it. The launcher says the engine is missing, and
from then on "Install Engine" and "+" work.

The logs of Epic Online Services (EOS), the background service the launcher
hands installs to, also show `EOS_SESSION_GUID environment variable is
required.` and exit code 91. That comes from EOS's own update step, which its
service runs every two hours
(`EpicOnlineServicesHost.exe startandwait --mode=stage`). Installs go through another copy of the same helper, which the
launcher starts itself with that variable set: it reports `MAINSERVICE_READY`
and accepts the launcher's sign-in. The update step fails because Wine runs a
service under the user's account, not LocalSystem: a test service registered
with `sc create` saw the SID `S-1-5-21-0-0-0-1000`. EOS's helper checks for
LocalSystem (`IsWellKnownSid` in its `os_toolbox.node`), logs
`isSystemUser: false`, and takes the path that needs the variable. Installing
EOS through its MSI package works: EOS's installer logged
`MSI completed with Success (0)`.

## Anti-cheat refuses to start the game

If the publisher has enabled Easy Anti-Cheat or BattlEye's Linux support, the
Expand Down
12 changes: 8 additions & 4 deletions docs/project/corpus.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,6 +63,7 @@ same investigation from being run twice.
| *ShineHill*, second run onward | Game, Direct3D 11 | **Runs**, and a relaunch immediately after closing now works | - | What sessions bought: before them a relaunch inside three to six seconds was refused outright. The remaining several-second wait is the game's own start-up - plain Wine takes 7.9 s to the same window |
| `dxdiag.exe` (Windows 11 26200) | Microsoft's DirectX diagnostic | **Runs**, drove DXVK to initialise and enumerate the GPU | - | How Direct3D-on-Vulkan was first shown to work at all against a real Windows. Its DirectDraw probe went through WineD3D and its D3D9 probe through DXVK, in one process |
| BS_SoSR 1.15 (NW.js 0.103.1 / Chromium 140, RPG Maker MV) | Game, 64-bit | **Startup crash fixed; WebGL initializes.** Gameplay not verified | `raven` | Tested 2026-09-15 with Wine 11.17. Twice aborted in `remote_font_face_source.cc:357`: no fallback font. The real Windows font files were visible but their registrations were excluded. Registering the existing Arial alone removed the abort; projecting the base's `CurrentVersion\Fonts` also passed the startup check. Existing environments need the narrow rule added and reprojection; see [registry projection](../internals/registry-projection.md#font-registrations). |
| Epic Games Launcher 20.3.6, with Epic Online Services 5.8.1 | Store client (UE5, CEF 90) and its Node.js service | **Runs and signs in**, installs EOS through its MSI. The sign-in is lost at every start, and "Install Engine" does nothing | `wine` (sign-in) | Tested 2026-10-26/27 with Wine 11.20. Sign-in: Wine's `ncrypt` keeps no named keys. Install Engine: the same log lines appear on Windows 11, so the bug is Epic's. EOS's service starts and runs its helper under Wine's Service Control Manager, under the user's SID. See [troubleshooting](../guide/troubleshooting.md#the-epic-games-launcher-asks-you-to-sign-in-at-every-start) |

## Experiment: Proton's Wine against a real Windows

Expand Down Expand Up @@ -115,9 +116,12 @@ Named so the gaps are visible rather than merely absent:
- **A 32-bit Direct3D title.** The x32 libraries are installed and unexercised.
- **Anything using COM**, the category most likely to be broken by a design
decision rather than a bug.
- **A program whose service must actually *run*, not merely register.**
`sc create` and `sc query` work; nothing has yet been made to start and stay
up under Wine's Service Control Manager.
- **A second installer framework.** NSIS, MSI, InstallShield - all untried.
- **A service that needs LocalSystem.** Epic Online Services' service starts
and runs under Wine's Service Control Manager, but Wine runs every service
under the user's SID, so a service that checks for LocalSystem takes another
path. EOS's own update step fails that way; no program has yet been found
that cannot run at all because of it.
- **A second installer framework.** NSIS and InstallShield are untried. MSI ran
through Epic Online Services' package, including its managed custom actions.
- **Anything with a `.mui` file**, to see how mute "mute" really is.
- **A 32-bit program of any kind other than the RPG Maker game.**
Loading