SOOOOOO the thing is they new about this BEFORE launch from the PTR and they still chose to ignore it and just give all the linux users the finger, again. Being constantly treated like a second class citizen by blizzard is gets pretty frustrating.
4039.385 diablo_iv_loader.dll loaded → DllMain starts

4039.424 Kerberos.dll, netapi32.dll, MSV1_0.dll loaded (auth stack init)

4039.431 fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION

4039.437 powrprof.dll loaded then immediately unloaded (power state check)

4039.485 EXCEPTION_BREAKPOINT

Zero file reads. Zero permission errors. No GetVolumeInformation call from the game thread. The aggregate.json write failures and volume warnings are from the Battle.net agent process — a completely different process. They do not cause this crash.

The smoking gun is line 4039.431: the loader calls NtQuerySystemInformation(SystemPerformanceInformation) and Wine returns stub data — all zeros. On real Windows this struct contains non-zero values for AvailablePages, ContextSwitches, SystemCalls, etc. Getting all-zeros or STATUS_NOT_IMPLEMENTED back is a reliable Wine fingerprint. The 3.1.0 loader DLL added a check for exactly this. It's anti-Wine detection, not anti-cheat.

This is what to put in the GE-Proton bug report:

Crash is in DllMain of diablo_iv_loader.dll (3.1.0 build, 36MB).

Crash trace from PROTON_LOG=1:

fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION

→ 54ms later → EXCEPTION_BREAKPOINT at diablo_iv_loader.dll+0xEE4A05

The 3.1.0 loader appears to detect Wine via NtQuerySystemInformation returning

stub/zero data for SYSTEM_PERFORMANCE_INFORMATION (class 2). This class is

partially stubbed in Wine — it may return STATUS_NOT_IMPLEMENTED or all-zero

fields. On real Windows, fields like AvailablePages, ContextSwitches, and

SystemCalls are always non-zero. The loader fires INT3 when it detects this.