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

[Bug 60225] FL Mafia Desktop 2.1.2 (Tauri app) crashes with page fault in ole32 at window creation

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60225 --- Comment #4 from germanshtyrov(a)gmail.com --- Root cause found, with a patch that fixes it. Please disregard the truncation guess in my first comment - that was wrong, there is no truncation involved. RegisterDragDrop stores the raw IDropTarget pointer in the window property "OleDropTargetInterface", and refuses windows owned by another process: GetWindowThreadProcessId(hwnd, &pid); if (pid != GetCurrentProcessId()) return DRAGDROP_E_INVALIDHWND; so that pointer is only ever valid inside the window's owning process. RevokeDragDrop (dlls/ole32/ole2.c) has no such check: drop_target = GetPropW(hwnd, prop_oledroptarget); if(drop_target) IDropTarget_Release(drop_target); IDropTarget_Release() dereferences the pointer to reach the vtable, which is the faulting instruction. When one process revokes a window that a different process registered, that read hits a foreign address. WINEDEBUG=+ole shows exactly that pairing - the WebView2 browser process registers, the host application process revokes the same window: 0188:trace:ole:RegisterDragDrop (000000000001009A,00001A64009A7D20) 00f4:trace:ole:RevokeDragDrop (000000000001009A) and in the resulting fault RAX is exactly that registered pointer while RBX is exactly that window: rax:00001a64009a7d20 rbx:000000000001009a ole32+0x35e48: movq (%rax), %rdx The application vendor independently confirmed the call path: Tauri calls OleInitialize and RegisterDragDrop during window creation, and their splash window - unlike their main window - does not disable it. This cannot be worked around by configuration. WebView2 is always out-of-process relative to its host application, so any Tauri application can hit it. I also tried forcing the WebView2 renderer and GPU in-process through the documented AdditionalBrowserArguments policy (--single-process): the internal children do collapse into one process (Chrome_InProcGpuThread and Chrome_InProcRendererThread appear), but the WebView2 browser process stays separate from the host and the crash is unchanged. Proposed fix - only release the raw pointer when the current process owns the window. The marshalled drop target and the window properties are cleaned up as before: --- a/dlls/ole32/ole2.c +++ b/dlls/ole32/ole2.c @@ -628,6 +628,7 @@ HRESULT WINAPI RevokeDragDrop(HWND hwnd) IStream *stream; IDropTarget *drop_target; HRESULT hr; + DWORD pid = 0; TRACE("(%p)\n", hwnd); @@ -643,8 +644,15 @@ HRESULT WINAPI RevokeDragDrop(HWND hwnd) if (!(map = get_droptarget_handle(hwnd))) return DRAGDROP_E_NOTREGISTERED; - drop_target = GetPropW(hwnd, prop_oledroptarget); - if(drop_target) IDropTarget_Release(drop_target); + /* The raw pointer in prop_oledroptarget is only valid in the process that + * called RegisterDragDrop, which is always the process owning the window. + * Releasing it from any other process dereferences a foreign address. */ + GetWindowThreadProcessId(hwnd, &pid); + if (pid == GetCurrentProcessId()) + { + drop_target = GetPropW(hwnd, prop_oledroptarget); + if(drop_target) IDropTarget_Release(drop_target); + } RemovePropW(hwnd, prop_oledroptarget); RemovePropW(hwnd, prop_marshalleddroptarget); Verified: I built Wine 11.0 with and without this change and ran the same application against both. Vanilla 11.0 crashes on every start, at the moment the splash window is destroyed. With the patch the application starts and keeps running; its own log gets past the point that used to be fatal: "close_splashscreen: main window shown" "close_splashscreen: splash destroyed" Patch script and the build workflow: https://github.com/G6rm0k/wine-ole32-fix One open question. Skipping the release when a foreign process revokes leaks the owner's reference. Mirroring RegisterDragDrop and rejecting the call outright with DRAGDROP_E_INVALIDHWND may be the more correct behaviour - I did not do that because it changes the return value for existing callers. Happy to redo it either way. -- 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. 23, 2026

[Bug 50323] Multiple applications need 'Ws2_32.getservbyname' to read information from '%SystemRoot%\System32\Drivers\Etc\services' (Autodesk 3ds Max 9 RaySat service)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=50323 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |d3138d711beedf3e06ac64f7eba | |d2d7f4d205c1a Resolution|--- |FIXED --- Comment #2 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Anastasius Focht from comment #1) > *** Bug 19102 has been marked as a duplicate of this bug. *** This is fixed: 030c:trace:winsock:getservbyname name "mi-raysat_3dsmax9_32", proto "tcp" ... 030c:trace:winsock:get_next_service parsing line "mi-raysat_3dsmax9_32 7504/tcp -- 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. 23, 2026

[Bug 60094] Marathon crashes on launch

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60094 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |2974626684216395a5059eb4b62 | |20683fc050b67 --- Comment #14 from Hans Leidekker <hans(a)meelstraat.net> --- Fixed by 2974626684216395a5059eb4b6220683fc050b67. -- 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. 23, 2026

[Bug 60226] Wine XInput: XInputGetState returns 0 buttons for connected Bluetooth Xbox One controller

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60226 --- Comment #1 from lifeartas1(a)gmail.com --- Confirmed real-world impact + working workaround, and where the fix belongs. This Wine XInput bug (enumerate-connected-but-never-map-input) is the root cause of a shipped-game failure: Kingdom Come: Deliverance II 1.5.6 (Bluetooth Xbox) never receives input on Linux. The game's xinput0 stays connected: 0 despite Wine XInput reporting the controller connected; the permanently-zero button state means the game sees no input and never connects the pad. Reproduces across Proton Experimental, GE-Proton, and Wine Staging 11.13, with real Bluetooth Xbox (xpadneo) and synthetic uinput devices — so it is Wine XInput, not any single game. Workaround (bypasses XInput): present the Xbox as a native DualSense and use the game's separate, working Sony HID (scepad0) path: InputPlumber ds5 UHID target + DisableHidraw=0 in the prefix. KCD2 then logs m_ControllerType: DualSense and input works. Details on Proton issue 8727. Suggested fix location: the fault is in Wine's XInput backend not feeding HID/evdev events into the returned XINPUT_STATE. Relevant code: dlls/xinput1_3/xinput_main.c / dlls/xinput1_3/xinput_hid.c and the bus enumeration in dlls/winebus.sys (unixlib.c) plus dlls/hidclass.sys. The controller IS enumerated (XInputGetState returns SUCCESS, packet increments) but XINPUT_STATE.Gamepad is never populated from the device's incoming HID/evdev reports. A dev would need to verify the HID report path from winebus.sys → xinput_hid.c for a Bluetooth (xpadneo, hid_xpadneo) device — the SDL path works but the native HID/evdev mapping into XINPUT_STATE does not. -- 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. 23, 2026

[Bug 54836] GrandMA3 onPC Version 1.9.2.2 page fault on startup (1.8.8.2 worked fine)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=54836 --- Comment #9 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Zeb Figura from comment #7) > (In reply to Swiftb0y from comment #6) > > Sure, what do you propose? > > It may be reasonable to treat any builtin DLL as signed. It may also be > reasonable to distribute packages with builtin DLLs signed by a signature > that Wine treats as trustworthy. Treating builtin dlls as signed introduces discrepancies such as missing security dll section and missing catalog hash. Wine distributors that make use of dll signing would need to override it. Wine already treats builtin dll signatures as trustworthy if the certificate chain leads to a trusted root CA but these signing certificates cost money and it seems unlikely that Linux distributions would take on this task. An alternative might be to include a script that generates a self-signed signing certificate when Wine is installed, signs Wine dlls with it and adds the corresponding CA to the local trust database. -- 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. 23, 2026

[Bug 60227] New: Legacy 10 antoi tämän virheilmoituksen lopetettaessa

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60227 Bug ID: 60227 Summary: Legacy 10 antoi tämän virheilmoituksen lopetettaessa Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: timo.t.tenhunen(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81927 --> http://bugs.winehq.org/attachment.cgi?id=81927 Legacy antoi tämän virheilmoituksen lopetettaessa Legacy 10 antoi tämän virheilmoituksen lopetettaessa -- 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. 23, 2026

[Bug 59188] wayland: Photoshop menu is overlapped by canvas (wrong z-order)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59188 Dmytro <lyushukovdmitry(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lyushukovdmitry(a)gmail.com -- 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. 23, 2026

[Bug 60226] New: Wine XInput: XInputGetState returns 0 buttons for connected Bluetooth Xbox One controller

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60226 Bug ID: 60226 Summary: Wine XInput: XInputGetState returns 0 buttons for connected Bluetooth Xbox One controller Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: xinput Assignee: wine-bugs(a)list.winehq.org Reporter: lifeartas1(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81926 --> http://bugs.winehq.org/attachment.cgi?id=81926 Complete Wine XInput probe output and stderr (wine-staging 11.13) plus evdev monitor capture of the connected Bluetooth Xbox One controller On a clean Wine prefix (default layout, no DLL overrides, no third-party DLLs), a standalone Windows XInput probe polling XInputGetState(0) reports the controller as CONNECTED (result == ERROR_SUCCESS) but the button/trigger/thumb-stick state is permanently zero — buttons=0x0000, rt=0, lt=0, lx=0, ly=0 — even while the physical buttons and D-pad are pressed. The kernel-level input IS delivered to the controller's evdev node (a monitor captures button/axis events), so the break is in Wine's XInput backend: it enumerates the controller but never maps incoming HID/evdev input into the XINPUT_STATE it returns. Environment: - Nobara Linux 44 (KDE Plasma), x86_64 - Kernel: 7.1.4-200.nobara.fc44.x86_64 - Wine: 11.13 (Staging), package wine-staging-11.13-1.x86_64 - Controller: Microsoft Xbox Wireless Controller (Bluetooth), VID 045e PID 0b13, fw 0522 - Driver: xpadneo (hid-xpadneo) Repro: 1. Connect an Xbox One Wireless Controller over Bluetooth (xpadneo). 2. Create a clean prefix: WINEPREFIX=/tmp/wine-clean wineboot -i 3. Run a minimal XInput probe (loop XInputGetState(0) ~800x over 8s) under it while pressing A / D-pad. 4. Observed: t=0 result=0 packet=1 buttons=0x0000, then done — no button changes ever. Expected: XInputGetState(0) returns the pressed button bits when physical buttons are pressed, matching Windows. Actual: returns result=0 (connected) but buttons=0x0000 permanently, while the same presses produce valid events at the kernel evdev layer. Attached: complete probe output + wine stderr + evdev monitor capture. -- 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. 23, 2026

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

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60219 --- Comment #1 from Béla Gyebrószki <gyebro69(a)gmail.com> --- I found four more games affected by the same regression: Art of Murder: Hunt for the Puppeteer Art of Murder: Cards of Destiny Chronicles of Mystery: The Scorpion Ritual Chronicles of Mystery: The Tree of Life All four use the same game engine. In these games the skin textures of all character models are rendered black. All four games are also available on Steam. -- 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. 23, 2026

[Bug 60204] AcceptEx broken for Unix-domain sockets

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60204 --- Comment #4 from Alisa Sireneva <me(a)purplesyringa.moe> --- I'm realizing my initial code analysis was wrong -- I assumed AF_UNIX sockets were part of the core Wine build, but they're actually in staging. The issue is that the ws2_32-af_unix patchset doesn't patch fill_accept_output in the commit where it patches getsockname and accept. -- 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. 23, 2026