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

[Bug 60429] New: Anno 1800: Closes immediately after launch since Wine 11.17
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60429 Bug ID: 60429 Summary: Anno 1800: Closes immediately after launch since Wine 11.17 Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: philipp.kloke(a)web.de Target Milestone: --- Distribution: --- Created attachment 82238 --> http://bugs.winehq.org/attachment.cgi?id=82238 Log with Wine 11.16 - Anno 1800 works Anno 1800 used to work very well with Wine 11.16. Since 11.17, also tested with 11.18 and 11.19, it does no longer start. The game successfully launches Ubisoft Connect. It even opens the games main window, switches to fullscreen and shows the cursor on a black screen. After a while, the game window closes and only Ubisoft connect remains open. Log files with working 11.16 and not working 11.19 are attached. -- 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.

1 4

[Bug 60559] New: dinput: Acquire() dispatches messages sent from other threads (Sudden Strike Gold crashes)
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60559 Bug ID: 60559 Summary: dinput: Acquire() dispatches messages sent from other threads (Sudden Strike Gold crashes) Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dinput Assignee: wine-bugs(a)list.winehq.org Reporter: winehqbmw(a)lsmod.de Target Milestone: --- Distribution: --- Created attachment 82424 --> http://bugs.winehq.org/attachment.cgi?id=82424 reproducer source Sudden Strike Gold (Steam 612300) crashes at startup with Proton 8.0 and later, with a NULL pointer read in Menu_Dll.dll. Proton 7.0 works a bit better, but has random crashes later. The crash happens when another process sends a message to the game window while the game is inside IDirectInputDevice::Acquire. Proton 8+ runs tabtip.exe, which sends WM_GETOBJECT to the focused window. In Wine, Acquire sends a message to dinput's internal input thread and waits for the reply. While it waits, it dispatches messages sent to the calling thread, so the game's window procedure runs from inside Acquire. The game doesn't expect that, and its startup ends up in a broken state. Unacquire behaves the same way. Native dinput doesn't do this. I checked on Windows XP SP3 with dinput versions 3, 5, 7 and 8, keyboard and mouse, foreground and background. The attached repro.c (produces repro.exe) sends WM_USER to its window from a second thread, calls Acquire, and prints how many times the window procedure ran during the call: Windows XP SP3: messages dispatched inside Acquire: 0 Wine 11.20 / Proton 10: messages dispatched inside Acquire: 1 The crash can be reproduced in plain Wine without tabtip.exe by running any program that repeatedly sends WM_GETOBJECT to the game window while it starts. -- 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.

1 0

[Bug 55405] New: FreeCommander crashing immediately after it starts, when Windows version is set above Windows XP
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=55405 Bug ID: 55405 Summary: FreeCommander crashing immediately after it starts, when Windows version is set above Windows XP Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: mywine(a)schiermeier-it.de Distribution: --- Created attachment 74965 --> https://bugs.winehq.org/attachment.cgi?id=74965 Console log from start of FreeCommander with Windows version set to v10 Installation of FreeCommander 32bit is working without any error. When it should start it crashes. Depending on the version Windows is set to, it behaves like this: Windows XP: works Windows 7: crash at the start with a stack overflow error, show in a message box Windows 10: a window came up and disappears immediately without any message (box) Console output for Windows 10 is attached. -- 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.

2 5

[Bug 27559] New: ImgBurn crash at startup when Wine's 'Windows Version' is set to 'Vista' (or newer)
by wine-bugs＠winehq.org Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=27559 Summary: ImgBurn crash at startup when Wine's 'Windows Version' is set to 'Vista' (or newer) Product: Wine Version: 1.3.22 Platform: x86 URL: http://www.imgburn.com/ OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lightning_uk(a)imgburn.com I've had a bunch of crash logs sent to me over the past year where ImgBurn crashes unrecoverably on startup when users are running it under Wine but was never able to reproduce the error until today. It turns out that if Wine's 'Windows Version' is set to 'XP' (default and what I'd always been using) everything works fine. The second it's changed to 'Vista' (or newer), the app crashes at startup. I've managed to get a crash call stack via madExcept / Eurekalog and have now traced the problem back to the 'Explorer' style component it uses in the 'Disc Layout Editor' window ('TVirtualExplorerTree' by MustangPeak). It looks like it's related to namespace stuff and therefore the shell? I've made/attached a Delphi demo app with a single form and single instance of 'TVirtualExplorerTree' to hopefully make testing and debugging this issue a little easier. Without fail, it'll crash when Wine's 'Windows Version' is set to 'Vista' but it's fine as 'XP'. I'm using Wine in Ubuntu 11.04 for testing. The programs (ImgBurn and demo app) work fine on a real Windows XP, Vista or 7 installation. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.

3 35

[Bug 60281] New: 32-bit installer crashes with stack overflow due to infinite loop in RtlUnwindEx (SEH unwinding) on macOS WoW64 build
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60281 Bug ID: 60281 Summary: 32-bit installer crashes with stack overflow due to infinite loop in RtlUnwindEx (SEH unwinding) on macOS WoW64 build Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: nileshkumbhar1604(a)gmail.com Target Milestone: --- Wine version: wine-11.16 (self-built from git, commit gcd22bd7383a) Build configuration: ./configure --enable-archs=i386,x86_64 --with-mingw Host: Mac mini M4 (Apple Silicon), running Wine under Rosetta 2 as x86_64. Steps to reproduce: 1. Build Wine from source with WoW64 support (`--enable-archs=i386,x86_64`). 2. Run a 32-bit Windows installer, for example: `./wine UltraViewer_setup_6.6.124_en.exe` 3. The installation starts and the "Installing UltraViewer" dialog appears. 4. The process then crashes with: `err:virtual:virtual_setup_exception stack overflow 1664 bytes addr 0x7bcfccd3 stack 0x130000-0x131000-0x230000` Running with `WINEDEBUG=+seh,+tid` shows that `RtlUnwindEx` is repeatedly called with the same `target_ip` (`00006FFFFDFB2E80`) and does not appear to make any progress. This continues until the thread stack overflows. I have attached the full trace. This initially looked similar to bug 58698, which also involved an infinite loop with the new WoW64 implementation. However, that issue was related to the `VirtualAlloc` size-probing logic and was fixed by commit `f4c5b04148db5fc4e5265beec461d3b7d9f4a789`. The problem described here still occurs with Wine 11.16, so it does not appear to be the same issue. A 64-bit-only build (`--enable-win64`, without WoW64) does not reproduce the problem, and 64-bit applications run normally. The issue therefore appears to be specific to the 32-bit-on-64-bit exception/unwinding path. It may also be related to the macOS/Apple Silicon environment, although I have not confirmed this yet. -- 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.

1 7

[Bug 60262] New: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60262 Bug ID: 60262 Summary: winemac.drv: macOS title bar drawn on frameless windows that reclaim the caption via WM_NCCALCSIZE, displacing all mouse input Product: Wine Version: 11.16 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)protonmail.ch Target Milestone: --- winemac.drv draws a macOS title bar on a window that reclaimed its caption area via `WM_NCCALCSIZE`, and the resulting geometry displaces all mouse input by the caption height. ## Reproducer 60 lines, no game or third-party app required: https://github.com/macgameport/cities-skylines-2-macos/blob/main/scripts/fr… ## Steps to reproduce 1. Build the attached 60-line reproducer: `x86_64-w64-mingw32-gcc -O2 -o frameless-repro.exe frameless-window-repro.c -lgdi32` 2. `wine frameless-repro.exe` It creates a `WS_OVERLAPPEDWINDOW` and, in `WM_NCCALCSIZE`, reserves a 5px border on the left, right and bottom and **zero** on the top — the frameless-but-resizable pattern used by Electron and CEF apps. `SWP_FRAMECHANGED` is applied after creation so the change takes effect. ## Expected `dx=5 dy=0` (border kept, caption reclaimed) and **no** title bar — the application declined the caption and draws its own chrome there. ## Actual The window reports `dx=5 dy=0` as expected, and winemac draws a macOS title bar with traffic lights anyway. Applications that draw their own title bar therefore show **two**. The knock-on effect is worse than cosmetic: the Cocoa content view ends up ~28pt shorter than the client rect Win32 reports, so `ScreenToClient` subtracts a window origin ~56px above where the NSWindow actually is. **Every control hit-tests below the visible pointer** — you must hold the cursor above a button to activate it. Measured on a real application (the Paradox launcher shipped with Cities: Skylines II): ``` Win32 window rect : 228,346 px = 114,173 pt Cocoa window drawn at : 232,402 px = 116,201 pt -> 56 px = 28 pt apart Cocoa window 1279 x 674 pt Cocoa content view 1279 x 642 pt -> a 32 pt title bar that should not exist Win32 client rect 1279 x 669.5 pt -> widths identical, heights 27.5 pt apart ``` Not a pointer-mapping bug — `GetCursorPos` agrees with macOS `CGEvent` to within truncation (`dx -0.4, dy -0.4 px`, pointer verified stationary by bracketing the reads). ## Analysis Two functions answer "does this window have a title bar" from different inputs, and nothing reconciles them: | caller | function | input | |---|---|---| | `macdrv_GetWindowStyleMasks` — win32u asks how much non-client space the window rect reserves | `get_window_features_for_style()` | **style bits only** | | window creation / style change — the actual Cocoa decoration | `get_cocoa_window_features()` | style bits **+ `data->rects`** | `get_cocoa_window_features()` already carries an evidence-based override — `EqualRect(&data->rects.window, &data->rects.visible)` — so the incompleteness of the style test was clearly known. But it never consults `rects.client`, which is precisely the record of what `WM_NCCALCSIZE` did, and `struct window_rects` carries it already. **That guard is also why this is not more widely noticed.** An application that reclaims the *entire* window rect gets `dx=0 dy=0`, `window == visible` fires, and the window is left undecorated — Steam's own client does exactly this and is unaffected. The bug needs a **border with no caption**, which is the more common Electron shape. ## What does not fix it Suppressing `title_bar` in `get_cocoa_window_features()` when `client.top == window.top` removes the doubled chrome but **not the offset**: `GetWindowStyleMasks` still reports caption masks, win32u keeps reserving the space, and the NSWindow simply moves down by it. Measured content-view vs client: 27.5pt apart before and after. A fix has to make both answers share one source of truth, and the ordering is the hard part — `GetWindowStyleMasks` is called *while* win32u is computing the very rects it would need to consult. ## Disclosure This was investigated with heavy AI assistance. I am filing a bug report rather than a patch, and the reproducer is deliberately small enough to confirm or dismiss in two minutes without taking my analysis on trust. -- 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.

1 7

[Bug 60375] New: Regression: Sojourn hangs due to timeout in ntdll/loader.c
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60375 Bug ID: 60375 Summary: Regression: Sojourn hangs due to timeout in ntdll/loader.c Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: zerooneo(a)01101001.net Target Milestone: --- Distribution: --- Created attachment 82160 --> http://bugs.winehq.org/attachment.cgi?id=82160 A log showing the timeout in the last two lines The game Sojourn has started hanging when the user starts playing after the main menu. As the game hangs, the log shows: 0254:err:vulkan:vkEndCommandBuffer section 00006FFFFFC4C460 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0254, blocked by 0124, retrying (60 sec) 0120:err:sync:RtlpWaitForCriticalSection section 00006FFFFFC4C460 "../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread 0120, blocked by 0124, retrying (60 sec) This started happening after commit 68474011825a98e9710240209d15b024b1dc6978 , "faudio: Import upstream release 26.09." The game is running with DXVK 2.4.1. -- 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.

1 5

[Bug 60304] New: Leverage deduplication for prefixes to reduce wasted storage space
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60304 Bug ID: 60304 Summary: Leverage deduplication for prefixes to reduce wasted storage space Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bokorbalazs(a)gmail.com Target Milestone: --- Distribution: --- A gentleman created an issue/feature request six years ago for proton, and the concluson was that it is not proton specific, it belongs to wine. Aeikum from CodeWeavers and maybe others were working on it: https://github.com/ValveSoftware/Proton/issues/4093 To sum up, there were already work invested but has stalled for unknown reasons. Maybe here this worthy feature request will move somewhere, and we will be provided some insight, what happened to this project. -- 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.

1 4

[Bug 60303] New: Singularity crashes after FAudio 26.09 import
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60303 Bug ID: 60303 Summary: Singularity crashes after FAudio 26.09 import Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: julliard(a)winehq.org, z.figura12(a)gmail.com Target Milestone: --- Regression SHA1: 68474011825a98e9710240209d15b024b1dc6978 Distribution: ArchLinux Created attachment 82053 --> http://bugs.winehq.org/attachment.cgi?id=82053 terminal output Singularity (2010, Activision) has a regression after the FAudio 26.09 import in Wine 11.17. I tested the GOG.com version of Singularity. I don't own the Steam version so don't know whether that version is affected as well (https://store.steampowered.com/app/42670/Singularity/) The game needs Nvidia Physx to be installed ('winetricks -q physx'). The game crashes at various points during startup or loading. The crash is not completely deterministic. The initial splash screens work correctly. After that, the crash may occur: - immediately when the main menu appears - during the loading screen after selecting "Continue Game" - when starting a new game, sometimes after the intro video has finished, when the "Saving content..." message appears. I could not obtain a Wine backtrace. Wine reports that it is starting the debugger, but no useful winedbg backtrace is produced. The game also creates an Unreal crash dump file after each crash (e.g. unreal-v4869-....dmp), but the generated .dmp files are always 0 bytes. I bisected the regression to: commit 68474011825a98e9710240209d15b024b1dc6978 faudio: Import upstream release 26.09. Reverting this commit on top of Wine 11.17 fixes the crashes completely. Still present in wine-11.17-54-g490f6d5dcbb -- 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.

1 6

[Bug 60270] New: Chrome 16 shows with the compositor's window decorations obscuring the tab bar
by WineHQ Bugzilla Oct. 22, 2026

Oct. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60270 Bug ID: 60270 Summary: Chrome 16 shows with the compositor's window decorations obscuring the tab bar Product: Wine Version: 11.16 Hardware: x86-64 URL: https://www.oldversion.com/windows/google-chrome/googl e-chrome-16-0-912-75-1/ OS: Linux Status: UNCONFIRMED Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: lingm+winebz(a)posteo.org Target Milestone: --- Distribution: ArchLinux Created attachment 81988 --> http://bugs.winehq.org/attachment.cgi?id=81988 obscured_tab_bar Pretty sure it's supposed to render custom window controls. Those currently show up in black, but that's bug 60269. In any case, the compositor's window decorations partially obscure the open tabs. Tested on kwin wayland in case it turns out to be relevant. > $ sha1sum chrome_installer_16.0.912.75.exe > b44af829b88ac422b3c3c8848b631c69bb5a463b chrome_installer_16.0.912.75.exe > $ du -h chrome_installer_16.0.912.75.exe > 24M chrome_installer_16.0.912.75.exe -- 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.

1 4