Description
Hosting a server crashes BF2 on Linux, every time, on every map. This is on the unofficial
Linux port of the Kyber launcher (BF2 runs through Wine/Proton via umu). Joining and playing
work fine for 30+ minutes on the same setup; only hosting is broken.
A few seconds after the listen server starts loading its level, Frostbite's own renderer calls
device->CreateTexture2D(...), which fails with E_INVALIDARG (0x80070057). Kyber catches the
fault, uploads a Sentry crash, and the process terminates.
The failing CreateTexture2D call is Frostbite's own (the error line comes from the engine's
own DX error handler, Kyber only captures it). We ruled out the Kyber ModLoader as the trigger:
launching with KYBER_DISABLE_MODLOADER=1 produces zero [ModLoader] Loading bundle lines
(confirmed it never ran) and the host still crashes identically. So the bad texture descriptor
comes from the host-side / listen-server render path itself, not from Kyber's resource
reshaping.
Steps To Reproduce
- Launch the game through the Linux launcher, log in.
- Create/host a server (any map, any mode).
- Server registers fine (launcher shows "Detected hosting status", moderation view loads,
0/N players), listen server starts loading the level.
- ~7-56s later (varies per run):
[DXERROR] CreateTexture2D(...) failed with E_INVALIDARG,
crash uploaded to Sentry, process terminates.
Expected Behavior
The host loads the level and stays up, same as on Windows, and same as joining as a client
on this exact setup (which renders fine for 30+ minutes).
Screenshots
Not applicable, there is no visual symptom before the crash. The relevant evidence is the
crash log below.
Additional Context
Environment:
- Game: STAR WARS Battlefront II (
starwarsbattlefrontii.exe, Origin.OFR.50.0002015), Frostbite.
- Launcher: Kyber Linux port, beta.6.4.7 (AppImage), umu-launcher 1.4.0.
- GPU: NVIDIA GeForce RTX 3060 (DeviceID 0x2504), proprietary driver. PlatformMode WIN32_DX11_NVIDIA.
- Host OS: Ubuntu (X11), glibc 2.39.
- Not an out-of-memory condition: GPU local memory budget ~10.7 GB, ~1.4 GB used at the crash.
Exact error (logged by Frostbite, captured by Kyber):
[DXERROR] DirectX function "device->CreateTexture2D( &texDesc, desc.subResourceCount != 0
? reinterpret_cast<const D3D11_SUBRESOURCE_DATA*>(desc.subResourceData) : 0,
&texture->m_texture2d)" failed with E_INVALIDARG ("An invalid parameter was passed to the
returning function."). GPU: "", Driver: <driver>
[DxErrorCode] 80070057
Redirecting crash to Sentry
Process terminated
The GPU adapter string is empty ("") at the moment of failure, though it is reported correctly
at init ("NVIDIA GeForce RTX 3060").
Host-side sequence right before the crash (kyber log):
[Server] Constructing a 30hz server Levels/MP/Kamino_01/Kamino_01
[Server] Starting server Levels/MP/Kamino_01/Kamino_01 (Hooked: 1)
[Server] Server started
... 7-56s ...
[DXERROR] CreateTexture2D ... E_INVALIDARG
Reproductions (Sentry crash IDs):
- ac22d20f-9264-410b-0ce9-3fd813f13864 (Geonosis, GE-Proton10-34, 2026-06-22)
- 4a4e2486-08f1-4436-c735-06b48ab7a682 (Geonosis, GE-Proton10-34, 2026-06-22)
- 40b6b7f7-2e66-49a4-e751-6d0f712dd609 (Geonosis, GE-Proton10-34, 2026-06-22)
- 133f5508-699b-4701-5567-85c09c427184 (Geonosis, Proton-Experimental, driver 58099, 2026-06-22)
- 2672d4dc-9a59-4f8f-1edf-12dd12708b1f (Kamino, GE-Proton10-34, ModLoader DISABLED, 2026-06-22)
- 707619c5-ed24-4abb-ee8d-05381e958b1c (Kamino, GE-Proton8-13/DXVK 2.2, 2026-07-04)
- 1a492cff-e88a-4a84-e33a-b91d02ea604b (Kamino, GE-Proton11-1, dxvk.conf enableContextLock, 2026-07-04)
- e86e866e-96d5-422d-a314-72ea3df1161f (Kamino, GE-Proton11-1, dxvk.conf disableMsaa+maxFeatureLevel, 2026-07-04)
What we ruled out:
- Networking / proxy / relay: server registers fine; the crash is the game process dying, not
a connection failure. Forcing IPv4 DNS (gai.conf precedence) on the host changed nothing.
- Mods: reproduces with a vanilla setup (no user mods).
- Map: reproduces on Geonosis and Kamino; every map crashes.
- DXVK / Proton version: identical crash on three different builds (GE-Proton10-34,
Proton-Experimental, GE-Proton8-13/DXVK 2.2). Not a version regression.
- dxvk.conf
d3d11.enableContextLock = True (targets a multithreaded texture-creation race,
the mechanism behind a fixed DXVK bug, #4613): no change.
- dxvk.conf
d3d11.disableMsaa = True + d3d11.maxFeatureLevel = 11_0 (targets an unsupported
MSAA sample count in the texture descriptor): no change.
- Kyber ModLoader: crash persists with the ModLoader confirmed disabled (see Description).
- The Linux launcher and the Maxima layer: the host launch path is identical to join up to the
DLL inject; the divergence is entirely after inject, in the game/DLL.
Where it looks like it lives: the host-only entry point is the listen-server construction
(Core/Server.cpp, "Constructing a 30hz server ... (Hooked: 1)"). Joining never constructs a
server and never crashes. The texture creation that fails is Frostbite's own, during host-side
level initialization. SettingsManagerApplyHk (the host render-settings override in
Core/Server.cpp) is installed for every non-dedicated client (join included), so it is
probably not the differentiator, but it forces a specific render config and runs in the same
path.
Open question for the team: when a listen server is started under Wine/DXVK, what render
texture does Frostbite create with a descriptor that DXVK rejects as E_INVALIDARG (likely an
invalid Width/Height/Format/MipLevels/ArraySize/SampleDesc combination), and does any Kyber
host/server hook influence the render state at that point? On native Windows the same host path
works, so this may be a Wine/DXVK validation difference that the host path triggers but the
client path does not.
What we cannot do on our side: the fix is in the runtime-downloaded Kyber.dll and/or the
Frostbite host render path. The Linux launcher fork cannot ship a Module change and has no
lever over the host-side level load or texture creation, and we are out of Proton/DXVK-side
things to try (three DXVK builds and two targeted dxvk.conf flags all crash identically). We
need either a Module/DLL fix, a host-render-path workaround you can deploy, or guidance on a
Wine/DXVK setting we have not thought of.
Description
Hosting a server crashes BF2 on Linux, every time, on every map. This is on the unofficial
Linux port of the Kyber launcher (BF2 runs through Wine/Proton via umu). Joining and playing
work fine for 30+ minutes on the same setup; only hosting is broken.
A few seconds after the listen server starts loading its level, Frostbite's own renderer calls
device->CreateTexture2D(...), which fails withE_INVALIDARG (0x80070057). Kyber catches thefault, uploads a Sentry crash, and the process terminates.
The failing
CreateTexture2Dcall is Frostbite's own (the error line comes from the engine'sown DX error handler, Kyber only captures it). We ruled out the Kyber ModLoader as the trigger:
launching with
KYBER_DISABLE_MODLOADER=1produces zero[ModLoader] Loading bundlelines(confirmed it never ran) and the host still crashes identically. So the bad texture descriptor
comes from the host-side / listen-server render path itself, not from Kyber's resource
reshaping.
Steps To Reproduce
0/N players), listen server starts loading the level.
[DXERROR] CreateTexture2D(...) failed with E_INVALIDARG,crash uploaded to Sentry, process terminates.
Expected Behavior
The host loads the level and stays up, same as on Windows, and same as joining as a client
on this exact setup (which renders fine for 30+ minutes).
Screenshots
Not applicable, there is no visual symptom before the crash. The relevant evidence is the
crash log below.
Additional Context
Environment:
starwarsbattlefrontii.exe, Origin.OFR.50.0002015), Frostbite.Exact error (logged by Frostbite, captured by Kyber):
The GPU adapter string is empty ("") at the moment of failure, though it is reported correctly
at init ("NVIDIA GeForce RTX 3060").
Host-side sequence right before the crash (kyber log):
Reproductions (Sentry crash IDs):
What we ruled out:
a connection failure. Forcing IPv4 DNS (gai.conf precedence) on the host changed nothing.
Proton-Experimental, GE-Proton8-13/DXVK 2.2). Not a version regression.
d3d11.enableContextLock = True(targets a multithreaded texture-creation race,the mechanism behind a fixed DXVK bug,
#4613): no change.d3d11.disableMsaa = True+d3d11.maxFeatureLevel = 11_0(targets an unsupportedMSAA sample count in the texture descriptor): no change.
DLL inject; the divergence is entirely after inject, in the game/DLL.
Where it looks like it lives: the host-only entry point is the listen-server construction
(
Core/Server.cpp, "Constructing a 30hz server ... (Hooked: 1)"). Joining never constructs aserver and never crashes. The texture creation that fails is Frostbite's own, during host-side
level initialization.
SettingsManagerApplyHk(the host render-settings override inCore/Server.cpp) is installed for every non-dedicated client (join included), so it isprobably not the differentiator, but it forces a specific render config and runs in the same
path.
Open question for the team: when a listen server is started under Wine/DXVK, what render
texture does Frostbite create with a descriptor that DXVK rejects as E_INVALIDARG (likely an
invalid Width/Height/Format/MipLevels/ArraySize/SampleDesc combination), and does any Kyber
host/server hook influence the render state at that point? On native Windows the same host path
works, so this may be a Wine/DXVK validation difference that the host path triggers but the
client path does not.
What we cannot do on our side: the fix is in the runtime-downloaded Kyber.dll and/or the
Frostbite host render path. The Linux launcher fork cannot ship a Module change and has no
lever over the host-side level load or texture creation, and we are out of Proton/DXVK-side
things to try (three DXVK builds and two targeted dxvk.conf flags all crash identically). We
need either a Module/DLL fix, a host-render-path workaround you can deploy, or guidance on a
Wine/DXVK setting we have not thought of.