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

[Bug 60475] New: cmd: quoted redirection target of a built-in in a pipe is interpreted differently from Windows 11
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60475 Bug ID: 60475 Summary: cmd: quoted redirection target of a built-in in a pipe is interpreted differently from Windows 11 Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs(a)list.winehq.org Reporter: strucc.c(a)gmail.com Target Milestone: --- Distribution: Debian Quoting interpretation mismatch in cmd.exe between Windows 11 and WINE: --- mkdir "d x" // BOTH: "d x" directory created // Built in command after "|" echo| set /p v="1.0" > "d x\a.txt" // WIN11: file "a.txt" written inside "d x" (content 1.0) // WINE: file "d" written in the current folder (content 1.0) // External command after "|" (no mismatch) echo hi | sort > "d x\b.txt" // WIN11: "d x\b.txt" written correctly // WINE: "d x\b.txt" written correctly --- Windows 11: cmd.exe 10.0.22631.4541. Wine: 11.19 Affected application: CODESYS V3.5 SP22 Patch 4. (not needed to reproduce the bug) Description: The post-install script of its Visualization package writes a repository marker with echo| set /p version="1.0" > "%~1\Visual Elements\formatinfo"; under WINE the file lands as ...\CODESYS\Visual and the Visualization Toolbox of the IDE stays empty. Additional information: See: https://github.com/Re-CODESYS/codesys-wine for details, and fix -- 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 60485] New: wininet: after a redirect to https on another host, later requests on the same connection handle go to that host on port 443 without TLS
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60485 Bug ID: 60485 Summary: wininet: after a redirect to https on another host, later requests on the same connection handle go to that host on port 443 without TLS Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)list.winehq.org Reporter: ti.mue.1010109(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82332 --> http://bugs.winehq.org/attachment.cgi?id=82332 Test program When a request gets redirected (302) from http to https on a different host, HTTP_HandleRedirect writes the new host and port into the shared session (the InternetConnect handle), but INTERNET_FLAG_SECURE only goes on the redirected request. Every later HttpOpenRequest on the same connection handle then goes to the redirect's host on port 443 as plain HTTP (Host header "host:443"). An https server resets the connection, and the request fails with ERROR_INTERNET_CONNECTION_ABORTED (12030). Real-world case: TrackMania United Forever downloads custom skins through one InternetConnect handle to united.tm-exchange.com:80. That site redirects to https://tmuf.exchange/. Only the first skin per track arrives and all others fail, so the in-game signs stay blank. Same result with Proton (wine-11.0 based), reported there: https://github.com/ValveSoftware/Proton/issues/467#issuecomment-6109833098 Test program (attached, redirect_reuse.c): one InternetConnect to united.tm-exchange.com:80, then three GET requests through it. Each one answers 302 with Location: https://tmuf.exchange/... For comparison it then sends the same three with a new connection handle each time. The flags are the game's: INTERNET_FLAG_RELOAD | INTERNET_FLAG_NO_CACHE_WRITE | INTERNET_FLAG_KEEP_CONNECTION | INTERNET_FLAG_PRAGMA_NOCACHE. Build and run: i686-w64-mingw32-gcc -O2 -o redirect_reuse.exe redirect_reuse.c -lwininet wine redirect_reuse.exe Output with wine-11.19 (fresh prefix): A) one connection handle for all requests: /special/signpack/BD-Right_2.zip status 200, 96802 bytes (request Host: tmuf.exchange) /special/signpack/BD-Right-135.zip HttpSendRequest FAILED, error 12030 (request Host: tmuf.exchange:443) /special/signpack/BD-Slow.zip HttpSendRequest FAILED, error 12030 (request Host: tmuf.exchange:443) B) a new connection handle per request (control): /special/signpack/BD-Right_2.zip status 200, 96802 bytes (request Host: tmuf.exchange) /special/signpack/BD-Right-135.zip status 200, 96867 bytes (request Host: tmuf.exchange) /special/signpack/BD-Slow.zip status 200, 94027 bytes (request Host: tmuf.exchange) The +wininet trace (excerpt attached) shows the second request built for "tmuf.exchange:443" with "Host: tmuf.exchange:443" and no TLS. Then "read_line read failed 10054" follows. Code: dlls/wininet/http.c, HTTP_HandleRedirect, sets session->hostName and session->hostPort, but sets INTERNET_FLAG_SECURE only in request->hdr.dwFlags: https://gitlab.winehq.org/wine/wine/-/blob/wine-11.19/dlls/wininet/http.c#L… Not tested on Windows. As far as I know the game downloads all skins there, so I'd expect native wininet to leave the connection handle's server alone on a redirect (or at least keep it consistent with the secure flag). -- 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 3

[Bug 57175] New: Multiple issues with Audacity after upgrading to Wine 9.17
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=57175 Bug ID: 57175 Summary: Multiple issues with Audacity after upgrading to Wine 9.17 Product: Wine Version: 9.17 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Created attachment 77073 --> https://bugs.winehq.org/attachment.cgi?id=77073 Audacity 3.6.3 in Wine 9.17 with DPI=144 and classic Windows theme After I upgraded Wine from version 9.10 to 9.17, Audacity has become horrible to use and look at. I've always been using DPI=144 because I have a High DPI 14" monitor. So, * Fonts in Audacity have become much smaller than they were before * Fonts now look very blurry A screenshot will be attached. On the outside of Audacity you can see IrfanView which continues to scale properly and fonts are rendered just fine. -- 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 49

[Bug 58572] New: wine crashes on the wayland driver when virtual-keyboard-unstable-v1 is used
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=58572 Bug ID: 58572 Summary: wine crashes on the wayland driver when virtual-keyboard-unstable-v1 is used Product: Wine Version: 10.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: azulbeae(a)icloud.com Distribution: --- https://wayland.app/protocols/virtual-keyboard-unstable-v1 This protocol is used by basically every wayland native/supported on-screen virtual keyboard, and by tools like https://git.sr.ht/~brocellous/wlrctl or https://github.com/atx/wtype Whenever virtual keyboard protocols are used when winewayland.drv is in use, wine immediately crashes. To replicate the issue, install wlrctl or wtype, then make them type any string while wine is running. -- 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 8

[Bug 49819] New: EveMon (v 4.0.18.4979): (with dotnet461) crashes on add character
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=49819 Bug ID: 49819 Summary: EveMon (v 4.0.18.4979): (with dotnet461) crashes on add character Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: httpapi Assignee: wine-bugs(a)winehq.org Reporter: maxwellc(a)gmail.com Distribution: --- Created attachment 68155 --> https://bugs.winehq.org/attachment.cgi?id=68155 Report from EVEMon of the problem Program: EVEMon 4.0.18.4979 (https://appdb.winehq.org/objectManager.php?sClass=application&iId=9346) Download Link: https://github.com/peterhaneve/evemon/releases/tag/4.0.18 60c649699694060f0175e5830e9381ad9189593a EVEMon-install-4.0.18.exe Wine Version is both 5.0 Ubuntu and 5.16 Setup: Following suggestion in https://appdb.winehq.org/objectManager.php?sClass=version&iId=29658 Prior to upgrade to 5.16 from devel repo, winetricks dotnet461 corefonts >From Linux Command line wine /tmp/EVEMon-install-4.0.18.exe Click through installation prompts. Offers to launch on conclusion. Exited. WINEDEBUG='fixme+all,err+all' wine "Program Files/EVEMon/EVEMon.exe" Program runs but attempting to perform File->Add Character crashes the program. Program brings up report on the problem attached as "EveMonCrashOwnWords.log" Second attachment of output with WINEDEBUG="err+all,warn+all,fixme+all" Unable to reproduce on clean 5.16 prefix since winetricks dotnet461 "is broken since 5.12" -- 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 9

[Bug 60443] New: ncrypt: Support importing ECDSA key blobs.
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60443 Bug ID: 60443 Summary: ncrypt: Support importing ECDSA key blobs. Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: auzy83(a)gmail.com Target Milestone: --- Distribution: --- Symptom: `NCryptImportKey` with `BCRYPT_ECCPRIVATE_BLOB` or `BCRYPT_ECCPUBLIC_BLOB` fails with `Unhandled key magic`. Wine today: - `dlls/ncrypt/main.c`: `NCryptImportKey` handles only RSA magics. - The internal `enum algid` has `ECDSA_P256` but no P-384 or P-521. - EC key objects have no `NCRYPT_ALGORITHM_PROPERTY` and no `NCRYPT_ALGORITHM_GROUP_PROPERTY`, which callers need to choose an export blob type. - `include/ncrypt.h` lacks `MS_KEY_STORAGE_PROVIDER` and the `NCRYPT_*_ALGORITHM_GROUP` strings ("RSA", "DH", "DSA", "ECDSA", "ECDH") that the Windows SDK header defines. Should do: - Import ECDSA P-256, P-384 and P-521 public and private blobs, by handing them to bcrypt. - Set the name, group, length and public-key-length properties on the new key. - Add the missing header definitions in their own commit. Confirm on Windows: - The property values for imported EC keys: `Algorithm Name` is "ECDSA_P256", or "ECDSA" on newer Windows with curve-generic keys. - Whether ECDH magics are accepted too, and what the group is then. - That `NCryptExportKey` round-trips the imported blob. Software Affected: Control4 Composer Pro -- 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 1

[Bug 60014] New: Opening PDF portfolio in Acrobat XI hangs
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=60014 Bug ID: 60014 Summary: Opening PDF portfolio in Acrobat XI hangs Product: Wine Version: 11.13 Hardware: x86-64 URL: https://web.archive.org/web/20200522053748/http://ardo wnload.adobe.com/pub/adobe/reader/win/11.x/11.0.04/en_ US/AdbeRdr11004_en_US.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: imwellcushtymelike(a)gmail.com Target Milestone: --- Distribution: --- Opening a sample PDF portfolio¹ in Acrobat XI hangs the application. Windows 10: - Open PDF - Click cancel to the Flash dialog - Black PDF, but the application remains useable. Wine 11.13: - Open PDF - Click the right-most button ("Cancel": see Bug 59993) - Acrobat hangs and has to be killed. ¹ https://web.archive.org/web/20170830042616/http://wwwimages.adobe.com/www.a… Bug 34665 states that riched20 can be used to avoid a crash, but it makes no difference in this case. allfonts also has no effect. Patch from Bug 59977 has no effect. In Win32: - winetricks mspatcha times (Bug 12501 & Bug 59997) - wine AdbeRdr11004_en_US.exe /sPB /l - wine 'c:\program files\adobe\reader 11.0\reader\acrord32.exe' combine-pdf-files-portfolio-sample.pdf sha1sum: 9c295c16d374735bf292ef6c630c9ab392c22500 AdbeRdr11004_en_US.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 2

[Bug 57909] New: Star Citizen WineWayland Cursor Warping
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

https://bugs.winehq.org/show_bug.cgi?id=57909 Bug ID: 57909 Summary: Star Citizen WineWayland Cursor Warping Product: Wine Version: 10.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)winehq.org Reporter: mactan(a)edgetransit.dev Distribution: --- star citizen has a cursor warp issue on wayland that spins the camera down to stare at the ground or the cursor's last position on mouse move observed behavior on 10.2 mainline nonstaging winewayland session. cursor flickers instead of being held and the cursor does not warp to center when the interact key is held, and the camera warps to the cursors last position https://youtu.be/rkWaCgDNZeo https://youtu.be/hvb-BOVlsew these are examples of the expected behavior as observed on 10.2 x11 session, when the interact key (default F) is held, the cursor warps to the middle of the screen and the user can move the cursor freely from there. upon release and holding again, cursor warps to center when the key is held https://youtu.be/5cfveNGmHRI https://youtu.be/NKBSWfQrfCw observed behavior on 10.2 wayland xwayland session. the cursor does not warp to center when the interact key is held, and the camera warps to the cursors last position https://youtu.be/9I3g-fbxMUQ https://youtu.be/MAm85csb4Lk observed behavior with patches !7352 !7353 !7368 !7457 !7475 applied. cursor flickers instead of being held and constantly warps to the display center instead of being allowed to move about the screen after the initial warp. attached log with +waylanddrv,+win https://youtu.be/XxRbAljl49w https://youtu.be/RyS8UjzH9hs -- 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 8

[Bug 59993] New: Acrobat Reader DC preferences dialog is unusable
by WineHQ Bugzilla Oct. 12, 2026

Oct. 12, 2026

http://bugs.winehq.org/show_bug.cgi?id=59993 Bug ID: 59993 Summary: Acrobat Reader DC preferences dialog is unusable Product: Wine Version: 11.12 Hardware: x86-64 URL: https://ardownload2.adobe.com/pub/adobe/reader/win/Acr obatDC/2001320064/AcroRdrDC2001320064_en_US.exe OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: imwellcushtymelike(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81397 --> http://bugs.winehq.org/attachment.cgi?id=81397 Screenshot The preferences dialog is unusable in Adobe's Acrobat Reader DC. 32-bit wineprefix: - mspatcha (Bug 12501) - wine AcroRdrDC2001320064_en_US.exe /sPB /l - wine reg add "HKCU\Software\Adobe\Acrobat Reader\DC\Privileged" /v bProtectedMode /t REG_DWORD /d 0 /f (Bug 59985) - wine 'c:\program files\adobe\acrobat reader dc\reader\acrord32.exe' - Edit --> Preferences (or CTRL+K) Screenshot attached. 0024:fixme:oleacc:AccPropServices_SetHwndProp (00020264 4294967292 0 {cb905ff2-7bd1-4c05-b3c8-e6c241364d70} 0032B120 {VT_I4: 20}) 0024:err:comboex:COMBOEX_WindowProc unknown msg 042a, wp 0x50000, lp 0x2027c https://ardownload2.adobe.com/pub/adobe/reader/win/AcrobatDC/2001320064/Acr… http://web.archive.org/web/20260706223227/https://ardownload2.adobe.com/pub… sha1sum: c908742e4f456742dc6c3e863dea80fe68925e53 -- 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 2

[Bug 60482] New: MsgWaitForMultipleObjects with invalid handles behaves differently than Windows when a window is created
by WineHQ Bugzilla Oct. 11, 2026

Oct. 11, 2026

http://bugs.winehq.org/show_bug.cgi?id=60482 Bug ID: 60482 Summary: MsgWaitForMultipleObjects with invalid handles behaves differently than Windows when a window is created Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: j20001970(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82324 --> http://bugs.winehq.org/attachment.cgi?id=82324 Test code for MsgWaitForMultipleObjects Calling MsgWaitForMultipleObjects with invalid handles and QS_POSTMESSAGE/QS_ALLPOSTMESSAGE mask results in different behavior from Windows if a window is created. After a window is created, MsgWaitForMultipleObjects will return WAIT_FAILED with ERROR_INVALID_HANDLE on Wine, while on Windows it will return WAIT_OBJECT_0+nCount without error. If no window is created, both Wine and Windows will behave the same. (Returning WAIT_FAILED with ERROR_INVALID_HANDLE error) Tested with Wine 11.19 (commit a15ee2ccf20e2fc9f470badd916855801933d31f) on and Windows 10 22H2. -- 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 2

[Bug 60483] New: PRO100 CAD: dimension/label text broken (GDI glyphs via GetGlyphOutlineW into OpenGL) — OK on Ubuntu 24.04, broken on Ubuntu 26.04
by WineHQ Bugzilla Oct. 11, 2026

Oct. 11, 2026

http://bugs.winehq.org/show_bug.cgi?id=60483 Bug ID: 60483 Summary: PRO100 CAD: dimension/label text broken (GDI glyphs via GetGlyphOutlineW into OpenGL) — OK on Ubuntu 24.04, broken on Ubuntu 26.04 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: sylwek1716(a)gmail.com Target Milestone: --- Distribution: --- Hello, I am reporting a severe regression with 2D dimension numbers and labels in PRO100 (furniture CAD by Écru / pro100.eu), version 7.05 (64-bit). The same application works correctly on an older host stack and fails on a newer one. Changing the Wine runner alone does not fix it. === Working reference (control machine) === - Host: Ubuntu 24.04.5 LTS - Wine: wine-9.0 (Ubuntu package 9.0~repack-4build3) - Desktop: GNOME - GPU: Intel integrated (DRI3 / Mesa stack of 24.04) - Result: dimension text and labels render correctly over the 3D scene === Failing machine === - Host: Ubuntu 26.04.1 LTS (kernel 7.0.0-38-generic) - Session: Wayland (GNOME; previously also reproduced under KDE Plasma 6 / XWayland) - Wine / Bottles runners tested (all FAIL the same way for dimensions): - wine-8.0.2 (Kron4ek) - soda-9.0-1 (Wine 9 TkG / Bottles) - caffe-10.x - soda-11.x - GPUs / GL backends on the failing host (same missing dimension text, different visual failure mode): - AMD Mesa RadeonSI: garbage / vertical stripes in place of glyphs - NVIDIA proprietary OR Mesa Zink→NVIDIA Vulkan: blank / transparent text (no stripes). Confirmed in WINEDEBUG: GL renderer = "zink Vulkan 1.4(NVIDIA GeForce RTX 3060 …)" when DRI_PRIME alone does not force radeonsi — dimensions invisible, not striped. - Software GL (LLVMpipe): blank text === Application technical details === PE import analysis of PRO100.exe shows it uses classic GDI + OpenGL: - GetGlyphOutlineW - TextOutW / ExtTextOutW - CreateFontIndirectW - opengl32 / wglMakeCurrent It does NOT import gdiplus.dll, d2d1.dll, or dwrite.dll. So winetricks gdiplus / dwrite / Direct2D factory overrides are irrelevant for this title (already tried; no effect). WineDEBUG (+font,+gdi,+wgl) on the failing host confirms NtGdiGetGlyphOutline and NtGdiExtTextOutW are called (e.g. splash/UI strings). The failure appears when glyph bitmaps for dimension overlays are composed into the OpenGL viewport — not a missing font install (UI menus still draw text via GDI). === Steps to reproduce === 1. Install PRO100 7.05 (or the free Demo from https://www.pro100.eu) in a clean 64-bit Wine prefix. DEMO.exe from the vendor package reproduces the bug (confirmed: same vertical stripe corruption on AMD RadeonSI). 2. Start DEMO.exe (or PRO100.exe), open any project or draw a simple cabinet. 3. Enable the Dimensions layer ("Wymiary") and/or Labels. 4. Observe the 3D view. === Expected === Numeric dimensions and labels are readable text over the scene (as on Ubuntu 24.04 + Wine 9). === Actual === - AMD Mesa: corrupted stripes / garbage in place of glyph bitmaps - NVIDIA / software GL: empty/transparent text regions (dimension lines may still appear) === What did NOT help (already tested) === - Switching Wine 8 / 9 / 10 / 11 runners - winetricks gdiplus; native gdiplus/dwrite overrides - Direct2D max_version_factory=0 - Font replacements / FontSmoothing / PRO100.ini antialias=0 - Force GLX vs EGL (UseEGL) - Zink (stripes become blank; still no correct text) - Virtual desktop - Disabling PRO100's OpenGL preference in INI - Mesa GL version override / various MESA_* env experiments === Hypothesis for Wine developers === Regression or incompatibility in how Wine maps classic GDI glyph/bitmap allocations (GetGlyphOutlineW path) into textures or pixel buffers consumed by an OpenGL context on newer host graphics stacks (Mesa / NVIDIA / XWayland on Ubuntu 26), while the same PE binary works on Ubuntu 24.04. I can provide screenshots (working Dell/24.04 vs broken Victus/26.04) and a trimmed WINEDEBUG excerpt showing GetGlyphOutlineW / ExtTextOutW activity. Happy to run a small test case if you have one, or to retest a patch build. Thank you. -- 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 60479] New: CloneCD shows
by WineHQ Bugzilla Oct. 11, 2026

Oct. 11, 2026

http://bugs.winehq.org/show_bug.cgi?id=60479 Bug ID: 60479 Summary: CloneCD shows Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bernhardu(a)mailbox.org Target Milestone: --- Distribution: --- Driven by the experiments with other kernel mode drivers in bug #60466 I tried to start CloneCD, which unfortunately shows again the same behaviour as in bug #51998. 0074:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\ElbyCDIO": c0000142 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"ElbyCDIO" failed to start: 1114 0024:trace:msgbox:MSGBOX_OnInit L"Unable to load the CloneCD device driver!\nAfter Installation of CloneCD Windows has to be restarted!" This shows up with a 64-bit prefix, and a regression test leads me to wine-11.8 as last version, which gets over this message. A git bisect shows this commit: 2231b967d9e7f9712764c40aac235465d2890a1c is the first broken commit commit 2231b967d9e7f9712764c40aac235465d2890a1c Author: Dmitry Timoshkov <dmitry(a)baikal.ru> Date: Wed Oct 29 21:23:51 2025 +0300 wineboot: Run services.exe from c:\windows\system32 directory. A .Net based service detects that it's running as a service by checking if its current directory is system32, otherwise the service runs in some debugging console based mode. Service processes created by services.exe inherit its current directory, so it's enough to make sure that services.exe runs from c:\windows\system32. Comparing the files I could not find a difference to a native installation within a 64-bit windows 11: drive_c/windows/system32/drivers/ElbyCDIO.sys drive_c/windows/system32/drivers/ElbyCDFL.sys drive_c/windows/syswow64/Drivers/ElbyCDFL.sys $ wine reg query 'HKLM\System\CurrentControlSet\Services\ElbyCDIO' /v ImagePath HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ElbyCDIO ImagePath REG_SZ System32\Drivers\ElbyCDIO.sys Reverting 3f4fde0038 and 2231b967d9 makes this error go away. CloneCD fails then with another error, but UI stays open. 0024:trace:msgbox:MSGBOX_OnInit L"No CD-Rom found!" -- 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 2

[Bug 54176] New: Vegas pro 16
by WineHQ Bugzilla Oct. 11, 2026

Oct. 11, 2026

https://bugs.winehq.org/show_bug.cgi?id=54176 Bug ID: 54176 Summary: Vegas pro 16 Product: Wine Version: 7.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: bochtabochta(a)gmail.com Distribution: --- Created attachment 73699 --> https://bugs.winehq.org/attachment.cgi?id=73699 BackTrace of crash Vegas pro 16 crashes at launch when loading i/o file manager -- 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 3

[Bug 60481] New: Observer: System Redux: severely distorted, slow-sounding audio during MP4 playback following the Wine 11.12 resampler changes
by WineHQ Bugzilla Oct. 11, 2026

Oct. 11, 2026

http://bugs.winehq.org/show_bug.cgi?id=60481 Bug ID: 60481 Summary: Observer: System Redux: severely distorted, slow-sounding audio during MP4 playback following the Wine 11.12 resampler changes Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: winegstreamer Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Target Milestone: --- Regression SHA1: 3c4a1ec11487d5879d5f973eb198b3895cc11f70 Distribution: ArchLinux Created attachment 82322 --> http://bugs.winehq.org/attachment.cgi?id=82322 plain terminal output (wine-11.19-170-ga15ee2ccf20) Observer: System Redux (GOG version, 64-bit executable) has an audio regression affecting its MP4 videos. Audio is severely distorted and sounds as though it is playing at a reduced speed. I don't have the game on Steam to compare it to the GOG version. The issue occurs with both the game's DirectX 11 and DirectX 12 renderers, and with both legacy shared WoW64 and new WoW64 builds. It is still present in wine-11.19-170-ga15ee2ccf20. Steps to reproduce: 1. Launch the game. 2. After the silent splash screens, let Introduction_Redux.mp4 play. 3. Listen to the severely distorted, slow-sounding audio. Other affected in-game videos include: - NewGameIntroduction.mp4, played when starting a new game. - IntroObserver.mp4. - o_video_screen_01_a.mp4, displayed on the character's laptop while sitting in the car. These other videos display an image, but their audio is similarly distorted. The same source MP4 files play correctly with both gst-play-1.0 and ffplay on the same system. Introduction_Redux.mp4 has a separate, longstanding black-image issue. That issue predates this regression and is not the subject of this report. Playback initially broke completely between Wine 11.11 and 11.12: the affected videos produced neither an image nor audio, and could be skipped by pressing a key. I bisected that complete playback failure to: 3c4a1ec11487d5879d5f973eb198b3895cc11f70 winegstreamer/resampler: Translate IMFTransform calls to IMediaObject. I verified the bisect result. This is also the regression commit reported in bug #60307 for The Bard's Tale IV Director's Cut. Commit 91fabe0d1dc0f766df0c54809b0b2811f28bcf1d: resampledmo: Don't use AVRational as time base. restored playback in Observer: System Redux as well, but the audio remained severely distorted. To narrow this down, I tested: - e3ef49921efb44cb416baba6e189fb93dd600bfb, the commit immediately following 3c4a1ec1, with 91fabe0d applied: playback resumes, but audio is distorted. - 3c4a1ec11487d5879d5f973eb198b3895cc11f70 itself, with the same time-base fix adapted to dlls/winegstreamer/resampler.c: playback also resumes, but audio is distorted. Thus, the distorted audio is already reproducible with 3c4a1ec1 plus the time-base fix; the subsequent move of the resampler implementation into resampledmo (e3ef4992) and later Wine changes are not required. Media details: Introduction_Redux.mp4 contains H.264 High-profile video and two AAC LC audio tracks. Both audio tracks are stereo, 48,000 Hz, approximately 160 kb/s. -- 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 1

[Bug 46716] New: utherverse client : crash when loading and installing
by wine-bugs＠winehq.org Oct. 11, 2026

Oct. 11, 2026

https://bugs.winehq.org/show_bug.cgi?id=46716 Bug ID: 46716 Summary: utherverse client : crash when loading and installing Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: www.max87(a)yahoo.fr Distribution: --- Created attachment 63684 --> https://bugs.winehq.org/attachment.cgi?id=63684 report generate by wine on the crash When i lunch the application client Uhterverse i got a bug report from wine and the loading of the client is stopped I tryed a reinstall of the client and it done the same a bug appared but the installation finished -- 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 60478] New: Wine's .winmd files have "include/" in their assembly names; .NET Framework WPF apps fail with 0x80131047 (Razer installer)
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60478 Bug ID: 60478 Summary: Wine's .winmd files have "include/" in their assembly names; .NET Framework WPF apps fail with 0x80131047 (Razer installer) Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82318 --> http://bugs.winehq.org/attachment.cgi?id=82318 Razer installer log, XamlParseException 0x80131047 Wine installs ten .winmd files into C:\windows\system32\winmetadata, and the assembly name inside each of them still carries the build directory: windows.storage.winmd is named "include/windows.storage", windows.ui.winmd "include/windows.ui", and so on for all ten. Checked on wine-11.19. Going by the Arch packages the files first appear in 10.16 (10.15 has none) and the names have been like this ever since. Native .NET Framework 4.8 cannot parse such a name. Once one of the files is loaded into a process, Assembly.FullName returns include\/windows.storage, Version=255.255.255.255, Culture=neutral, PublicKeyToken=null, ContentType=WindowsRuntime and new AssemblyName() on that string throws FileLoadException 0x80131047. WPF does this for every loaded assembly while it resolves BAML types, so the next window fails to load. I hit it with the Razer installer (RazerAxonInstaller.exe, Razer Installer 2.6.0.890, the same file as https://rzr.to/synapse-4-pc-download) Fresh 64-bit prefix, winetricks dotnet48, Windows 10: the process stays alive but no window ever appears, and its log has XamlParseException 0x80131047 from MainWindow.InitializeComponent (attached). Move system32\winmetadata out of the prefix, change nothing else, and the window comes up. Same in two separate prefixes. Should the name simply be "Windows.Storage", without the directory? -- 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 2

[Bug 60133] New: RazerSynapseInstaller Fails To Connect To Server
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60133 Bug ID: 60133 Summary: RazerSynapseInstaller Fails To Connect To Server Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: wz4mnbp8kx6q(a)posteo.net Target Milestone: --- Distribution: --- Created attachment 81718 --> http://bugs.winehq.org/attachment.cgi?id=81718 Terminal Log Running "$ wine RazerSynpaseInstaller.exe" produces a bunch of "fixme" errors and the GUI reads "Connection To Service Terminated". Attached is (a screenshot - only one attachment allowed) of the GUI and the terminal output. Razer Installer Version 2.5.0.882 Razer Synapse 4 Link to binary: https://rzr.to/synapse-4-pc-download -- 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 60172] New: WPF font fallback does not work: the families named by GlobalUserInterface.CompositeFont do not resolve under Wine
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60172 Bug ID: 60172 Summary: WPF font fallback does not work: the families named by GlobalUserInterface.CompositeFont do not resolve under Wine Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)list.winehq.org Reporter: wehrwolfmann(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81815 --> http://bugs.winehq.org/attachment.cgi?id=81815 family resolution and glyph outlines for Latin and Cyrillic WPF (.NET Framework, PresentationCore) does not use DirectWrite layout or the dwrite fallback API -- it carries its own per-character fallback table, the GlobalUserInterface.CompositeFont file installed with the framework. That table is written entirely in terms of Windows system font families. Under Wine essentially none of those families exist, so the table has nowhere to go and WPF emits .notdef for the character instead. Measured on this prefix (Wine 11.15, WINEARCH=win64, reported Windows 10 build 19045, native .NET Framework 4.8, host CachyOS/Arch with the usual Noto, DejaVu and Liberation font packages installed), against the RS5 section of GlobalUserInterface.CompositeFont, which is the section .NET selects when Wine reports Windows 10: families named as fallback targets 44 resolvable through Wine 1 (Tahoma) not resolvable 43 (Segoe UI, Segoe UI Symbol, Ebrima, Nirmala UI, Leelawadee UI, Malgun Gothic, Gulim, Gadugi, Yu Gothic UI, Meiryo UI, Microsoft YaHei UI, Microsoft JhengHei UI, SimSun, MS Gothic, MingLiU, Calibri, Cambria Math, Myanmar Text, MV Boli, Mongolian Baiti, Simplified Arabic, ... ) The single map that matters most is the first one: <FontFamilyMap Unicode = "0000-052F, 0590-05FF, ..." Target = "Segoe UI, Segoe UI Symbol, Ebrima" /> U+0000-U+052F is Latin, Latin Extended, IPA, Greek and Cyrillic; the same map also carries Hebrew. All three targets are missing, so under Wine a WPF application has no fallback at all for those scripts. A plain WPF application does not notice, because its default typeface comes from SystemParametersInfo(SPI_GETNONCLIENTMETRICS) and Wine answers "Tahoma", which covers Latin, Greek and Cyrillic by itself. An application that ships its own branded font does notice, and branded fonts are usually Latin-only. WHAT THIS LOOKS LIKE IN A REAL APPLICATION Razer Central 7.23.0.1220 (the launcher bundled with Razer Axon) draws its tray icon context menu with WPF, in its own font "RazerF5" (SIL OFL, derived from Titillium, embedded in the executable and also shipped as a separate download). RazerF5 has 229 glyphs: Latin and punctuation, no Cyrillic. With the application's language set to Russian, every Latin menu entry renders and every Cyrillic menu entry is a row of empty boxes. On Windows the same build renders the Russian entries, because the fallback lands on Segoe UI. MINIMAL REPRODUCER wpf_fonts.cs (attached). It is a console program; build it with the csc.exe that comes with the framework already installed in the prefix, no SDK needed: wine "C:\windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /nologo \ /nowarn:0618 /target:exe /out:C:\wpf_fonts.exe \ "/r:C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\PresentationCore.dll" \ "/r:C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\PresentationFramework.dll" \ "/r:C:\windows\Microsoft.NET\Framework64\v4.0.30319\WPF\WindowsBase.dll" \ "/r:C:\windows\Microsoft.NET\assembly\GAC_MSIL\System.Xaml\v4.0_4.0.0.0__b77a5c561934e089\System.Xaml.dll" \ C:\wpf_fonts.cs For every family name given on the command line it prints whether the family resolves, whether the resolved face covers Latin and Cyrillic, and the bounding box of the outlines FormattedText.BuildGeometry() actually produced for the Latin string "Settings" and the Cyrillic string "Настройки". An empty bounding box means WPF produced no glyph outline at all -- the tofu case. It also writes wpf_fonts.png so the failure can be seen rather than read. Run it with any font that covers Latin but not Cyrillic; RazerF5 is the one used here (razerf5-light.otf, freely downloadable, SIL OFL): family "RazerF5" resolved=True latin=True cyrillic=False latin width= 55.26 height= 18.66 outline=53.7x14.8 cyrillic width= 33.84 height= 18.66 outline=EMPTY (nothing drawn) family "Tahoma" resolved=True latin=True cyrillic=True latin width= 56.50 height= 19.31 outline=55.9x15.0 cyrillic width= 77.58 height= 19.31 outline=75.6x15.0 family "Segoe UI" resolved=False Tahoma proves the text path itself is fine. RazerF5 shows that once the requested face lacks the character, nothing takes over. THE GDI CONTRAST gdi_cyrillic.c (attached) does the same two strings through plain GDI: CreateFontIndirectA, GetGlyphIndicesW(GGI_MARK_NONEXISTING_GLYPHS), TextOutW into a DIB, counting painted pixels. face "Segoe UI" latin missing_glyphs=0/8 painted_pixels=522 (GetTextFace Liberation Sans) cyrillic missing_glyphs=0/9 painted_pixels=637 (GetTextFace Liberation Sans) face "RazerF5" latin missing_glyphs=0/8 painted_pixels=489 (GetTextFace RazerF5) cyrillic missing_glyphs=9/9 painted_pixels=653 (GetTextFace RazerF5) So Wine already degrades gracefully when a Win32 application asks for a Windows font by name -- "Segoe UI" quietly becomes Liberation Sans and the Cyrillic renders. That graceful degradation happens at font *selection* time and is invisible to any consumer that first asks whether the family exists. WPF asks exactly that question, gets "no", and its whole fallback table dies with it. (GDI's own per-glyph behaviour for RazerF5 -- 9 unmapped glyphs, boxes painted -- matches Windows; GDI TextOutW does not font-link either. The difference is only in the family lookup.) A HARSHER MANIFESTATION If the *requested* family also fails to resolve, WPF does not fall back to a default -- the process dies silently inside text formatting. With the reproducer above: wine wpf_fonts.exe "Segoe UI" family "Segoe UI" resolved=False <process gone, no exception, no message> This looks like the same root cause as bug 50021 (PS Remote Play, assertion in MS.Internal.Shaping.TypefaceMap.MapUnresolvedCharacters, "installing corefonts changes the behaviour"): MapUnresolvedCharacters has nothing left to map to. Related but distinct: bug 59925 is also WPF fallback failing, but there the requested families do resolve and a single character (U+002D) is orphaned into a run of its own. Here the fallback targets do not exist as families at all, so the table has nothing to reach in the first place. SUGGESTED FIX Wine already has the mechanism, it just has no default entries for these names: HKCU\Software\Wine\Fonts\Replacements, honoured by both win32u/font.c (load_gdi_font_replacements) and dwrite/font.c. It enumerates an existing family under an additional name, and it steps aside automatically if a real font of that name is ever installed. REG_MULTI_SZ values are already supported and the first available entry wins, so one value works across distributions: [HKEY_CURRENT_USER\Software\Wine\Fonts\Replacements] "Segoe UI"=hex(7):... Noto Sans, DejaVu Sans, Liberation Sans, Arial, Tahoma "Segoe UI Symbol"=hex(7):... DejaVu Sans, Noto Sans, Liberation Sans, Arial, Tahoma "Ebrima"=hex(7):... Noto Sans, DejaVu Sans, Liberation Sans, Arial, Tahoma Adding just those three restores WPF fallback for Latin Extended, Greek, Cyrillic and Hebrew. Verified on this prefix with the reproducer, with GlobalUserInterface.CompositeFont left untouched: before family "RazerF5" cyrillic outline=EMPTY (nothing drawn) after family "RazerF5" cyrillic outline=80.8x16.0 (Noto Sans metrics) Tahoma as the last entry is a safe floor: Wine ships it, and it covers Latin, Greek and Cyrillic. The same treatment would extend naturally to the CJK and Indic target names for hosts that have suitable fonts. An independent cross-check that the composite font really is the mechanism: appending an existing family to every Target attribute in the prefix's *.CompositeFont files fixes it too, with no registry change at all. The registry route is preferable because it needs no edits to files that belong to the framework. VERSIONS Reproduced on wine-11.15 (Arch/CachyOS package), WINEARCH=win64, native .NET Framework 4.8, reported Windows version 10 (build 19045). Not tested on Wine-Mono; Wine-Mono's WPF carries its own copy of the same composite font files, so the same reasoning should apply. ATTACHMENTS wpf_fonts.cs WPF reproducer described above gdi_cyrillic.c the GDI counterpart used for the contrast wpf_fonts_before.png offscreen render, stock prefix: Cyrillic missing wpf_fonts_after.png the same render once "Segoe UI" resolves -- 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 16

[Bug 60477] New: wininet: HTTP CONNECT proxy authentication state invalidated upon upstream socket reset under rotating gateway
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60477 Bug ID: 60477 Summary: wininet: HTTP CONNECT proxy authentication state invalidated upon upstream socket reset under rotating gateway Product: Wine Version: 10.0 Hardware: x86-64 URL: https://learn.microsoft.com/en-us/windows/win32/winine t/handling-authentication OS: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: wininet Assignee: wine-bugs(a)list.winehq.org Reporter: info(a)neurobitlab.com Target Milestone: --- Distribution: Ubuntu Description: Under Wine 9.20 through 10.0, 32-bit and 64-bit Windows applications utilizing WinINet (InternetOpenW, HttpSendRequestW) fail to transparently re-authenticate when an upstream HTTP proxy gateway resets the underlying TCP connection or rotates its egress endpoint. Test Setup & Environment: - OS: Linux 6.11 / x86_64 - Wine: wine-10.0 (staging / vanilla) - Subsystem: dlls/wininet/http.c - Network Topology: Windows client application routing outbound HTTPS via HTTP CONNECT proxy requiring Basic/Digest authentication (RFC 7235). Steps to Reproduce: 1. Initialize WinINet session via InternetOpenW with INTERNET_OPEN_TYPE_PROXY: lpszProxy = L"http=http://proxy-node.local:8080" 2. Supply proxy credentials using InternetSetOptionW with INTERNET_OPTION_PROXY_USERNAME and INTERNET_OPTION_PROXY_PASSWORD. 3. Establish persistent HTTP/1.1 keep-alive session to an external target. 4. Simulate an upstream cellular gateway IP rotation or gateway socket teardown (e.g., standard carrier-grade NAT rebind on mobile hardware gateways). 5. Attempt subsequent HttpSendRequestW on the same session handle. Observed Behavior: On native Windows 10/11 (mshtml / wininet.dll), WinINet catches the dropped socket, discards the cached connection pool entry, re-opens a fresh TCP socket, and re-issues the HTTP CONNECT handshake with Proxy-Authorization header. Under Wine, wininet attempts to write the next request into the defunct socket descriptor, receives ECONNRESET / EPIPE, and immediately fails with error 12031 (ERROR_INTERNET_CONNECTION_RESET) without initiating a re-connection or re-evaluating the proxy auth state machine in HTTP_ProcessAsync. Upstream Protocol References & Test Data: - Microsoft WinINet Authentication Specification: https://learn.microsoft.com/en-us/windows/win32/wininet/handling-authentica… - IETF RFC 7235 (Hypertext Transfer Protocol - Authentication): https://datatracker.ietf.org/doc/html/rfc7235 - Wine Git Source Reference (dlls/wininet/http.c): https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/wininet/http.c - Reproducer Socket Traces & Cellular Gateway Test Environment: https://pxm2.io/guides/ Expected Behavior: WinINet should catch socket reset errors on pooled idle connections, flush the dead socket, and automatically retry the HTTP CONNECT negotiation before returning ERROR_INTERNET_CONNECTION_RESET to the calling application. -- 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 33985] New: Nokia Music Player: window decorations should not be displayed in installer window
by wine-bugs＠winehq.org Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=33985 Bug #: 33985 Summary: Nokia Music Player: window decorations should not be displayed in installer window Product: Wine Version: 1.6-rc4 Platform: x86-64 URL: http://nds1.nokia.com/files/support/nseries/phones/sof tware/SetupOviPlayer.exe OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: frederic.delanoy(a)gmail.com Classification: Unclassified Created attachment 45154 --> http://bugs.winehq.org/attachment.cgi?id=45154 WinXP/wine-1.6-rc4-52-g9a0b434 side-by-side comparison The windows decorations (here from XFCE 4.10) are present in Wine while they aren't in native Windows. See attached screenshot for a comparison -- 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.

2 9

[Bug 60171] New: A click that falls through a native-surface-less active top-level window incorrectly deactivates it
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60171 Bug ID: 60171 Summary: A click that falls through a native-surface-less active top-level window incorrectly deactivates it Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: patch Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: devel(a)velmeden.info Target Milestone: --- Distribution: ArchLinux Created attachment 81813 --> http://bugs.winehq.org/attachment.cgi?id=81813 Patch *I ran into this bug but could not find or reproduce the underlying cause myself, so I investigated it together with an AI assistant. The text and patch below is written by the AI, based on that interactive troubleshooting session.* ## Summary `process_mouse_message()` (`dlls/win32u/message.c`) reactivates whatever top-level window a click's X11 event resolves to, and deactivates the previously-active window as a side effect, whenever the clicked window differs from the currently active one. This is correct when the click is a genuine user action on a different window. It is wrong when the currently active top-level window has no native (X11) surface of its own: any click physically within that window's on-screen bounds can only ever be delivered by the X server to whatever real window happens to be underneath or around it (typically an ancestor), since the active window itself has nothing on screen to receive input. Wine currently can't tell these two cases apart, so it deactivates a window the user visually clicked on, purely because of how the click was routed at the X11 level. ## Why a top-level window can have no native surface Some applications create ordinary (non-`WS_CHILD`) top-level windows whose visible content is presented through some other mechanism than Wine's own X11 "whole window" — for example, a toolkit-hosted child surface embedded inside a native host window, where the toolkit's own window/surface object is what's actually on screen, while the win32-visible `HWND` exists purely for message routing, focus and activation bookkeeping. In such a case `X11DRV_get_whole_window(hwnd)` legitimately returns `0` for that `HWND` even though it is a real, activatable top-level window as far as the win32 window manager is concerned. ## Observed effect I diagnosed this on Wine 11.14 against Loxone Config (an MFC + Qt6 hybrid application), whose MDI document window is exactly such a case: its X11 "whole window" is destroyed early on and never recreated for the rest of the session (confirmed structural, not a transient timing gap — traced via `create_whole_window()`/`destroy_whole_window()` instrumentation across a full session), while Wine's own bookkeeping still tracks it as the active top-level window (`NtUserGetForegroundWindow()`/`info.hwndActive`). Any real mouse click physically over that window's on-screen area resolves, at the raw X11 level, to whichever window is actually behind it (confirmed via instrumented `X11DRV_ButtonPress` logging the raw event's `window`/`subwindow` fields together with each window's actual X11 id — the click's `ButtonPress` event targets the ancestor's real X11 window, never the document window's, because the latter doesn't have one). `process_mouse_message()` then runs its normal `WM_MOUSEACTIVATE`/`set_foreground_window()`/`set_active_window()` cascade for "a click on a different top-level window", which sends `WM_ACTIVATE(WA_INACTIVE)` to the window that was actually still active and that the click was visually intended for. Any interaction state that window's application logic keeps tied to activation (for example, a pending drag-and-drop-style operation initiated by an earlier click) gets torn down as a result, even though the user's click landed squarely inside that window's visible bounds. This does not require the click to race anything — in the traced case, the affected window had already been without a native surface for ~30 seconds before the failing click, so this is a deterministic misclassification, not a timing-sensitive race. ## Steps to reproduce 1. Download Loxone Config: https://updatefiles.loxone.com/LoxConfig/LoxoneConfigSetup_17010727.zip 2. Unzip it and run the installer under Wine: `wine LoxoneConfigSetup.exe` (click through the installer normally). 3. Launch `LoxoneConfig.exe` and open or create any project. 4. Pick any block/object to add, either via the search dialog (press `F5` to open it, type e.g. `RS` to find the "RS Flipflop" block, and pick it from the results) or by dragging one of the toolbar symbols — either way it attaches to the mouse cursor as a drag preview. 5. Move the mouse over the project canvas and click to place it. Expected: the block is placed on the canvas. Actual: the drag preview disappears on mouse-down, but no block is actually added — no visible change, and `Edit` → `Undo` stays greyed out, confirming the placement was never registered. This is 100% reproducible. ## Fix Attached patch adds a `WindowHasNativeSurface(HWND) -> BOOL` user driver entry point (default `TRUE`; implemented for `winex11.drv` via the existing `X11DRV_get_whole_window()` helper, other drivers unaffected). In `process_mouse_message()`, before running the reactivation cascade for a click that resolves to a different top-level window, check whether the window Wine still considers active has no native surface and geometrically contains the click point; if so, treat this as a click-through rather than a genuine activation change, and skip the cascade. The check is narrowly scoped: it does not redirect the click itself, does not touch window-surface creation/lifecycle, and every other click-resolution/activation path (including everything on drivers other than `winex11.drv`, where the new hook always returns `TRUE`) is unaffected. ## Testing - Live-validated against the real application described above: prior to the fix, the described interaction failed 100% of the time; after the fix, the specific click-misrouting-to-an-ancestor mechanism no longer tears down the document window's activation state (confirmed via the same gdb instrumentation, both on a debug and on a release (`-O2`) Wine build). - `dlls/user32/tests/msg.c` and `dlls/user32/tests/input.c` run clean (via an isolated `Xephyr` X server, since the interactive desktop proved too environment-sensitive for a byte-accurate baseline comparison): no activation/`WM_ACTIVATE`/`WM_MOUSEACTIVATE`-related failures attributable to the patch across multiple runs. ## Known limitation of this report I don't yet have a minimal, app-independent C reproduction case for this specific mechanism (a separate, previously-considered mechanism for the same user-facing symptom turned out, on later investigation, to be a distinct and still-open issue in the same application, unrelated to this patch). I'm glad to build one (the core ingredients — a top-level window with no native surface set as active, and a second, real window overlapping its screen area — should be reproducible with plain Win32 API plus one Wine-internal step to force the surface-less state) if that would help review; in the meantime the patch was developed and validated against a live repro that exhibits the exact structural condition described above, with full gdb-level traces at each step (raw X11 event routing, `set_active_window()` call arguments, and whole-window create/destroy lifecycle) establishing the mechanism precisely rather than by inference. -- 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 18

[Bug 60411] New: Serious Sam 3 blank screen
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60411 Bug ID: 60411 Summary: Serious Sam 3 blank screen 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: rva1048576(a)yandex.ru Target Milestone: --- Distribution: --- Created attachment 82215 --> http://bugs.winehq.org/attachment.cgi?id=82215 output After starting game it shows short first video about serious engine. After this video blank screen. 8-9 years ago I played this copy of game in wine and it was ok. Wine output attached. I also tried Serious Sam HD Second Encounter with Fusion DLC of 2017 year and it starts with blank screen and it shows very similar output. Serious Sam HD released in 2010 shows game menu as expected. I think 2010 year release uses older DirectX and it is ok. -- 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 55336] New: Touhou 6 : Full-screen with Alt-tabbing or using DXVK breaks inputs
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

https://bugs.winehq.org/show_bug.cgi?id=55336 Bug ID: 55336 Summary: Touhou 6 : Full-screen with Alt-tabbing or using DXVK breaks inputs 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: riyu12383(a)gmail.com Distribution: --- -The Game Here is a very small demo version of the game from archive.org https://archive.org/compress/KoumaTr013/formats=ARCHIVE%20BITTORRENT,METADA… To launch this version, you'll need to add Japanese locale like this : LANG=ja_JP.UTF-8 wine 東方紅魔郷.exe -The bug When launching the game in Full-screen and Alt-Tabbing or using DXVK, the game inputs breaks, its scrolls the menu infinitely or quit the game by itself, the user can't control anything anymore. On the demo version it seems the user only loose the control. Interestingly on Windows, since Windows 10, the game has an exaggerated speed/framerate in full-screen. Which was fixed using this dx8 to dx9 converter : http://enbdev.com/convertor_dx8_dx9_v0036.htm However this doesn't change anything with wine. I originally discovered this bug here : https://github.com/AlpyneDreams/d8vk/issues/155 -- 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 29

[Bug 60457] New: The Hankaku/Zenkaku key never reaches the application as WM_KEYDOWN VK_PROCESSKEY with an X input method, so text typed with the IME off is not committed
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60457 Bug ID: 60457 Summary: The Hankaku/Zenkaku key never reaches the application as WM_KEYDOWN VK_PROCESSKEY with an X input method, so text typed with the IME off is not committed Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs(a)list.winehq.org Reporter: kagetaro1986(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82278 --> http://bugs.winehq.org/attachment.cgi?id=82278 imetest program, logs (Windows 11, Wine unpatched/patched) DESCRIPTION With a Japanese keyboard and an X input method (fcitx5 + mozc), pressing the Hankaku/Zenkaku key (the key that switches the input method on or off) gives the application only a WM_KEYUP of VK_OEM_AUTO. No key down is delivered at all. On Windows 11 the IME processes this key, and the application receives the release followed by WM_KEYDOWN VK_PROCESSKEY. While that message is being handled, ImmGetVirtualKey returns the real key (VK_OEM_AUTO / VK_OEM_ENLW). This is the same in all 8 runs with the current Microsoft IME (ANSI and Unicode windows, 32 and 64 bit, also with -open and -recreate). Some applications keep the text typed with the IME off in their own edit buffer, and commit it when they see this key. A game I use with Wine does this: text typed with the IME off (for example a chat command prefix such as /l ) is committed when the user presses Hankaku/Zenkaku on Windows. On Wine the key never arrives, so that text is replaced by the first Japanese composition. Analysis: the X input method consumes the key press (XFilterEvent), so Wine never generates a key message for it. Only the release reaches ImmProcessKey / ImeProcessKey. This happens with fcitx5's default configuration (fcitx5 handles Hankaku/Zenkaku as its trigger key) and also when mozc handles the key itself. STEPS TO REPRODUCE 1. LC_ALL=ja_JP.UTF-8 XMODIFIERS=@im=fcitx wine imetest32.exe -a -o test.log 2. Switch the input method on with Hankaku/Zenkaku, type nihon, press Hankaku/Zenkaku again. Actual: for each Hankaku/Zenkaku press the log only has LOOP WM_KEYUP wp=0x00f3. Expected (Windows 11 logs attached, steps 9 and 10 of the scenario): LOOP WM_KEYUP wp=0x00f3 lp=0xc0290001 LOOP WM_KEYDOWN wp=0x00e5 lp=0x00290001 (VK_PROCESSKEY, ImmGetVirtualKey=0xf3) - log: toggle key releases / VK_PROCESSKEY with ImmGetVirtualKey = VK_OEM_AUTO/ENLW - Windows 11, current Microsoft IME (each of the 8 runs): 2 / 2 - Wine 11.19 unpatched (A-32, W-64): 2 / 0 - Wine 11.19 + patches 0001-0004 (A-32, A-64, W-32, W-64): 2 / 2 PROPOSED PATCH (0004) When ImeProcessKey sees the release of VK_OEM_AUTO, VK_OEM_ENLW or VK_KANJI and nothing is being composed, the builtin IME posts a private notification to the IME UI window. The UI window then sets the virtual key returned by ImmGetVirtualKey (a small helper in imm.c) and posts WM_KEYDOWN VK_PROCESSKEY to the application. The message order is the same as on Windows: release first, then the VK_PROCESSKEY key down. ImeToAsciiEx ignores these keys when the application translates the message, because the host input method has already handled them. With the patch, that game commits the text typed with the IME off when Hankaku/Zenkaku is pressed, as on Windows. Apart from steps 9 and 10, the imetest results are the same as with patches 0001-0003. This is a workaround for a key that the host input method keeps to itself, and advice on a better place for it (for instance winex11 when XFilterEvent consumes a key press) is welcome. The patch applies on top of patch 0003 from bug 60450 (0001 and 0002 are attached to bugs 60447 and 60448). Related: bugs 60448, 60449, 60450. ENVIRONMENT - Ubuntu 24.04.5 LTS, x86_64. Interactive tests on KDE Plasma (X11); the logged runs use Xvfb + openbox. - fcitx5 5.1.7 with fcitx5-mozc 2.28.4715.102 (Japanese), XIM frontend, on-the-spot preedit (UseOnTheSpot=True), LC_ALL=ja_JP.UTF-8, XMODIFIERS=@im=fcitx. - Wine 11.19 built from the WineHQ source (configure --enable-archs=i386,x86_64, i.e. the new WoW64 mode), fresh prefix, no DLL overrides when running the test (Mono/Gecko installation skipped while the prefix was created). Same results with Wine 11.19 + Staging. The files involved (dlls/imm32, dlls/win32u/imm.c, dlls/winex11.drv/xim.c) are unchanged in master as of 2026-10-05. - Comparison: Windows 11 Pro 26H2 (build 26300), Microsoft IME (current version, and the previous version where noted), Japanese 106/109 keyboard. TEST PROGRAM imetest.c (attached, standalone, no dependencies) creates one window with default IME handling and a PeekMessage loop, and logs for every IME and keyboard message whether it was taken from the queue (LOOP) or sent to the window procedure (PROC/sent), and what ImmGetCompositionString, ImmGetOpenStatus and ImmGetConversionStatus return at that moment. IDLE lines record the state once the queue is empty. Build: i686-w64-mingw32-gcc -O1 -o imetest32.exe imetest.c -limm32 -lshell32 -mwindows (64-bit: x86_64-w64-mingw32-gcc). Options: -a ANSI window (default Unicode), -recreate, -open, -auto (types the scenario with SendInput; Windows only), -o <log>. On Wine the scenario was typed through XTEST with drive_x11.py (attached), so that the keys go through the X input method like real key presses. -- 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 2

[Bug 60450] New: ImmGetOpenStatus does not follow the X input method: IME reported closed while text is committed, and open while the input method is off
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60450 Bug ID: 60450 Summary: ImmGetOpenStatus does not follow the X input method: IME reported closed while text is committed, and open while the input method is off Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs(a)list.winehq.org Reporter: kagetaro1986(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82266 --> http://bugs.winehq.org/attachment.cgi?id=82266 imetest test program, comparison and logs (normal and -open runs; Windows 11, Wine unpatched/patched) with terminal output DESCRIPTION The X input method (fcitx5 + mozc) does not report when the user switches it on or off, and cannot be switched on by the application (fcitx5 ignores XNPreeditState). Wine's builtin IME therefore guesses the open status: open when a composition starts, closed when it ends. Compared with Windows 11: - Around a commit, Windows keeps the IME open; Wine closes it right after each commit (IMN_SETOPENSTATUS), a few milliseconds before the application receives the committed characters. - A full-width space typed with nothing composed is committed while Wine reports the IME closed; on Windows the IME is open. - When the application opens the IME with ImmSetOpenStatus(TRUE), Windows switches the IME on (typing produces a composition). On Wine the IME is reported open while the input method is still off; typed characters arrive as plain WM_CHAR with ImmGetOpenStatus() == 1, and applications that wait for IME input while the IME is open ignore them. STEPS TO REPRODUCE 1. LC_ALL=ja_JP.UTF-8 XMODIFIERS=@im=fcitx wine imetest32.exe -a -o test.log; switch the input method on, press Space with nothing composed: the commit of U+3000 is logged with open=0. 2. wine imetest32.exe -a -open -o open.log (the program calls ImmSetOpenStatus(TRUE) after creating its window); with the input method off, type abc: the WM_CHAR lines show open=1. Expected (Windows 11 logs attached): open=1 during commits; with -open, abc becomes a composition. PROPOSED WORKAROUND (PATCH 0003, RFC) This is heuristic, and advice on a better approach is welcome (for instance a way to query or set the state of the input method): - close the IME 300 ms after a composition ends instead of immediately, unless a new composition starts; - open the IME for a commit that arrives without a composition, and close it again after the delay; - when a character key (letters, digits, OEM, numpad; no Ctrl/Alt) reaches ImeProcessKey while the IME is open and nothing is composed, the input method did not use it, so it is off: close the IME before the key is delivered. With the patch, commits happen with open=1, and with -open the first typed character arrives with open=0 (on Windows the IME would really be on; this cannot be done through XIM). The patch applies on top of patch 0002 from bug 60448. Possibly related: bug 54988. Not a Wine issue, for reference: when fcitx5's trigger key (Zenkaku_Hankaku) switches the input method off during a composition, fcitx5 clears the preedit without committing it (no commit over XIM), so the composition is lost, with or without the patch. Windows 11's current Microsoft IME keeps the composition and switches to alphanumeric mode. ENVIRONMENT - Ubuntu 24.04.5 LTS, x86_64. Interactive tests on KDE Plasma (X11); the logged runs use Xvfb + openbox. - fcitx5 5.1.7 with fcitx5-mozc 2.28.4715.102 (Japanese), XIM frontend, on-the-spot preedit (UseOnTheSpot=True), LC_ALL=ja_JP.UTF-8, XMODIFIERS=@im=fcitx. - Wine 11.19 built from the WineHQ source (configure --enable-archs=i386,x86_64, i.e. the new WoW64 mode), fresh prefix, no DLL overrides when running the test (Mono/Gecko installation skipped while the prefix was created). Same results with Wine 11.19 + Staging. The files involved (dlls/imm32, dlls/win32u/imm.c, dlls/winex11.drv/xim.c) are unchanged in master as of 2026-10-05. - Comparison: Windows 11 Pro 26H2 (build 26300), Microsoft IME (current version, and the previous version where noted), Japanese 106/109 keyboard. TEST PROGRAM imetest.c (attached, standalone, no dependencies) creates one window with default IME handling and a PeekMessage loop, and logs for every IME and keyboard message whether it was taken from the queue (LOOP) or sent to the window procedure (PROC/sent), and what ImmGetCompositionString, ImmGetOpenStatus and ImmGetConversionStatus return at that moment. IDLE lines record the state once the queue is empty. Build: i686-w64-mingw32-gcc -O1 -o imetest32.exe imetest.c -limm32 -lshell32 -mwindows (64-bit: x86_64-w64-mingw32-gcc). Options: -a ANSI window (default Unicode), -recreate, -open, -auto (types the scenario with SendInput; Windows only), -o <log>. On Wine the scenario was typed through XTEST with drive_x11.py (attached), so that the keys go through the X input method like real key presses. -- 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 2