From 19d25e6d9c95664bfa0dcc7ab1a089c3b1d4dbd2 Mon Sep 17 00:00:00 2001 From: MotherSphere Date: Tue, 27 Oct 2026 09:54:29 +0100 Subject: [PATCH] docs: record what the Epic Games Launcher needs that Wine lacks The launcher loses its sign-in at every start because Wine's ncrypt keeps no named CNG keys (NCryptOpenKey is a stub returning 0x80090029), and the base's own ncrypt does not load under Wine 11.20. Install Engine doing nothing is Epic's bug, reported with the same log lines on Windows 11. The EOS_SESSION_GUID exit 91 in EOS's logs is its update step, which fails because Wine runs services under the user's SID, not LocalSystem. --- docs/guide/troubleshooting.md | 53 +++++++++++++++++++++++++++++++++++ docs/project/corpus.md | 12 +++++--- 2 files changed, 61 insertions(+), 4 deletions(-) diff --git a/docs/guide/troubleshooting.md b/docs/guide/troubleshooting.md index ed4a03e..83e1a0e 100644 --- a/docs/guide/troubleshooting.md +++ b/docs/guide/troubleshooting.md @@ -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 diff --git a/docs/project/corpus.md b/docs/project/corpus.md index 1d2da22..438ac5e 100644 --- a/docs/project/corpus.md +++ b/docs/project/corpus.md @@ -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 @@ -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.**