these are logs found in the TEMP folder, don't know if that will help find the issue.

Elytra_Anti-Cheat_Framework_20260902144207.elevated.log

Elytra_Anti-Cheat_Framework_20260902144203_000_Elytra_Setup.msi.log

Elytra_Anti-Cheat_Framework_20260902144203.log

Can confirm — same error reproduces here (App 4809930).

• Tested with Proton 9.0-203 (Steam default) and Proton Experimental: same failure.
• Deleted the whole Elytra install directory (Program Files/Elytra, empty Content folder) between attempts, error persists after fresh MSI reinstall.
• service.exe/control.exe timestamps stay from the original build even after re-running the MSI, only the empty Content folder gets recreated each time.

Worth noting for context: previous WARDOGS playtest builds used Easy Anti-Cheat, this is the first build shipping Elytra. Game is scheduled to release 2026-09-10, so hoping this gets prioritized before then.

After working around the Volume GUID path failure in this issue, I reached a second blocker: Elytra's service crashes when its heartbeat.dll calls the missing ntdll.dll.RtlStringFromGUIDEx function.

Could support for RtlStringFromGUIDEx be tracked and considered for implementation in Wine/Proton? Please let me know if a separate upstream Wine report would be more appropriate.

Observed failure

The launcher now reports:

Session prime failed: Pipe closed while reading RPC header

The Proton log identifies the service crash:

Unhandled exception: unimplemented function ntdll.dll.RtlStringFromGUIDEx called in 64-bit code (0x006ffffff5c8c0).

Backtrace:
=>0 0x006ffffff5c8c0 in ntdll (+0x6c8c0)
  1 0x006ffffc191136 in heartbeat (+0x1136)
  2 0x006ffffc1ad62a in heartbeat (+0x1d62a)
  3 0x006ffffc1d6059 in heartbeat (+0x46059)
  4 0x006fffffe81669 in kernel32 (+0x11669)
  5 0x006ffffff00e0f in ntdll (+0x10e0f)

00000180 (D) C:\Program Files\Elytra\service.exe

How I reached this point

In this game's existing prefix, I added these filesystem aliases under pfx/dosdevices:

volume{00000000-0000-0000-0000-000000000043} -> c:
volume{00000000-0000-0000-0000-000000000053} -> s:

Here c: and s: are existing drive links, with s: pointing to the Steam library. I left those existing links unchanged. After adding the aliases, Elytra installed three module CABs into C:\Program Files\Elytra\Content and extracted their contents. The earlier InstallModule file-open failure was no longer the stopping point. The service then crashed during session setup as shown above.

Test scope

• Game: WARDOGS, Steam AppID 4809930.
• Crash captured September 2, 2026, using GE-Proton11-6, with PROTON_LOG=+file %command%.
• OS/kernel: CachyOS, 7.2.2-1-cachyos, x86-64.
• Elytra installer/service package version: 0.0.3.
• Export inspection using winedump dump -j export also found no RtlStringFromGUIDEx export in the installed official experimental-11.0-20260826-x86_64, proton-11.0-2-x86_64, or proton-10.0-4b 64-bit ntdll.dll files. Their RtlStringFromGUID export is present. This was static inspection; I have not reproduced this second crash with those official builds after adding the aliases.

This report concerns the missing API and the observed service crash. Implementing it has not been tested and should not be taken as confirmation that all Elytra functionality or the full game will then work.

@Evansch0 Yeah, re-linking "c:" and "s:" into those volumes, does allow the Anti-cheat to download the related files but snags at the "Session prime".

Don't know if relevant, just to "rule" out the game, if we bypass the anti-cheat we can load the game just fine, including we can do tutorial and the firing range with no problems, I did not attempt anything related to online since that can be a ban-able offense.

Managed to do the tutorial plus spent hours in the firing range.

Followed this up on my machine and got two blockers further than the report. Short version: after working around the Volume GUID issue and implementing the missing RtlStringFromGUIDEx, Elytra gets all the way to loading a kernel-mode driver, which is where Wine ends.

Setup: Nobara 44 (kernel 7.2.0-202.nobara.fc44), Proton-CachyOS 10.0-20251107 and a self-built Proton from the proton_10.0 branch. Steam library on its own mount (/mnt/spiele, NTFS), game at AppID 4809930.

1. Volume GUID path for the CAB — confirmed, workaround works

Same as reported: InstallModule failed / Failed to open input file / os error 2, Program Files\Elytra\Content stays empty although the MSI installs fine (Applied execute package: Elytra_Setup.msi, result: 0x0).

Adding the alias @Evansch0 described fixes it:

$WINEPREFIX/dosdevices/volume{00000000-0000-0000-0000-000000000043} -> ../drive_c

Worth spelling out for anyone reproducing: the last byte of the GUID is the ASCII code of the drive letter (C = 0x43, S = 0x53, Z = 0x5a), so the alias needed is derivable, not guesswork. After this, Elytra downloads and installs its three module CABs into Program Files\Elytra\Content.

2. New: GetVolumeNameForVolumeMountPointW fails when the library is on its own mount

Next failure, not mentioned in the thread yet — the launcher shows:

Failed to compute volume-GUID path for executable

With WINEDEBUG=+volume:

trace:volume:GetVolumePathNameW L"Z:\\mnt\\spiele\\...\\WardogsClient-Win64-Shipping.exe" -> L"Z:\\mnt\\spiele\\"
trace:volume:GetVolumeNameForVolumeMountPointW (L"Z:\\mnt\\spiele\\", ..., 32)
fixme:volume:GetVolumeNameForVolumeMountPointW Mounted Folders are not yet supported

Cause: the Steam library sits below Z: (the unix root drive) on a separate mount point, so GetVolumePathNameW correctly stops at Z:\mnt\spiele\. GetVolumeNameForVolumeMountPointW then rejects it, because it bails out on any path longer than X:\ (dlls/kernelbase/volume.c, "if length of input is > 3 then it must be a mounted folder").

Workaround: launch option

PROTON_SET_GAME_DRIVE=1 %command%

That makes Proton create dosdevices/s: pointing at the library root, so the executable resolves to S:\steamapps\common\... and the volume path becomes a plain S:\:

trace:volume:GetVolumePathNameW L"S:\\steamapps\\common\\...\\WardogsClient-Win64-Shipping.exe" -> L"S:\\"
trace:volume:GetVolumeNameForVolumeMountPointW (L"S:\\", ..., 32)
trace:volume:GetVolumeNameForVolumeMountPointW found symlink=L"\\??\\Volume{00000000-0000-0000-0000-000000000053}"

Note that without that option Proton actively deletes a manually created s: on every start (setup_dir_drive() in the proton script removes the drive when the compat option is absent), which makes hand-made aliases look like they simply don't work. The matching volume{...053} alias has to be created too.

Users whose library is on the same filesystem as / won't hit this at all, which is probably why it hasn't come up yet.

3. ntdll.RtlStringFromGUIDEx — patched, and it does get past "Session prime"

Confirming @Evansch0's finding: the function does not exist in Wine at all (only RtlStringFromGUID, no Ex), and Elytra's heartbeat.dll imports it statically, so service.exe dies immediately:

wine: Call from ... to unimplemented function ntdll.dll.RtlStringFromGUIDEx, aborting
00000190 (D) C:\Program Files\Elytra\service.exe

which surfaces as Session prime failed: Pipe closed while reading RPC header.

I built Proton with the function added, modelled on the existing RtlStringFromGUID:

--- a/dlls/ntdll/ntdll.spec
+++ b/dlls/ntdll/ntdll.spec
 @ stdcall RtlStringFromGUID(ptr ptr)
+@ stdcall RtlStringFromGUIDEx(ptr ptr long)

--- a/dlls/ntdll/rtlstr.c
+++ b/dlls/ntdll/rtlstr.c
+NTSTATUS WINAPI RtlStringFromGUIDEx(const GUID *guid, UNICODE_STRING *str, BOOLEAN allocate)
+{
+  TRACE("(%p,%p,%d)\n", guid, str, allocate);
+
+  if (allocate)
+  {
+    str->MaximumLength = (GUID_STRING_LENGTH + 1) * sizeof(WCHAR);
+    str->Buffer = RtlAllocateHeap(GetProcessHeap(), 0, str->MaximumLength);
+    if (!str->Buffer)
+    {
+      str->Length = str->MaximumLength = 0;
+      return STATUS_NO_MEMORY;
+    }
+  }
+  else if (str->MaximumLength < (GUID_STRING_LENGTH + 1) * sizeof(WCHAR))
+  {
+    str->Length = 0;
+    return STATUS_BUFFER_TOO_SMALL;
+  }
+
+  str->Length = GUID_STRING_LENGTH * sizeof(WCHAR);
+  swprintf(str->Buffer, str->MaximumLength/sizeof(WCHAR),
+          L"{%08lX-%04X-%04X-%02X%02X-%02X%02X%02X%02X%02X%02X}", guid->Data1, guid->Data2, guid->Data3,
+          guid->Data4[0], guid->Data4[1], guid->Data4[2], guid->Data4[3],
+          guid->Data4[4], guid->Data4[5], guid->Data4[6], guid->Data4[7]);
+
+  return STATUS_SUCCESS;
+}

With that build, service.exe starts, registers its event source, extracts the three modules and loads them. The "Session prime" error is gone.

4. Where it actually ends: kernel-mode driver

Immediately after loading the modules:

fixme:ntdll:NtLoadDriver (L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\elytra_gn03Pndpbk4PR2lT"), stub!
trace:loaddll:free_modref Unloaded module L"...\\mod.0420baa4...":
trace:loaddll:free_modref Unloaded module L"...\\mod.04207452...":
trace:loaddll:free_modref Unloaded module L"...\\mod.0420a822...":

The modules Elytra extracts to %LOCALAPPDATA%\Temp\elytra.<guid>.<rnd>\ are:

mod.04207452.../ elytraldrfs_driver.sys     PE32+ executable (native), x86-64
                 elytraldrfs_shared.dll
                 module.json
mod.0420a822.../ heartbeat.dll
                 module.json
mod.0420baa4.../ lighthouse_driver.sys      PE32+ executable (native), x86-64
                 lighthouse_bootstrap.dll
                 lighthouse_module.dll
                 driver.ini
                 module.json

Both .sys files are native subsystem, i.e. real kernel-mode drivers. NtLoadDriver is a stub in Wine's ntdll, the service gives up, unloads the modules and the launcher errors out.

So this is a kernel-level anti-cheat. Even with NtLoadDriver wired up to the service manager, Wine's ntoskrnl is a user-mode emulation and an AC driver registering process/thread callbacks and scanning other processes' memory is not going to work — and shouldn't be made to look like it does. Unless the Elytra vendor ships explicit Proton/Linux support the way EAC and BattlEye did, WARDOGS is not runnable on Linux, and the two Wine gaps below only move the failure point.

Wine-side issues worth tracking regardless

Both are real gaps independent of this game:

1. GetVolumeNameForVolumeMountPointW does not support mounted folders, so any application resolving a volume GUID for a file on a non-root mount fails.
2. ntdll.RtlStringFromGUIDEx is missing entirely; patch above works if it's wanted upstream.

Happy to provide full PROTON_LOG output for any of the stages.

sad times sad times.

steam-4809930.log

Confirming this issue on CachyOS / KDE Wayland with NVIDIA RTX 3060 and driver 610.57.04.

Tested:
Proton-CachyOS SLR 11
Proton Experimental
Proton Experimental bleeding-edge
completely fresh compatdata prefix

All reproduce the same Elytra InstallModule failed / Failed to open input file / os error 2.

With PROTON_LOG=1 WINEDEBUG=+mountmgr,+file, Wine mountmgr creates both:

??\Volume{00000000-0000-0000-0000-000000000043}
and
\DosDevices\C:

for \Device\HarddiskVolume1.

The downloaded CAB can be opened through its normal C:\users\steamuser\AppData\Local\Temp...cab path, but Elytra subsequently attempts to access the same file through:

\?\Volume{00000000-0000-0000-0000-000000000043}\users\steamuser\AppData\Local\Temp...cab

Wine then returns c00000cb from get_nt_and_unix_names, followed by CreateFileW ... status c0000034.

So this also reproduces on current Experimental bleeding-edge.

// To thanks to my ChatGPT* lol

@Dave-1987 A new update of the playtest has landed and I ran 2 tests one with Experimental(bleeding-edge) and CachyProtonLatest.

I have the volumes linked and I'm getting this anti-cheat error:

I have also collected logs from both runs:

steam-4809930_1.log

steam-4809930_2.log

Hope this helps.

Elytra runs on both The Finals and Arc Raiders, which both work on Linux (CachyOS and Bazzite in my experience). Why don't those games have this issue?

EDIT - Other users have informed me that the version of Elytra that runs on Embark's games is running in a different mode that doesn't require the kernel drivers. See below!

Elytra runs on both The Finals and Arc Raiders, which both work on Linux (CachyOS and Bazzite in my experience). Why don't those games have this issue?

That doesnt run thats server side collecting data for ML

Elytra runs on both The Finals and Arc Raiders, which both work on Linux (CachyOS and Bazzite in my experience). Why don't those games have this issue?

iirc this is not ture
(the finals & arc raiders )
its disabled on both and only "runs for data collection"

Wardogs is afaik currently the only game to run it actively

also here is a good read up for it
https://www.invenglobal.com/articles/25085/the-era-of-guarding-game-files-is-over-the-shift-seen-by-embark

There is a discord user id like to quote here for visibility :

Wardogs / Elytra on Proton — diagnosed to the wall

Ran the whole chain in the game's own prefix. Three findings, in order:

1. Install failure — root cause found and fixed. Elytra passes file paths to its service as volume-GUID paths (GetFinalPathNameByHandleW, VOLUME_NAME_GUID). Wine fabricates \\?\Volume{00000000-0000-0000-0000-0000000000<hex of drive letter>} and then cannot reopen it — STATUS_OBJECT_NAME_NOT_FOUND, surfacing as your "File not found (os error 2)". Workaround: symlinks in pfx/dosdevices/ named for those fake GUIDs. Applied for C:, S:, Z:. All three modules now install (Module added successfully, cabs in C:\Program Files\Elytra\Content). The MSI, the service registration, and the RPC pipe were all fine the whole time.

2. Next blocker, soft. heartbeat.dll imports ntdll.RtlStringFromGUIDEx, unimplemented in Wine → hard abort during session prime. Absent from proton-cachyos-slr, -native, and Proton 9.0 alike, so A/B-ing Proton Experimental won't clear it. Small Wine patch.

3. Terminal blocker. Priming the driver module alone: fixme:ntdll:NtLoadDriver ... stub! → Load fails 0x80070001. Two of the three modules ship real kernel drivers (elytraldrfs_driver.sys, lighthouse_driver.sys). Wine has no kernel to load them into.

Verdict: unplayable until Embark ships a Proton path, same as EAC got. Nothing further in the prefix reaches it. The volume-GUID bug is worth a Wine bugzilla report on its own; the rest is good ProtonDB material since no data exists yet. Leftovers: 55 MB of cabs in the prefix Temp\elytra-mods — say the word and I'll clear them.

In addition to the previous comment about the Elytra download error on Proton Experimental:

After applying the volume{...0043} -> ../drive_c workaround and successfully installing, the current Proton Experimental on CachyOS runs into the subsequent errors as well.

1129356:20794.593:015c:01c0:trace:loaddll:build_module Loaded L"C:\\users\\steamuser\\AppData\\Local\\Temp\\elytra.28c7fa0f-5c9d-4ac8-884a-d17a8447733e.knqAjZ\\mod.04206c23ad67d4551cf8e94075b246a8f53049327fc677d61fd353ae6bd937b265af.lKaGEY\\heartbeat.dll" at 00006FFFFD830000: native
1129360:20794.595:015c:01c0:fixme:ntdll:NtLoadDriver (L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\elytra_3UUXcdDVdiYhn62c"), stub!
1129362:wine: Call from 00006FFFFFF9C280 to unimplemented function ntdll.dll.RtlStringFromGUIDEx, aborting
1129423:wine: Unimplemented function ntdll.dll.RtlStringFromGUIDEx called at address 00006FFFFFF9C280 (thread 01d0), starting debugger...
1129515:Unhandled exception: unimplemented function ntdll.dll.RtlStringFromGUIDEx called in 64-bit code (0x006ffffff9c280).
1129541:  1 0x006ffffd831136 in heartbeat (+0x1136) (0000000000000000)
1129542:  2 0x006ffffd84d62a in heartbeat (+0x1d62a) (0000000000000000)
1129543:  3 0x006ffffd876059 in heartbeat (+0x46059) (0000000000000000)

Have the same error.
Independent confirmation on Gentoo with the official Proton Experimental.

Environment

Game: WARDOGS Playtest, AppID 4809930
Distro: Gentoo Linux
Kernel: 7.2.2
Proton: official Proton Experimental
Trace used: PROTON_LOG=1 WINEDEBUG=+timestamp,+pid,+tid,+winhttp,+wininet,+winsock,+file %command%

Observed sequence

Elytra successfully fetches its config from elytra.ac (HTTP/1.1 200 OK).
It downloads the anti-cheat CAB successfully (HTTP/1.1 200 OK, Content-Length: 189929).
The temporary *.cab.part file is successfully renamed to *.cab.
The CAB is readable through the normal path under C:\users\steamuser\AppData\Local\Temp....
Elytra verifies the module signature successfully.
During Installing module 1 of 3, the service attempts to reopen the same CAB through a Volume GUID path:
\?\Volume{00000000-0000-0000-0000-000000000043}\users\steamuser\AppData\Local\Temp...
Wine then fails that open with CreateFileW ... status c0000034 / file not found.
Elytra reports:
InstallModule failed
RPC error:
Failed to open input file
crates/bin/service/src/server_module.rs:28
File not found. (os error 2)

The current module ID on my system is:

042079a62a15754c377467867d487adcbbc4e0d12768ce9c0ed7c4752763a4e1d108

Elytra's own ElytraLauncher.log confirms that download and signature verification complete before the failure, so this is not a network/download problem. The failure reproduces across multiple launches/build updates on Sep 3-4.

This independently confirms the Volume GUID path-resolution failure on Gentoo + official Proton Experimental. I have not applied filesystem aliases, patched Wine/Proton, or bypassed the anti-cheat. Full Proton/Elytra traces are available if useful.

Independent confirmation on Bazzite using official Proton Experimental (experimental-11.0-20260826-x86_64).

I reproduced the same Volume-GUID failure with WINEDEBUG=+file.

The downloaded CAB is successfully created and opened through the normal DOS path:

C:\users\steamuser\AppData\Local\Temp<module>.cab

Wine resolves that path successfully (ret 0).

Elytra then attempts to reopen the same CAB through:

\?\Volume{00000000-0000-0000-0000-000000000043}\users\steamuser\AppData\Local\Temp<module>.cab

At that point:

get_nt_and_unix_names -> ret c00000cb

CreateFileW -> status c0000034

The CAB is then removed and InstallModule fails.

So the original Volume-GUID issue is reproducible on Bazzite with current official Proton Experimental as well.

I’ve attached a sanitized WINEDEBUG extract containing only the relevant CAB operations.

wardogs-experimental-volume-guid-public.txt

please post the latest pins or information and not old stuff (:

or thier CEO (Joe Brammer) on Twitter:

No, we are just prioritising security ahead of that part of the playerbase. We will bring the game to proton properly ASAP which should be soon after launch.

Security and perf are our biggest priorities, we won’t compromise them.

Yes, we want Linux users to play and we’ll be prioritising that, in part for Steam deck. But not at the expense of security.

So no timeline, but fast. It’s an anti cheat related issue not anything else.

i wouldnt recommend following @nickmartin1ee7 's fixes as you will likely be banned, since elytra doesnt natively have linux support

these linux compat patches would need to come upstream from embark studios directly

Same thing on the full EA release (1867240), not just the Playtest.

Steam Machine, SteamOS, Proton 11.0. Launcher fails with WD-L010-4ea7b9bda656.

Elytra's actual errors only show up with +eventlog (ReportEventW is a stub otherwise):

5475.925:017c:0198:trace:eventlog:ReportEventW L"Service started with arguments: [\"Elytra.Service\"]"
5476.036:017c:01ac:trace:eventlog:ReportEventW L"is_module_installed(0420a0b6d89ceec7fd6b01bb536b90ef72f45c124c939ad156063268266cd2bae75f) -> false"
5476.093:017c:01ac:trace:eventlog:ReportEventW L"c -> s: {\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"InstallModule\",\"params\":[\"\\\\\\\\?\\\\Volume{00000000-0000-0000-0000-000000000043}\\\\users\\\\steamuser\\\\AppData\\\\Local\\\\Temp\\\\0420a0b6d89ceec7fd6b01bb536b90ef72f45c124c939ad156063268266cd2bae75f-316-5476036.cab\"]}"
5476.093:017c:01ac:trace:eventlog:ReportEventW L"s -> c: {\"jsonrpc\":\"2.0\",\"id\":2,\"error\":{\"code\":-32000,\"message\":\"Failed to open input file / crates/bin/service/src/server_module.rs:28 / Fichier introuvable. (os error 2)\"}}"

Module hash changed since the Playtest (0420a0b6... vs 04207452...) but it still dies on the Volume GUID path. Service goes quiet right after GetTempPath2W, launcher gives up ~20s later with error 1726.

Should this be tracked on a new Issue since APPID changed?

I have logs for the current release, APPID: 1867240

WARDOGS-1867240.log

Replying to https://github.com/ValveSoftware/Proton/issues/10113#issuecomment-5548762008

yeah
just refund. Its a fucking circus

Replying to [#10113 (comment)](https://github.com/ValveSoftware/Proton/issues/10113#issuecomment-5637653230)

im not seeing the change number listed here on steamdb

https://steamdb.info/changelist/38799019/