WARDOGS Playtest (4809930)

[rootosiris85]

WARDOGS Playtest (4809930) – Elytra InstallModule fails opening CAB through Volume GUID path
Compatibility Report

Name: WARDOGS Playtest
Steam AppID: 4809930
Distribution: Linux Mint
Kernel: 7.0.0-28-generic

Proton versions tested

The issue reproduces with:

Proton Experimental
Proton 11.0-2
Proton 10.0-4

A completely fresh Proton prefix was also tested.

Symptoms

WARDOGS starts the Elytra anti-cheat/service installation, but Elytra fails during InstallModule.

The Elytra error dialog 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 module identifier involved is:

042074521588d69599a364e2f975460e68551832d35317ce19bd30af43e9cca90758
Investigation

Testing with:

PROTON_LOG=1 WINEDEBUG=+file %command%

shows that Elytra successfully creates/downloads:

C:\users\steamuser\AppData\Local\Temp
042074521588d69599a364e2f975460e68551832d35317ce19bd30af43e9cca90758.cab.part

It then renames it to:

C:\users\steamuser\AppData\Local\Temp
042074521588d69599a364e2f975460e68551832d35317ce19bd30af43e9cca90758.cab

The CAB exists and can be accessed through the normal C: path.

However, Elytra subsequently attempts to open the same CAB using a Windows Volume GUID path:

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

Wine then fails the file open with:

CreateFileW Unable to create file ... (status c0000034)

After the failure, the downloaded CAB is removed.

MountedDevices

The Proton prefix contains:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

??\Volume{00000000-0000-0000-0000-000000000043}
REG_BINARY 2E2E2F64726976655F6300

\DosDevices\C:
REG_BINARY 2E2E2F64726976655F6300

Therefore the Volume GUID used by Elytra and C: appear to reference the same backing path.

Nevertheless, opening the CAB through the Volume GUID path fails while the regular C: path works.

Reproduction
Install WARDOGS Playtest (Steam AppID 4809930).
Force Proton Experimental, Proton 11.0-2, or Proton 10.0-4.
Use a fresh compatibility prefix.
Launch the game.
Elytra installs and starts its service.
Elytra downloads the module CAB to %LOCALAPPDATA%\Temp.
Elytra attempts to access the CAB through \?\Volume{...}.
CreateFileW fails with status c0000034.
Elytra reports InstallModule failed / Failed to open input file / os error 2.
Expected result

The Volume GUID path corresponding to the Proton C: drive should resolve to the same file as the normal C:... path, allowing Elytra to install its module.

Actual result

The CAB can be downloaded and accessed through C:..., but opening the same file through the corresponding \?\Volume{GUID}... path fails.

The behavior is reproducible after deleting the entire Proton compatibility prefix and allowing Steam/Proton to recreate it.

[RNKode]

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

[KenBlasse]

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.

[Evansch0]

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.

[RNKode]

@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.

[Dave-1987]

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.

[AtomicKaiser]

sad times sad times.

steam-4809930.log

[Floder151]

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

[RNKode]

@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.

[GameVogue]

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!

[AtomicKaiser]

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

[DSDV]

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

[DSDV]

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.

[Dragster39]

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)