http://bugs.winehq.org/show_bug.cgi?id=58584
Bug ID: 58584 Summary: msvcp140: Multiple modern applications using C++ Concurrency crash in CONCRT140.dll on startup Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: msvcp Assignee: wine-bugs@winehq.org Reporter: waser@waser.tech Distribution: ---
This report details a consistent, immediate startup crash in `CONCRT140.dll` affecting modern S.T.A.L.K.E.R. engine forks. These engines are based on the open-source **Open X-Ray 1.6**, which itself works flawlessly under Wine.
The crash only appears in these newer, more advanced forks which leverage the MSVC concurrency runtime for performance. This strongly indicates the issue lies within Wine's implementation of these APIs, not a bug in the engines themselves. This is effectively a regression, as the baseline engine works while the newer, concurrency-enabled versions do not.
**Existing Related Bugs:** This issue appears to be a new, highly reproducible test case for known problems in Wine's concurrency support. We are filing this as a new report due to the unique test case and the specific failure point (constructor vs. destructor), but it is likely caused by the same underlying issues as: - **Bug 52899:** Notes that `CONCRT140.dll` requires `CreateEventExW` from `kernel32`. This is the most likely root cause. - **Bug 41749:** Shows a crash in the destructor for `Concurrency::details::_TaskCollection`. Our crash occurs in the *constructor* of this same object, demonstrating a different failing code path.
Our report provides two clear methods to reproduce this crash, including one that is fully free and requires no commercial software.
---
### **Primary Reproduction Steps (IX-Ray on S.T.A.L.K.E.R.: Call of Pripyat)**
*(Steps 1-5 as in previous draft)*
6. **Run the Game with Debug Logging:** Launch the game using its main executable with full debug channels enabled. ```bash WINEDEBUG=+all wine Stalker-COP.exe &> stalker_cop_crash_all.log WINEDEBUG=+seh,+loaddll wine Stalker-COP.exe &> stalker_cop_crash_seh.log ``` 7. **Result:** The process will crash immediately. The game's own crash log (in `_appdata_ixray_/logs`) and the attached Wine debug logs will show a fatal error in `CONCRT140.dll`.
---
### **Alternative Reproduction Steps (AOEngine on S.T.A.L.K.E.R. Anomaly)**
This method is fully free and requires no commercial game assets.
1. **Download S.T.A.L.K.E.R. Anomaly:** Download the standalone game from its [ModDB page](https://www.moddb.com/mods/stalker-anomaly/downloads). 2. **Download AOEngine:** Download the latest AOEngine release from its [ModDB addons page](https://www.moddb.com/mods/stalker-anomaly/addons/aoengine). 3. **Install AOEngine:** Extract the contents into the Anomaly game's `bin` directory, overwriting `AnomalyDX11.exe`. 4. **Create a Clean Wine Prefix:** ```bash export WINEPREFIX=~/.wine_anomaly rm -rf $WINEPREFIX && wineboot -u ``` 5. **Install Runtimes:** ```bash winetricks -q vcrun2022 d3dcompiler_47 ``` 6. **Run the Game with Debug Logging:** Launch the game using the Anomaly launcher. ```bash WINEDEBUG=+all wine AnomalyLauncher.exe &> anomaly_crash_all.log WINEDEBUG=++seh,+loaddll wine AnomalyLauncher.exe &> anomaly_crash_seh.log ``` (Within the launcher, disable AVX, select DX11, disable the shader cache, and click Play). 7. **Result:** The exact same crash behavior as the IX-Ray method will be observed. The game's crash log will be in `_appdata_/logs` and the full Wine log will be `anomaly_crash_*.log`.
---
**Expected Behavior:** The game launcher should appear, and the game should launch to the main menu successfully, as it does on Windows and as the baseline Open X-Ray 1.6 engine does under Wine.
**Logs:** Three files will be attached for the primary reproduction case: 1. `stalker_cop_crash_seh.log`: A small log with `+seh,+loaddll` for quick initial review. 2. `stalker_cop_crash_all.log.bz2`: The complete `+all` debug log, compressed with bzip2 due to its large size. 3. `ixray-2025.08.10-02.37.21-waser.log`: The game's own crash log from its `_appdata_ixray_/logs` directory.
**References:** - **IX-Ray GitHub (Open Source Engine):** https://github.com/ixray-team/ixray-1.6-stcop - **GE-Proton Issue #197 (Full History):** https://github.com/GloriousEggroll/proton-ge-custom/issues/197
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #1 from Danny Waser waser@waser.tech --- Created attachment 79108 --> http://bugs.winehq.org/attachment.cgi?id=79108 Archive containing the logs files
My attachment was too big with the `+all` logs so here it is with only the seh and the game logs.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #2 from Danny Waser waser@waser.tech --- Oups, here are the missing steps (1-5) for the primary method:
1. **Install the Base Game:** Ensure S.T.A.L.K.E.R.: Call of Pripyat is installed. 2. **Download IX-Ray:** Download the latest release from the [IX-Ray GitHub Releases](https://github.com/ixray-team/ixray-1.6-stcop/releases). 3. **Install IX-Ray:** Extract the contents of the release archive into the game's root directory, overwriting all files when prompted. 4. **Create a Clean Wine Prefix:** ```bash export WINEPREFIX=~/.wine_stalker_cop rm -rf $WINEPREFIX && wineboot -u ``` 5. **Install Required Runtimes:** ```bash winetricks -q vcrun2022 d3dcompiler_47 ``` ...
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #3 from Danny Waser waser@waser.tech --- *** Bug 58583 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #79108|0 |1 is obsolete| |
--- Comment #4 from Danny Waser waser@waser.tech --- Created attachment 79109 --> http://bugs.winehq.org/attachment.cgi?id=79109 A small log with `+seh,+loaddll` for quick initial review.
No need to compress those small files. Here is wine logs.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #5 from Danny Waser waser@waser.tech --- Created attachment 79110 --> http://bugs.winehq.org/attachment.cgi?id=79110 The game's own crash log from its `_appdata_ixray_/logs` directory.
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |ArchLinux CC| |waser@waser.tech
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=52899
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=41749
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #79109|0 |1 is obsolete| |
--- Comment #6 from Danny Waser waser@waser.tech --- Created attachment 79111 --> http://bugs.winehq.org/attachment.cgi?id=79111 Wine logs using `WINEDEBUG=+seh,+loaddll`
Recomputed wine logs properly.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #7 from Danny Waser waser@waser.tech --- The log confirms the crash is an `EXCEPTION_ACCESS_VIOLATION` (c0000005) occurring at address `0x...C20EFBD`, which is inside the native `CONCRT140.dll` module loaded at `0x...C1F0000`.
Most importantly, just before the crash, the log shows a call to a semi-stubbed function:
``` 0134:fixme:heap:GetNumaHighestNodeNumber semi-stub: 000000000011FC20 ```
This strongly suggests that the crash is caused by the MSVC concurrency runtime receiving incomplete NUMA information from Wine, leading to an access violation when it attempts to initialize its thread pools. This reinforces the theory that the root cause is in Wine's implementation of modern CPU/memory features required by the concurrency runtime.
The `GetNumaHighestNodeNumber` function is expected to return the highest NUMA node number available on the system, which is crucial for applications that rely on NUMA-aware memory allocation and thread management.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #8 from Danny Waser waser@waser.tech --- Already implement a rough NUMA support in my `numa` branch of my fork of wine. Here is the commit: https://gitlab.com/wasertech/wine/-/commit/e29d3365554de1f643c69d8a876a8e18d...
Currently building it. Will try running the game with it and see...
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #9 from Danny Waser waser@waser.tech --- The above commit is wrong on so many levels.
Use https://gitlab.com/wasertech/wine/-/merge_requests/1/diffs to see an up to date diff with upstream's master branch.
If I can make it work, I can look into creating a proper PR.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #10 from Danny Waser waser@waser.tech --- My NUMA implementation in Wine is now complete and functional! It:
1. Correctly detects the system's NUMA topology via `GetLogicalProcessorInformation` 2. Accurately maps CPUs to NUMA nodes 3. Implements all necessary gaming features 4. Uses the appropriate Wine APIs (no Linux-specific code)
``` ❯ x86_64-w64-mingw32-gcc -o test_numa.exe test_numa.c && ./wine test_numa.exe 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. 00b8:fixme:wineusb:query_id Unhandled ID query type 0x5. Testing NUMA functions... GetNumaHighestNodeNumber: 1 GetNumaNodeProcessorMaskEx(0): Group=0, Mask=0x3f03f GetNumaNodeProcessorMaskEx(1): Group=0, Mask=0xfc0fc0 GetNumaProximityNodeEx(0): 0 GetNumaProximityNodeEx(1): 1
```
It need more work to be accurate but this should allow the game to boot with some luck.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #11 from Danny Waser waser@waser.tech --- Created attachment 79117 --> http://bugs.winehq.org/attachment.cgi?id=79117 Logs running the game using the numa patch for wine
I’ve re-tested S.T.A.L.K.E.R. – Call of Pripyat w/ IX-Ray under the current Wine git with my NUMA patch applied, and the game now actually launches (only in pure wine):
• Intros play correctly • The animated mouse cursor appears • Menu music can be heard
However the screen remains completely black once the menu is up. I’ve captured the Wine debug output (see attached `stalker_cop_crash_numawine.log`) and the most relevant lines are:
``` 0130:fixme:dxgi:dxgi_output_GetDesc1 iface … semi-stub! 0130:fixme:dxgi:dxgi_output_GetDisplayModeList … partial stub! 0130:fixme:d3d:wined3d_query_gl_create Unhandled query type 0x4. 01b4:fixme:d3d:state_linepattern_w Setting line patterns is not supported in OpenGL core contexts. ```
It looks like Wine’s DXGI and wined3d paths aren’t fully implemented yet for the game’s swap-chain / fullscreen setup. I suspect that once `dxgi_output_GetDesc1` and `GetDisplayModeList` are fully implemented (and perhaps additional wined3d present/swapchain methods), the scene should render correctly instead of remaining black.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #12 from Danny Waser waser@waser.tech --- Created attachment 79118 --> http://bugs.winehq.org/attachment.cgi?id=79118 Logs running the game using the numa patch for wine+dxvk27
To fix the above mentioned issues with DXGI, I tried to install DXVK v2.7 using winetricks but the game crashed with a new access violation (see attached `stalker_cop_crash_numawinedxvk.log`).
``` 0130:trace:seh:dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) flags=0 addr=00006FFFFC37A516 ... 0130:trace:seh:dispatch_exception rip=00006ffffc37a516 rsp=00007ffffe1ffbc0 rbp=00007ffffe1ffc29 ... 01bc:trace:seh:dispatch_exception code=406d1388 (EXCEPTION_WINE_NAME_THREAD) flags=0 addr=00006FFFFF3CD7C7 ``` That AV comes from inside `xrAbstractions.dll` (the game’s CPU/thread abstraction layer), not directly Wine code. It suggests that our NUMA-enabled thread-affinity calls or the corresponding WOW64 transition may still be off by a bit.
Could someone advise which kernel32/ntdll stubs or WOW64 boundary handling might still be missing for proper thread-affinity or TLS setup? Happy to provide gdb backtrace or further instrumentation if helpful. I can also attach a small patch of `memory.c` for the NUMA impl. if it's more convenient.
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #79117|0 |1 is obsolete| |
--- Comment #13 from Danny Waser waser@waser.tech --- Created attachment 79119 --> http://bugs.winehq.org/attachment.cgi?id=79119 Logs running the game using the numa patch for wine
Uploaded the wrong file, updated now. The other log with dxvk is correct.