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.
http://bugs.winehq.org/show_bug.cgi?id=58584
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |major
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, | |https://bugs.winehq.org/sho | |w_bug.cgi?id=41749 |
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #14 from Danny Waser waser@waser.tech --- Created attachment 79138 --> http://bugs.winehq.org/attachment.cgi?id=79138 Pure wine logs (no winetricks install)
Note to self: always double check sources provided by LLMs..
So the so called "related issues" are completely unrelated. Thanks Gemini... Anyways when I was looking myself on the bugtracker I found https://bugs.winehq.org/show_bug.cgi?id=40500 which is the same issue I get if I try in pure wine without installing anything using winetricks (see attached logs).
With builtin concrt140 on current Wine master (WoW64 experimental), launching S.T.A.L.K.E.R. Call of Pripyat immediately aborts on:
unimplemented function concrt140.dll.??0_TaskCollection@details@Concurrency@@QEAA@XZ
This matches bug 40500 (same missing TaskCollection constructor, 64‑bit flavor). Repro:
1. Fresh 64-bit prefix. 2. Ensure no native VC runtimes (remove vcrun2015/2019/2022). 3. WINEDLLOVERRIDES="concrt140,msvcr120=b" wine Stalker-COP.exe 4. Crash with the unimplemented constructor message above.
Marking this ticket as a duplicate of 40500.
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED
--- Comment #15 from Danny Waser waser@waser.tech --- Dup of 40500
*** This bug has been marked as a duplicate of bug 40500 ***
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #16 from Danny Waser waser@waser.tech --- Created attachment 79218 --> http://bugs.winehq.org/attachment.cgi?id=79218 (abridged) Logs running the AOE using the numa patch for wine
Update: progress report
I can now run Anomaly (AOE) under plain Wine (not even Staging). Build details: I used the tkg build scripts with NTsync enabled (but neither should be needed) and tested my NUMA late patch (based on my NUMA branch). The game launches and runs fine — there are still a few Wine stubs left to tidy up, but none of them block AOE at this point.
About IX‑RAY: I expect the same NUMA/Concurrency work will help IX‑RAY, but the engine also relies on additional “DX11+” features. I tested with VKD3D’s partial DX12 support and hit an unrelated blocker: IX‑RAY calls an NVAPI export that is missing (function id 412753887) in the NVAPI DLL. So the IX‑RAY failure is a separate issue from the NUMA/Concurrency changes.
Attached, you'll find the shortened log of my first successful run of the AOE under wine and in my next comment I'll add the numa.mylatepatch for your convenience.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #17 from Danny Waser waser@waser.tech --- Created attachment 79219 --> http://bugs.winehq.org/attachment.cgi?id=79219 My NUMA late patch
Simply drop the attach patch in `wine-tkg-git/wine-tkg-userpatches/`, configure your build and start the process. It should prompt you to apply the patch before compiling wine. You can obviously apply the patch yourself or even build wine from my numa branch direcly.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #18 from Danny Waser waser@waser.tech --- Update: Encountering NTsync’s “nasty beast” and DLL modification insights
Funny story: while experimenting with NTsync, I managed to stumble into one of those infamous Wine concurrency edge cases:
``` 0398:err:sync:RtlpWaitForCriticalSection section 00000000DE985360 "?" wait timed out in thread 0398, blocked by 0418, retrying (60 sec) ```
I suspected something interesting might happen, but I definitely underestimated how disruptive it would be — shutting down my system became so tricky I had to resort to drastic measures.
Another amusing discovery: Proton actually patches the affected DLLs to sidestep this issue entirely. That explains why so many users seemed confused about these deadlocks — they simply never encountered them, thanks to Proton’s workaround.
Personally, I prefer to keep the DLLs as close to their original state as possible. In this case, it makes much more sense to have the compatibility layer (Wine) expose the hardware topology directly to native Windows APIs. After all, the Linux kernel already provides this information; we just need Wine to reformat and present it correctly for Windows compatibility.
Sometimes, the best solution is not to patch around the symptom, but to let the system’s real capabilities shine through.
http://bugs.winehq.org/show_bug.cgi?id=58584
--- Comment #19 from Danny Waser waser@waser.tech --- With AOE handled, I focused on IX‑Ray and found the issue: my NVAPI shim is missing NVAPI_GPU_GetUsages from the nvapi DLL. Because IX‑Ray is open source, it was far simpler and cleaner to make that call optional in the engine than to try to stub the API in dxvk‑nvapi.
I opened a PR with the change: https://github.com/ixray-team/ixray-1.6-stcop/pull/181. Within the hour I had a patched executable of IX‑Ray that now runs perfectly on my machine. Kudos to the IX-Ray team for their reactivity.
With `numa.mylatepatch` applied, both games now run perfectly on mainstream Wine — no modifications to dynamic libraries needed.
http://bugs.winehq.org/show_bug.cgi?id=58584
Danny Waser waser@waser.tech changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #79219|0 |1 is obsolete| |
--- Comment #20 from Danny Waser waser@waser.tech --- Created attachment 79331 --> http://bugs.winehq.org/attachment.cgi?id=79331 My NUMA node count late patch
Cleanup patch from https://gitlab.winehq.org/wine/wine/-/merge_requests/8995/diffs. You only really need it if you have more than one node on your system anyway.