August 2026 - Wine-Bugs - list.winehq.org

[Bug 60220] New: GetLastError() returns garbage after file API calls, breaking .NET exception mapping

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60220 Bug ID: 60220 Summary: GetLastError() returns garbage after file API calls, breaking .NET exception mapping Product: Wine Version: 10.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- SUMMARY GetLastError() returns a garbage value after several file API calls -- both after successful calls and, critically, on the failure return of failing calls, where the value is what distinguishes "file not found" from a genuine I/O error. Callers that branch on the error code therefore take the wrong path. Managed runtimes are hit hardest because .NET/Mono map the Win32 error to an exception TYPE: with a garbage code, .NET throws a generic IOException -- often with the nonsensical message "Success" (i.e. strerror(0)) -- instead of DirectoryNotFoundException or FileNotFoundException. Application code that catches the specific type to handle a benign case instead sees a fatal error. ENVIRONMENT Wine : 10.0 (Sikarugir build, Kegworks/WineskinNavy wrapper) OS : macOS 26, Apple M3 Max (arm64, x86_64 via Rosetta 2) App : Cities: Skylines II 1.6.0f1 (Unity 2022, Mono runtime) OBSERVED IN Directory.Delete(path, recursive: true) fails on a directory that deletes cleanly on Windows. In CoreFX's FileSystem.RemoveDirectoryRecursive, the post-loop error check after FindNextFile reads a garbage GetLastError (neither 0 nor ERROR_NO_MORE_FILES / 18) and throws BEFORE reaching the actual RemoveDirectoryInternal call, so the directory is never removed. The same class of failure appears in File.Delete, directory enumeration of a nonexistent path, and deletion of a path with an open handle (which should report ERROR_SHARING_VIOLATION). STEPS TO REPRODUCE A self-contained probe is attached; it needs no game install. It runs a small .NET assembly under the same Mono runtime the application uses. 1. Build monohost.exe from monohost.c (mingw-w64): x86_64-w64-mingw32-gcc monohost.c -o monohost.exe 2. Build the probe with the prefix's own C# compiler: wine "<prefix>/drive_c/windows/Microsoft.NET/Framework64/v4.0.30319/csc.exe" \ /out:filetest_net.exe filetest_net.cs 3. Run: WINEPREFIX=<prefix> wine 'Z:\path\monohost.exe' \ 'Z:\path\filetest_net.exe' 'C:\probe' 4. Read sections [5] [6] [7] and [10]-[13]. EXPECTED vs ACTUAL Directory.Delete(dir, recursive:true) on a populated directory expected : succeeds, directory removed actual : throws; directory remains Directory.GetDirectories(<nonexistent path>) expected : DirectoryNotFoundException actual : generic IOException, message "Success" File.Delete / Directory.Delete on a path with an open handle expected : IOException (sharing violation) actual : garbage error code File.Delete(<nonexistent file>) expected : silent no-op actual : throws, though the file is genuinely absent IMPACT Eight separate binary patches to mscorlib.dll and the application's own IO layer exist solely to make callers tolerate this. Any managed application doing routine filesystem work is affected. ADDITIONAL INFORMATION Linux/Proton does NOT reproduce this, which suggests it is specific to the macOS backend rather than to Wine's file layer generally. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60219] New: Ankh - Anniversary Edition: Some textures are rendered black

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60219 Bug ID: 60219 Summary: Ankh - Anniversary Edition: Some textures are rendered black Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: z.figura12(a)gmail.com Target Milestone: --- Regression SHA1: b10b7e61b58c5536a01e5438607f8fa12a1f7932 Distribution: --- Created attachment 81920 --> http://bugs.winehq.org/attachment.cgi?id=81920 black textures Some textures are rendered completely black instead of displaying their normal texture. The issue is visible in several locations in the game. Lowering Shadows and Texture Quality to their minimum settings reduces the number of affected surfaces somewhat, but does not eliminate the problem. I reproduced the issue with the GOG.com version of Ankh - Anniversary Edition. The game is also available on Steam, but I do not own that version. Unfortunately, I could not find a demo version of the game. I bisected the regression to commit: b10b7e61b58c5536a01e5438607f8fa12a1f7932 Reverting the commit on top of Wine-11.16 fixes the problem for me. NVIDIA GeForce GTX 1660 SUPER NVIDIA driver 610.57.04 OpenGL 4.6 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 54963] Adobe Lightroom needs Windows.Storage.Streams.InMemoryRandomAccessStream

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=54963 --- Comment #8 from Nikolay Sivov <bunglehead(a)gmail.com> --- This needs a retest with current wine 11.16, this API is now implemented https://gitlab.winehq.org/wine/wine/-/merge_requests/11297. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 46856] Exact Audio Copy: Unhandled exception at EACWnd2.264 -> INDEX-RANGE

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=46856 --- Comment #13 from nobodyimportant92(a)proton.me --- See https://gitlab.winehq.org/wine/wine/-/merge_requests/11631 for the MR that fixes this bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60218] New: Ground Control: Mouse movement is confined to a small area

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60218 Bug ID: 60218 Summary: Ground Control: Mouse movement is confined to a small area Product: Wine Version: 11.13 Hardware: x86-64 URL: https://www.moddb.com/games/ground-control/downloads/g round-control-install OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Target Milestone: --- Regression SHA1: 21f24279eea959a8ece2503fb6ce1300aabc957f Distribution: --- Some older games have broken mouse movement since commit 21f24279eea959a8ece2503fb6ce1300aabc957f Mouse works properly with the previous commit. Still present in Wine-11.16. The mouse cursor is usually confined to a limited rectangular area around the center of the screen and cannot be moved over the entire game screen. If I move the physical mouse fast enough, the cursor can sometimes escape from this area temporarily, but the problem soon returns. This makes some games difficult or impossible to use properly: edge scrolling no longer works in some games, and menus located at the top or bottom of the screen may be unreachable with the mouse. The problem occurs with the X11 driver, both in an X11 session (XFCE) and under XWayland. I cannot reproduce it with the native Wayland driver on KDE Plasma 6.7.4. Some affected games I have found so far: Empire Earth, Ground Control I-II, Arcanum, Clive Barker's Undying. Can be reproduced with Ground Control demo. Ground_Control_GSI.exe (468 M) md5: 1350f2b5b3d73bba4b01f048d0a3ae91 Ground Control shows an additional symptom when started. Initially, the mouse cursor is completely stuck in the center of the screen and cannot be moved at all, although the left mouse button still works.I have to Alt-Tab to another window (e.g. the terminal) and then Alt-Tab back to the game before the mouse cursor starts moving. After doing this, however, the main regression is still present: the cursor movement is confined to a limited area of the screen. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60217] New: Prefix update (wineboot -u) resets a customised "MS Shell Dlg 2" font substitute to Tahoma, while "MS Shell Dlg" is kept

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60217 Bug ID: 60217 Summary: Prefix update (wineboot -u) resets a customised "MS Shell Dlg 2" font substitute to Tahoma, while "MS Shell Dlg" is kept Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: loic.simond(a)protonmail.com Target Milestone: --- Distribution: --- Created attachment 81919 --> http://bugs.winehq.org/attachment.cgi?id=81919 Terminal output of the reproduction steps on wine-11.16 (clean prefix) A font substitute set by the user for "MS Shell Dlg 2" under HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes is reset to Tahoma every time the prefix is updated, that is at the first start of Wine after any Wine upgrade, or with "wineboot -u". The sibling "MS Shell Dlg" substitute survives the same update. Steps to reproduce, in a clean 64-bit prefix: export WINEPREFIX=~/wine-bugtest-fontsubst wineboot -i K='HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes' wine reg add "$K" /v "MS Shell Dlg" /t REG_SZ /d "DejaVu Sans" /f wine reg add "$K" /v "MS Shell Dlg 2" /t REG_SZ /d "DejaVu Sans" /f wineboot -u wine reg query "$K" | grep "MS Shell Dlg" Observed (wine-11.16, full terminal output attached): MS Shell Dlg REG_SZ DejaVu Sans MS Shell Dlg 2 REG_SZ Tahoma Expected: both values keep what the user set. A prefix update should not undo a font configuration, as it already doesn't for "MS Shell Dlg"; on Windows, FontSubstitutes is a system setting that upgrades leave alone. I hit this on a prefix where both substitutes had been changed to another face: after the upgrade to wine-11.16, dialogs asking for "MS Shell Dlg 2" were back to Tahoma, with nothing in the logs to explain it. The only way to notice is to re-read the registry after every upgrade. Analysis: the two values are written by two different mechanisms. "MS Shell Dlg" is written by win32u, in update_codepage() (dlls/win32u/font.c, lines 3105-3110 in wine-11.16), and only when the stored "Codepages" value changes — the code carries the comment "Only update these if the Codepage changed". "MS Shell Dlg 2" comes from loader/wine.inf.in, line 515: HKLM,%FontSubStr%,"MS Shell Dlg 2",,"Tahoma" with an empty flags field, so setupapi rewrites it on every DefaultInstall: a value is left alone only when the entry carries FLG_ADDREG_NOCLOBBER (dlls/setupapi/install.c, line 384). wine.inf.in already uses that flag (",2,") for more than a hundred entries users are expected to customise, such as file associations, but for none of the FontSubstitutes entries. Marking the entry NOCLOBBER ("MS Shell Dlg 2",2,"Tahoma") keeps the default for new prefixes and makes the two substitutes behave the same way. Alternatively the value could be written next to "MS Shell Dlg" in update_codepage(), under the same guard. Tested on wine-11.16 (Arch Linux package, x86_64, unmodified); the wine.inf.in line and the update_codepage() code are identical on current git master. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 59813] Recent LINE messenger don't start with "NO SIGNATURE".

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59813 --- Comment #6 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Lem from comment #5) > Are there any logs or tests I can do to help out with this? I can provide my > time. There's not much we can do I'm afraid. The apps checks the signature on crypt32.dll which fails because the dll isn't signed. To do that you would need a valid signing certificate (or a self-signed one and trust the CA locally). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 59813] Recent LINE messenger don't start with "NO SIGNATURE".

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59813 --- Comment #5 from Lem <liamlemage(a)gmail.com> --- Are there any logs or tests I can do to help out with this? I can provide my time. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60215] esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60215 --- Comment #3 from Aydar Kamaltdinov <aydar.kamaltdinov(a)gmail.com> --- Reproduced again with `WINEDEBUG=warn+all,err+all` and `WINEESYNC=1` as requested — full log attached (thief_wine_debug_full_crash_2026-08-22.log). Notable: this crash is at a *different* fault address than the one in the original report — `Shipping-ThiefGame.exe+0x11F2A9` this time vs `+0x11F9D9` previously — but the backtrace has the same overall shape (same offset ranges throughout: 0x6F0xxx, 0x109xxxx, 0x10Dxxxx, 0x4A1xxx/0x4A8xxx/0x4AAxxx, 0x11Cxxx, 0x3A9xxx, 0x352xxx, 0x871xxx/0x875xxx). Both are 100% reproducible at their own respective address across repeated runs, but differ from each other run-to-run in what looks like a small, non-deterministic way. This suggests it's not one single isolated null-check bug, but a whole class of similarly-shaped call sites that all assume a sync-object handle is valid. Also much clearer evidence of resource exhaustion this time — right after the crash, cascading `STATUS_INSUFFICIENT_RESOURCES` (c000011f) failures on completely unrelated operations: loading `steam.dll`, writing the engine's own crash dump (`Thief64_4158_2026.08.22-15.24.33.dmp`), and saving `ThiefEngine.ini`. All consistent with the process being genuinely out of file descriptors at that point, not just the one eventfd allocation that happened to matter. Confirmed reproduction on a second, different physical device (Snapdragon 8 Elite Gen 5, less extensively tested than the original Snapdragon 8 Elite device, but same crash behavior observed) — not specific to one SoC/device. Re: testing an old shared-wow64 build vs the new one (per bug 59897) — haven't tried this yet, happy to if you think it'd help narrow things down; let me know which build/version would be most useful to test. Side note, possibly useful, possibly a separate issue: with WINEESYNC=0 (or WINEFSYNC=1 as an alternative), the crash disappears but framerate drops from a stable 60fps to a hard 30fps — GPU-driver/DXVK-version independent, tried several combinations. Haven't dug into why yet; mentioning in case it's a known tradeoff or points at something else in the sync fallback path. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60215] esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60215 --- Comment #2 from Aydar Kamaltdinov <aydar.kamaltdinov(a)gmail.com> --- Created attachment 81918 --> http://bugs.winehq.org/attachment.cgi?id=81918 Thief crash log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026