I captured a PROTON_LOG=1 log this time, and it shows the causal chain explicitly, so I can point at a specific cause rather than just a symptom.

System

• CachyOS (Arch-based), native Steam
• Kernel 7.2.11-1-cachyos, x86_64
• AMD Ryzen 7 5700X; Radeon RX 7600 XT (Navi 33, 1002:7480), RADV
• Mesa 26.2.4, Vulkan 1.4
• Proton Experimental (also reproduced on 3 other builds — see below)

Root cause: Wine's WDFLDR.SYS is a builtin stub, so HoYoKProtect.sys fails to load

From the Proton log, in order:

trace:loaddll:build_module Loaded L"C:\windows\system32\HoYoKProtect.sys" at 0000000100400000: native
trace:loaddll:build_module Loaded L"C:\windows\system32\drivers\WDFLDR.SYS" at 00006FFFC1300000: builtin

fixme:wdfldr:WdfVersionUnbind L"\Registry\Machine\System\CurrentControlSet\Services\HoYoProtect" 0000000100449540 0000000000C24F78 stub!
trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=FFFFEFFFFF6BF0EE
trace:seh:dispatch_exception rax=00000000c0000355 ...
err:ntoskrnl:ZwLoadDriver failed to create driver L"\Registry\Machine\System\CurrentControlSet\Services\HoYoProtect": c0000355

fixme:ntdll:NtRaiseHardError 0x50000018 4 0x3 ...: stub

The game ships a kernel driver (HoYoKProtect.sys) and loads it natively. That pulls in Wine's WDFLDR.SYS, which is a builtin stub — WdfVersionUnbind is unimplemented. The driver then takes an access violation and ZwLoadDriver fails with c0000355. The game treats that as fatal.

c0000355 here matches the game's own driverError.log exactly:

initDriver Failed: Error [4,643,0].

(Also seen as [4,1114,0] on a different prefix state — same failure, different prefix config.)

So this is not graphics/DXVK/Vulkan/Unity — it's Wine's incomplete Windows Driver Framework support. The D3D11 device and the Wwise sound engine both initialize successfully before the failure:

Direct3D: Version: Direct3D 11.0 [level 11.1]  Renderer: AMD Radeon RX 7600 XT
WwiseUnity: Sound engine initialized successfully.
Crash!!!

The crash stack lines up with the driver failure

Player.log shows a stack entirely inside MHYPBase.dll (39 frames, 37 of them the same address — the signature of a recursive error path rather than a graphics or engine fault):

MHYPBase.dll (..., fileVersion: 1.0.1.1)
========== OUTPUTTING STACK TRACE ==================
0x00006FFFC2BB6A61 (mhypbase) (function-name not available)
0x00006FFFC2C44F00 (mhypbase) (function-name not available)   <- x37
...
0x00006FFFC146D414 (mhypbase) (function-name not available)

And the Wine-side unwind matches it:

warn:seh:virtual_unwind backtrace: 00006FFFC2B96A61: L"MHYPBase.dll" + 0000000001856A61.
warn:seh:virtual_unwind backtrace: 00006FFFC2C24F00: L"MHYPBase.dll" + 00000000018E4F00.   <- x37

i.e. MHYPBase calls into HoYoKProtect, the driver fails to start, and the module recurses into its own error handler until it faults.

Confirmed not Proton-version-specific

I tested four builds, on both reused and freshly rebuilt prefixes — identical failure every time (same 39 mhypbase frames, same MHYPBase.dll +0x1856A61 / +0x18E4F00):

I specifically tested Proton-CachyOS 11.0-20261015-slr because its release notes claim to fix ZZZ via winehq MR 11824. Its prefix was verified freshly built by that tool (config_info = CachyOS-11.0-100), and it crashes identically. Those notes scope the MR fix to Genshin Impact / Zenless Zone Zero CN editions, which use a different anti-tamper path than this global/Steam build — consistent with no change here.

Reproduction

1. Install 4162040 with any modern Proton, launch.
2. Process exits within seconds; no title screen.
3. Artifacts in .../compatdata/4162040/pfx/drive_c/users/steamuser/AppData/Local/Temp/miHoYo/ZenlessZoneZero/Crashes/Crash_<timestamp>/

Launched via HYP.exe and via ZenlessZoneZero.exe directly — same crash either way.

Timeline

mhypbase.dll (MD5 0657a7d7d3d47d27705e41f27a1bff5b, 26,754,424 bytes) and ZenlessZoneZero.exe in the depot are both stamped 2026-10-20 20:20, matching the 3.3 update. Crashes started immediately after; the game worked before. config.ini reports game_version=3.3.0, version_info = OSPRODWin3.3.0.

Worth noting this is a recurrence of a known class — the HoYoKProtect/MHYPBase failure also hit at 2.8.0 and 3.1 and was resolved upstream/server-side (see @vecipher's report above for the 3.1 case). Suggests the fix pattern already exists.

Evidence attached

Gist: https://gist.github.com/osmarios/625aa0cb89fe8af3b7d6a63354cc0e6b

• Player.log — game crash log (39 mhypbase frames)
• driverError.log — initDriver Failed: Error [4,643,0]
• proton-log-driver-failure.txt — pruned Proton log covering the wdfldr/HoYoKProtect failure and stack unwind (start here)
• steam-4162040.proton-log.xz.base64.txt — full Proton log, xz+base64 (base64 -d FILE | xz -d > steam-4162040.log)
• crash.dmp.gz.base64.txt — crash dump, gzip+base64 (base64 -d FILE | gunzip > crash.dmp)

@m1lkch4n flagging in case this is the same thing you saw — your report and this one look like the same regression, and 3.3 appears to have brought it back.

System

• Arch Linux, native Steam
• Kernel 7.2.9-zen1-1-zen, x86_64
• Intel i9-13900K; NVIDIA RTX 3090, proprietary driver 615.78.08
• Steam build 25596035, version_info = OSPRODWin3.3.0
• mhypbase.dll MD5 0657a7d7d3d47d27705e41f27a1bff5b (same file as above), HoYoKProtect.sys MD5 cb4a0060c4656a0f849913a43ce8cf36, unchanged since June

Every build fails on 3.3

Before 3.3 it was intermittent

On 3.2 with DW-Proton 11.0-10, roughly 1 launch in 6 died with the same initDriver Failed: Error [4,643,0], and a relaunch would work (7 failures between 10-10 and 10-19). Since 3.3 it's every launch. So 3.2 already had this code path. The update looks to have made it run every time rather than adding it.

WDFLDR binds fine; the driver backs out on its own

With WINEDEBUG=+timestamp,+pid,+tid,+loaddll,+ntoskrnl,+service,+reg,+wdfldr the bind succeeds:

trace:wdfldr:WdfVersionBind 0000000000C23ED0 L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\HoYoProtect" version 1.9.7600, 396 functions
trace:wdfldr:WdfVersionBind driver 0000000000C23ED0 bound successfully

DriverEntry then runs, allocates its pools, and writes its own status values to its service key over about 135ms:

trace:reg:NtSetValueKey (0x58,L"LastState",11,...)
trace:reg:NtSetValueKey (0x58,L"LoadTime",11,...)
trace:reg:NtSetValueKey (0x58,L"LastStatus",11,...)
trace:reg:NtSetValueKey (0x58,L"LastState",11,...)
trace:reg:NtSetValueKey (0x58,L"UnLoadTime",11,...)

Then it frees everything and unbinds:

fixme:wdfldr:WdfVersionUnbind L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\HoYoProtect" 0000000100449540 0000000000C24668 stub!
err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\HoYoProtect": c0000355

So I don't think the WdfVersionUnbind stub is the cause. By the time Unbind is called, the driver has already written UnLoadTime and freed its pools, so it's tearing down after deciding to fail. No traced kernel or WDF call fails before that. The LastStatus/LastState values it leaves behind aren't NTSTATUS codes and change on every launch (0x12b2a065 on one, 0x2712e665 on the next), so they look encoded rather than being a plain reason code.

Builds that don't ship wdfldr.sys fail one step earlier, as @m1lkch4n saw on Hotfix:

err:module:import_dll Library WDFLDR.SYS (which is needed by HoYoKProtect.sys) not found
err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\HoYoProtect": c0000142

MHYPBase chooses the driver path, and on a good launch it never does

A good 3.2 launch with the same tracing never touches the SCM. MHYPBase does its hardware/WMI checks and carries on. A bad launch goes straight from the code integrity query to the driver:

fixme:ntdll:NtQuerySystemInformation SystemCodeIntegrityInformation, size 8, info 0xfdf18, stub!
trace:service:OpenSCManagerW (null) (null) 0x20000000
trace:service:OpenServiceW ... L"HoYoProtect" 0x34
trace:service:DeleteService ...
err:service:validate_context_handle Access denied - handle created with access 34, needed 10000
trace:reg:RegQueryValueExW (...,L"LoadTime",...)
trace:reg:RegQueryValueExW (...,L"UnLoadTime",...)
trace:service:CreateServiceW ... L"HoYoProtect" L"HoYoProtect"
trace:service:StartServiceW ...

It makes no registry reads between mhypbase.dll loading and that OpenSCManagerW, so nothing in the prefix is steering it there. On 3.2 something (internal or server-side) picked the driver path now and then. On 3.3 it picks it every time. That fits with this being resolved on HoYoverse's side at 2.8.0 and 3.1, as mentioned above.

Logs

Gist: https://gist.github.com/Alphaproject1998/39e27ab06dc025f3cc68937e1cfe4d7b

Trace excerpts for a good 3.2 launch and a bad 3.3 launch, both full Proton logs, the HoYoProtect service key after a failure, and driverError.log. Hostname and audio device names are redacted.

I haven't modified the prefix or game files, or tried to bypass the anti-cheat.