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

[Bug 60448] New: Committed Japanese text cannot be read from the message loop: IME messages are sent instead of posted, and GCS_RESULTSTR is already empty
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60448 Bug ID: 60448 Summary: Committed Japanese text cannot be read from the message loop: IME messages are sent instead of posted, and GCS_RESULTSTR is already empty 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 82263 --> http://bugs.winehq.org/attachment.cgi?id=82263 imetest test program, tools, comparison and logs (Windows 11, Wine unpatched/patched) with terminal output DESCRIPTION Applications that handle WM_IME_COMPOSITION in their message loop (right after PeekMessage) and read the committed text there with ImmGetCompositionString(GCS_RESULTSTR) get no Japanese input on Wine. On Windows 11 (current and previous Microsoft IME), WM_IME_STARTCOMPOSITION, WM_IME_COMPOSITION and WM_IME_ENDCOMPOSITION are posted to the thread queue, and GCS_RESULTSTR returns the committed text when the commit message is retrieved, and until the next composition starts. On Wine, with an X input method: - the messages are sent to the window procedure (ImmGenerateMessage), the message loop never sees them; - each update from the input method replaces the whole composition string; a commit arrives as several updates (result, composition cleared, end of composition), so GCS_RESULTSTR is already empty when the queue has been processed; - the commit message has lParam 0x1800; Windows reports 0x1e00 (GCS_RESULTSTR | GCS_RESULTCLAUSE | GCS_RESULTREADSTR | GCS_RESULTREADCLAUSE). A related case: typing while a conversion is shown commits the converted text and immediately starts a new composition. If the messages are posted but the updates are applied as soon as they arrive (as in a first version of the patch), the new composition replaces the composition string before the application has read the commit, and the converted text is lost. On Windows the commit is read with GCS_RESULTSTR set and the new composition with GCS_RESULTSTR empty. 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, type nihon, Space (convert), Return (commit). 3. Type nihon, Space, then go while the conversion is shown, Return. Actual: every IME message is PROC/sent; the IDLE line after the commit shows an empty RESULT. Expected (Windows 11 logs attached): the IME messages are LOOP (posted); RESULT holds the committed text when the commit message is retrieved; in step 3 the converted text is committed and the new composition is read with an empty RESULT. summarize.py (attached) turns a log into a table; COMPARISON.md has the full comparison. PATCH 0002-imm32-Post-the-IME-messages-and-keep-the-result-stri.patch (attached): - post the messages to the input context window; - queue the updates from the host input method (composition strings and open status changes) and apply them one at a time, in order, once the application has retrieved the IME messages posted for the previous one (checked with PeekMessage(PM_NOREMOVE); retried with a 10 ms timer; an application that never retrieves them only delays the updates by 0.5 s); - keep the result string until a new composition starts; - report GCS_RESULTREADSTR | GCS_RESULTREADCLAUSE with the result; - return FALSE from ImeProcessKey: keys that reach it were not used by the input method (this also fixes the separate report about keys delivered twice as VK_PROCESSKEY and as the real key). With the patch the logs match Windows for all the steps above (32/64-bit, ANSI and Unicode windows). Only winex11/XIM was tested; winemac and winewayland use the same WINE_IME_POST_UPDATE path. Possibly related: bug 35929 (delayed IM input inserts wrong text), bug 55451. 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 60447] New: Japanese input (XIM) no longer reaches a window created after the thread's first top-level window was destroyed
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60447 Bug ID: 60447 Summary: Japanese input (XIM) no longer reaches a window created after the thread's first top-level window was destroyed 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 82261 --> http://bugs.winehq.org/attachment.cgi?id=82261 imetest test program, logs (Wine unpatched/patched, Windows 11) and terminal output DESCRIPTION When a thread destroys its first top-level window and then creates a new one (for instance a launcher, splash or login window followed by the main window), IME input no longer works in the new window. The X input method still receives the keys and shows a composition, but the application gets no WM_IME_* message at all and nothing is committed. If the first window is not destroyed, the same input works. On Windows the behaviour is the same in both cases. Analysis: the IME UI window that imm32 creates for the default input context is owned by the default IME window. The default IME window is destroyed together with the last top-level window of the thread, and the IME UI window with it, but imc->ui_hwnd keeps the stale handle. get_ime_ui_window() keeps returning it, so __wine_ime_wnd_proc() forwards every IME notification (IMN_WINE_SET_COMP_STRING, IMN_WINE_SET_OPEN_STATUS) to a window that no longer exists. A +imm trace of the test (attached) shows the IME UI window receiving WM_DESTROY together with the first default IME window, then WM_IME_NOTIFY 0x10 (IMN_WINE_SET_COMP_STRING) reaching the new default IME window for every update (65 times in that run) with no ime_ui_notify call. STEPS TO REPRODUCE 1. LC_ALL=ja_JP.UTF-8 XMODIFIERS=@im=fcitx wine imetest32.exe -a -recreate -o recreate.log (-recreate creates and destroys a first top-level window before creating the test window) 2. Switch the input method on, type nihon, Space, Return. 3. Compare with the same run without -recreate. Actual: no WM_IME_* message in recreate.log, nothing committed. Expected: the same messages as without -recreate (Windows 11: identical logs with and without -recreate, apart from handles and timing). PATCH 0001-imm32-Recreate-the-IME-UI-window-when-it-has-been-de.patch (attached): get_ime_ui_window() drops the handle when the window has been destroyed, so that a new IME UI window is created. With the patch, the -recreate run gives the same result as the normal run (32 and 64-bit, ANSI window). 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 60449] New: Keys not used by the X input method are delivered twice, as VK_PROCESSKEY and as the real key, even with the IME closed
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60449 Bug ID: 60449 Summary: Keys not used by the X input method are delivered twice, as VK_PROCESSKEY and as the real key, even with the IME closed 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 82265 --> http://bugs.winehq.org/attachment.cgi?id=82265 imetest test program and logs (Windows 11, Wine unpatched/patched) with terminal output DESCRIPTION With a Japanese keyboard layout and an X input method, keys that the input method does not use (for example BackSpace with nothing composed, or any key while the input method is off) reach the application twice: a WM_KEYDOWN with VK_PROCESSKEY (ImmGetVirtualKey returns the real key), followed by the WM_KEYDOWN of the real key. Applications that handle VK_PROCESSKEY through ImmGetVirtualKey process the key twice. On Windows 11 such keys arrive only as the real key; only the keys processed by the IME are replaced with VK_PROCESSKEY. Analysis: ImeProcessKey returns TRUE for every key except Shift/Ctrl/Caps/Alt (/* TODO: should be ctx->fOpen */). With XIM, the keys that the input method handles are consumed by it before they reach Wine, and its changes arrive asynchronously (WINE_IME_POST_UPDATE), so every key that reaches ImeProcessKey is one the input method did not use. STEPS TO REPRODUCE 1. LC_ALL=ja_JP.UTF-8 XMODIFIERS=@im=fcitx wine imetest32.exe -a -o test.log 2. Without switching the input method on, type a, BackSpace. 3. Switch it on, commit something, then press BackSpace with nothing composed. Actual: each key down appears twice in the log (VK_PROCESSKEY, then the real key). Expected (Windows 11 logs attached): only the real key. PATCH Fixed by 0002-imm32-Post-the-IME-messages-and-keep-the-result-stri.patch attached to bug 60448, which makes ImeProcessKey return FALSE. Possibly related: bug 59737. 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 1

[Bug 60059] New: Lock-key state (CapsLock/NumLock) oscillates on every keystroke when any global WH_KEYBOARD_LL hook exists — adjust_lock_state defeated by its own deferred synthetic events
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60059 Bug ID: 60059 Summary: Lock-key state (CapsLock/NumLock) oscillates on every keystroke when any global WH_KEYBOARD_LL hook exists — adjust_lock_state defeated by its own deferred synthetic events Product: Wine Version: 11.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: me(a)papayadev.net Target Milestone: --- Distribution: --- Created attachment 81552 --> http://bugs.winehq.org/attachment.cgi?id=81552 minimal reproducer: pass-through global WH_KEYBOARD_LL + lock-state logging (modes: control/hook/eat) winex11's lock-key reconciliation defeats itself whenever any global WH_KEYBOARD_LL hook exists on the desktop, permanently corrupting the desktop-wide CapsLock/NumLock toggle state on every keystroke, for every process in the prefix. Mechanism, current git (byte-identical from wine-11.10 through master): update_lock_state (dlls/winex11.drv/keyboard.c:1472, called from X11DRV_KeyEvent for every X key event) detects a toggle mismatch against the X event state mask and calls adjust_lock_state (keyboard.c:1452), which sends a synthetic lock-key down+up via NtUserSendHardwareInput and immediately re-reads NtUserGetAsyncKeyboardState to detect whether a keyboard hook blocked the change. But with a global WH_KEYBOARD_LL present, the server defers the keystate commit until the hook thread replies: queue_keyboard_message only calls queue_hardware_message — which contains the sole keystate update, update_desktop_key_state at server/queue.c:1859 — after the LL hook result arrives (queue.c:2489, send_hook_ll_message; commit on reply in store_message_result). And the driver's send never waits for that: DECL_HANDLER(send_hardware_message) sets sender=NULL unless SEND_HWMSG_INJECTED (queue.c:3232, :3265), so hardware-origin sends are fire-and-forget. The immediate re-read in adjust_lock_state is therefore deterministically stale (in the common case the hook belongs to the app's main thread, which is currently inside X11DRV_KeyEvent and cannot possibly have processed the hook callback yet). The code then WARNs "keystate %x not changed, probably blocked by hooks" and force-writes the corrected toggle via set_async_key_state — the intended hook-defeat behavior — but the deferred synthetic KEYDOWN then passes the (non-blocking) hook, commits, and toggles the desktop-wide state right back (update_key_state, queue.c). The next real key event detects the mismatch again and the cycle repeats forever: with a seeded mismatch the lock toggles flip on every keystroke, visibly randomizing character case mid-line in any app on the desktop. A mismatch seed is trivial: start wineserver with physical NumLock ON (Wine's initial toggle is off), or toggle CapsLock while the Wine window is unfocused. Reproducer (attached, ditest3.c, plain user32/gdi32, i686-w64-mingw32-gcc -O2 -o ditest3.exe ditest3.c -luser32 -lgdi32): it installs a PASS-THROUGH global WH_KEYBOARD_LL (CallNextHookEx only) on its pumping thread, mimicking what many games do. With physical NumLock ON and a fresh wineserver: WINEDEBUG=-all,+key,+keyboard wine ditest3.exe hook, then type ~20 letters. Observed (wine 11.13, X11): 277 of 277 reconcile attempts fail with "probably blocked by hooks", "Adjusting NumLock state (0x40)" fires on every key event, GetKeyState(VK_NUMLOCK)&1 flips per keystroke, and after toggling CapsLock out of focus the typed text comes out with random per-character case ("the QuicK brown fox jumps Over the lazy dog"). Control run without the hook (ditest3.exe): the same mismatch converges silently after one keystroke, zero WARNs — confirming the LL hook deferral is the sole trigger. A third mode (ditest3.exe eat) has the hook genuinely eat (return 1) the lock-key events: the force-write then sticks and the state converges with exactly one WARN per genuine desync — i.e. the existing hook-defeat force-write works correctly whenever the events are truly blocked; only the delayed-but-not-blocked case breaks it. This is a regression introduced by cbc657a244d1 ("winex11.drv: Force changing lock keys state if hooks blocked keyboard input processing.", 2018). Before that commit, a correction deferred behind a non-blocking low-level hook simply committed late and converged one keystroke later. With it, the force-write plus the later deferred commit toggle the state twice per reconcile, sustaining the oscillation indefinitely. The case that commit was written for — a hook genuinely blocking lock keys — still needs the force-write, so a plain revert is not the fix either; the problem is that the "did the state change" check cannot distinguish blocked from deferred. Real-world impact: Final Fantasy XI installs such a global WH_KEYBOARD_LL, and one running instance permanently corrupts Caps/NumLock behavior for every Wine process in the prefix (randomly flipping character case while typing). Any app with a global LL keyboard hook should trigger the same. Suggested fix directions: commit the keystate change of driver-origin lock-key corrections before/independently of the LL-hook round trip; or have adjust_lock_state skip the synthetic events and only force-write when a global WH_KEYBOARD_LL is present; or make the "did it change" check wait for / account for the deferred commit rather than misreading deferral as blocking. Related but distinct existing reports (checked 2026-07-24, none cover this defect): bug 35907 (caps state confused across processes — thread-vs-async state propagation, 2014 analysis predating the adjust_lock_state force-write; no LL hook involved, no per-keystroke oscillation) ; bug 59888 (numlock changes only detected while focused — the mismatch-seeding condition, not the oscillation; reconciliation-on-next-key is expected, this report is about the reconcile then un-doing itself); bug 57958 (adjust_lock_state falsely triggering while physically HOLDING CapsLock with the toggle on — a trigger-condition bug in the same function, no hook required; open MR !11315 addresses only that trigger condition and does not touch the LL-hook deferral). The control run (no hook: converges silently in one keystroke) isolates this report from all three. -- 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 15

[Bug 60476] New: Japanese 106/109 keyboard is not recognized: the Japanese-only keys get made-up scan codes, so GetKeyboardType(1) returns 0 and DirectInput reports a PC enhanced keyboard
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

http://bugs.winehq.org/show_bug.cgi?id=60476 Bug ID: 60476 Summary: Japanese 106/109 keyboard is not recognized: the Japanese-only keys get made-up scan codes, so GetKeyboardType(1) returns 0 and DirectInput reports a PC enhanced keyboard Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)list.winehq.org Reporter: kagetaro1986(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82306 --> http://bugs.winehq.org/attachment.cgi?id=82306 dinputtest.c, kbd_drive.py, container scripts, logs (Windows 11, Wine 11.19, Wine 11.19 + patch) DESCRIPTION With a Japanese keyboard (XKB layout jp, evdev keycodes), the keys that only exist on Japanese keyboards get no proper scan code in winex11: Ro (the key left of right Shift), Yen, Henkan, Muhenkan and Katakana/Hiragana. keyc2scan() has no entry for KEY_RO, KEY_YEN, KEY_HENKAN, KEY_MUHENKAN and KEY_KATAKANAHIRAGANA, so they fall through to the made-up extended scan code 0x200 | key (there is even a FIXME: map a KEY to T73 / VK_ABNT_C1). Consequences: - MapVirtualKey(VK_OEM_102, MAPVK_VK_TO_VSC) returns 0x59 instead of 0x73, so GetKeyboardType(1) returns 0 instead of 2 (its check for a Japanese 106 keyboard fails), although GetKeyboardType(0) returns 7. - DirectInput then creates the keyboard as DIDEVTYPEKEYBOARD_PCENH instead of DIDEVTYPEKEYBOARD_JAPAN106, so the Japanese key mapping in dinput is never used: @ and : are reported as 0x1a and 0x28 (US [ and ') instead of DIK_AT and DIK_COLON. - Ro, Yen and Henkan arrive with wrong DIK codes (0x59, 0x7c, 0x5c), Muhenkan and Katakana/Hiragana do not arrive in DirectInput at all. Applications that decide by the keyboard type how to show or bind keys show the wrong characters. A game I use with Wine shows [ for the @ key, ] for [ and ' for : in its key binding screen (correct on Windows with the same keyboard). STEPS TO REPRODUCE 1. XKB layout jp (e.g. setxkbmap jp, or Plasma with a Japanese keyboard layout). 2. LC_ALL=ja_JP.UTF-8 wine dinputtest32.exe -o test.log (attached test program, DirectInput 8 keyboard, buffered data, logs GetKeyboardType, MapVirtualKey and every DIK code). 3. Press @ [ ; : ] ^, Ro, Yen, Henkan, Muhenkan, Katakana/Hiragana, Esc to quit. The attached logs were made in Xvfb with keys sent through XTEST (kbd_drive.py), no input method. The Windows logs were made with the same scan codes injected through SendInput(KEYEVENTF_SCANCODE) (see logs/win/NOTE.txt in the archive). - Windows 11 (Japanese 106/109) | Wine 11.19 | Wine 11.19 + patch - GetKeyboardType(0) / (1): 7 / 2 | 7 / 0 | 7 / 2 - MapVirtualKey(VK_OEM_102 -> VSC): 0x73 | 0x59 | 0x73 - DirectInput device subtype: 10 (JAPAN106) | 4 (PCENH) | 10 (JAPAN106) - @ key: DIK_AT 0x91 | DIK 0x1a | DIK_AT 0x91 (*) - : key: DIK_COLON 0x92 | DIK 0x28 | DIK_COLON 0x92 (*) - Ro key: DIK 0x2b (BACKSLASH) | DIK 0x59 | DIK 0x2b (BACKSLASH) - Yen key: DIK_YEN 0x7d | DIK 0x7c | DIK_YEN 0x7d - Henkan / Muhenkan / Katakana: DIK_CONVERT 0x79 / DIK_NOCONVERT 0x7b / DIK_KANA 0x70 | 0x5c / none / none | DIK_CONVERT 0x79 / DIK_NOCONVERT 0x7b / DIK_KANA 0x70 (*) With the patch, dinput sets DIK_AT / DIK_COLON / DIK_CIRCUMFLEX in the device state (GetDeviceState; the game shows these keys correctly), but GetDeviceData does not return these key downs (Windows does return them, see the Windows logs). This is a separate, already existing dinput issue that only shows up once the keyboard is JAPAN106: keyboard_enum_objects() and keyboard_create_device() loop over the scan codes 0-0x1ff, and the extended scan codes 0x110-0x114 also map to DIK 0x90-0x94 (GetKeyNameText returns "Q", "W", ... for them), so DIK_CIRCUMFLEX, DIK_AT, DIK_COLON and DIK_KANJI are enumerated twice (see the OBJ lines in the logs). I can file it separately if that helps. PROPOSED PATCH Map the five keys to their set 1 scan codes in keyc2scan(), as the Japanese keyboard layout of Windows (and the Linux atkbd driver) does: KEY_KATAKANAHIRAGANA 0x70, KEY_RO 0x73, KEY_HENKAN 0x79, KEY_MUHENKAN 0x7b, KEY_YEN 0x7d. With the patch GetKeyboardType(1) returns 2, dinput reports DIDEVTYPEKEYBOARD_JAPAN106 and uses its existing Japanese DIK mapping, and the game shows the keys like on Windows. The patch only adds cases to the switch; the other layouts are not affected because these evdev keys do not exist on them. ENVIRONMENT - Ubuntu 26.04.1 LTS (Kubuntu, KDE Plasma 6.6, Wayland session; Wine runs on XWayland), x86_64. Found there with a Japanese 106/109 keyboard; the logged runs use Xvfb + openbox with the XKB layout jp (evdev keycodes), keys sent through XTEST, no input method (XMODIFIERS=@im=none). - Wine 11.19 built from the WineHQ source (configure --enable-archs=i386,x86_64, i.e. the new WoW64 mode), fresh prefix, LC_ALL=ja_JP.UTF-8, no DLL overrides when running the test (Mono/Gecko installation skipped while the prefix was created). Same results with Wine 11.19 + Staging. dlls/winex11.drv/keyboard.c is unchanged in current master (a15ee2cc, 2026-10-09). - Comparison: Windows 11 26H2, Japanese 106/109 keyboard (HKL 04110411), keys injected with SendInput(KEYEVENTF_SCANCODE). TEST PROGRAM dinputtest.c (attached, standalone) creates a window, a DirectInput 8 keyboard device (DISCL_FOREGROUND | DISCL_NONEXCLUSIVE, buffered data) and logs GetKeyboardType, MapVirtualKey for the Japanese keys, the device subtype, every WM_KEYDOWN / WM_CHAR (with the NumLock toggle state) and every DIK key down with its DIPROP_KEYNAME / DIPROP_SCANCODE. -hook installs a pass-through WH_KEYBOARD_LL hook, -o <file> sets the log file. Esc quits and writes a SUMMARY line. (The KEY vk=0xe5 lines in the Wine logs are bug 60449: Wine's builtin IME wraps every key in VK_PROCESSKEY, even without an input method. They are not related to this report.) Build: i686-w64-mingw32-gcc -O1 -o dinputtest32.exe dinputtest.c -ldinput8 -ldxguid -mwindows (64-bit: x86_64-w64-mingw32-gcc). -- 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 52254] New: Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea)
by WineHQ Bugzilla Oct. 10, 2026

Oct. 10, 2026

https://bugs.winehq.org/show_bug.cgi?id=52254 Bug ID: 52254 Summary: Cold Steel Subs: Application is not transparent (relies on DwmExtendFrameIntoClientArea) Product: Wine Version: 7.0-rc2 Hardware: x86-64 URL: https://zerofield.net/2020/09/30/hajimari-no-kiseki-sp readsheet-translation/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwmapi Assignee: wine-bugs(a)winehq.org Reporter: johnny(a)localmomentum.net Distribution: --- Created attachment 71376 --> https://bugs.winehq.org/attachment.cgi?id=71376 ColdSteelSubs transparency code (currently not in the distributed application) This application provides a transparent clickthrough overlay to show English translations on top of the original Japanese source. It relies on layered windows and DwmExtendFrameIntoClientArea to handle the transparent display. Currently, the main UI elements show, but the game (or any other application) does not show through. This seems to be because DwmExtendFrameIntoClientArea is only a stub. I'm not sure if that's the only reason it's not transparent, but it's at least one of the reasons. The program itself uses the unity3d engine along with some native dll calls to the relevant user32 apis to handle the transparency. I was able to get a copy of the relevant code (but not the whole application), of which I will attach. Since I can't get all of the code, I've been using an unity sample application to try to figure out some parts myself (the relevant code is here https://github.com/pheonise/Unity3D-Desktop-Overlay/blob/master/Assets/Scri…) This unity3d application works as expected on windows, but is not transparent via wine (as expected). When i comment the call to DwmExtendFrameIntoClientArea, then it its also no longer transparent on windows as well. It seems that if the sample application works, then I can make sure the dev applies to the same technique to the overlay application. Please let me know If i can provide any more information. -- 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 19

[Bug 60439] New: SafeDisc driver for The Sims 1 (all versions) failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\Secdrv" - Broken since wine 7?
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=60439 Bug ID: 60439 Summary: SafeDisc driver for The Sims 1 (all versions) failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Serv ices\\Secdrv" - Broken since wine 7? Product: Wine Version: 11.19 Hardware: x86-64 OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: blayer98(a)outlook.com Target Milestone: --- Created attachment 82257 --> http://bugs.winehq.org/attachment.cgi?id=82257 Log for Sims 1 on vanilla wine not launching due to SafeDisc bug since 6.3 Hello, I've attempted to install The Sims (Base game, Livin' Large, Hot Date, etc.) on all wine versions after 6.3, and it appears that a regression has popped up making the physical versions of these games unplayable due to the SafeDisc DRM not working on any wine version other than 6.3 and potentially lower. -- 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 15

[Bug 58878] New: Norwegian version of "Who Wants To Be A Millionaire" did not works
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=58878 Bug ID: 58878 Summary: Norwegian version of "Who Wants To Be A Millionaire" did not works Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lars_martin4(a)hotmail.com Distribution: --- larsmartinhambro(a)fedora-linux:~/.wine/drive_c/Program Files (x86)/Eidos Interactive/HotHouse Creations/Vil Du Bli Millionær$ dir BINKW32.DLL Data Game.exe SMACKW32.DLL Viktig.rtf larsmartinhambro(a)fedora-linux:~/.wine/drive_c/Program Files (x86)/Eidos Interactive/HotHouse Creations/Vil Du Bli Millionær$ wine Game.exe 002c:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. 0090:err:environ:init_peb starting L"C:\\Program Files (x86)\\HDD Health\\HDDHealthService.exe" in experimental wow64 mode 0090:fixme:heap:RtlSetHeapInformation HEAP_INFORMATION_CLASS 1 not implemented! 00c8:err:environ:init_peb starting L"C:\\Program Files (x86)\\ASUS\\AXSP\\4.00.38\\atkexComSvc.exe" in experimental wow64 mode 00c8:fixme:ole:CoInitializeSecurity 00000000, -1, 00000000, 00000000, 6, 3, 00000000, 2, 00000000 stub 00c8:fixme:wbemprox:client_security_SetBlanket 79273934, 00C145B8, 10, 0, (null), 4, 3, 00000000, 0 00c8:fixme:wbemprox:client_security_Release 79273934 00c8:fixme:wbemprox:client_security_Release 79273934 00c8:fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x10 wine: Unhandled page fault on read access to 00000000 at address 793A43CD (thread 00c8), starting debugger... 00d0:err:environ:init_peb starting L"C:\\windows\\syswow64\\winedbg.exe" in experimental wow64 mode 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0070:err:ole:start_rpcss Failed to start RpcSs service 00e4:err:ole:start_rpcss Failed to start RpcSs service 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0070:err:ole:start_rpcss Failed to start RpcSs service 003c:err:service:process_send_start_message service L"asComSvc" failed to start 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"asComSvc" failed to start: 1053 0100:err:environ:init_peb starting L"C:\\windows\\syswow64\\winedevice.exe" in experimental wow64 mode 010c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\win32k.sys" 010c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgkrnl.sys" 010c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgmms1.sys" 0108:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\SecDrv": c0000142 003c:fixme:service:scmdatabase_autostart_services Auto-start service L"SecDrv" failed to start: 1114 014c:err:environ:init_peb starting L"C:\\Program Files (x86)\\Electronic Arts\\Medal of Honor Airborne\\UnrealEngine3\\MOHAGame\\pb\\PnkBstrA.exe" in experimental wow64 mode 0024:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 0024:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. 01e4:err:environ:init_peb starting L"C:\\Program Files (x86)\\Eidos Interactive\\HotHouse Creations\\Vil Du Bli Million\00e6r\\Game.exe" in experimental wow64 mode 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0058:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d02c (device=4 access=3 func=40b method=0) 0204:err:environ:init_peb starting L"C:\\users\\larsmartinhambro\\AppData\\Local\\Temp\\~ef7194.tmp" in experimental wow64 mode 0210:err:environ:init_peb starting L"C:\\windows\\syswow64\\winedevice.exe" in experimental wow64 mode 021c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\win32k.sys" 021c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgkrnl.sys" 021c:err:ntoskrnl:ServiceMain Failed to load L"C:\\windows\\system32\\drivers\\dxgmms1.sys" 0218:err:ntoskrnl:ZwLoadDriver failed to create driver L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\SecDrv": c0000142 larsmartinhambro(a)fedora-linux:~/.wine/drive_c/Program Files (x86)/Eidos Interactive/HotHouse Creations/Vil Du Bli Millionær$ 0224:fixme:winediag:loader_init wine-staging 10.15 is a testing version containing experimental patches. 0224:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. -- 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 60469] New: BioShock 2 Remastered crashes when starting or loading a game with WineD3D/OpenGL in new WoW64
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=60469 Bug ID: 60469 Summary: BioShock 2 Remastered crashes when starting or loading a game with WineD3D/OpenGL in new WoW64 Product: Wine Version: 11.19 Hardware: x86-64 URL: https://store.steampowered.com/app/409720/BioShock_2_R emastered/ OS: Linux Status: NEW Keywords: wow64 Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82300 --> http://bugs.winehq.org/attachment.cgi?id=82300 backtrace BioShock 2 Remastered (32-bit, Direct3D 11, GOG and Steam version) crashes when starting a new game or loading a saved game with Wine's builtin dxgi.dll and d3d11.dll. Reproduced with Nouveau/Mesa 26.2.4 (NVK/Zink) and with NVIDIA driver 615.71.09. Both EGL and GLX backends are affected. Doesn't occur in a legacy shared-WoW. Doesn't occur with DXVK's dxgi.dll and d3d11.dll Steps to reproduce: - Start a new game. The loading screen and first introductory video appear, but skipping the video with Esc causes a crash. - Alternatively, load a saved game. The game crashes at the end of loading. Workarounds: Either of the following prevents the loading crash: - Setting `HavokNumThreads=1` instead of the default value of 2. This game option can be found in the Bioshock2SP.ini configuration file in ../drive_c/users/<username>/AppData/Roaming/BioshockHD/. This workaround works only with NVIDIA proprietary driver. - Applying `keep-vulkan-mapping.patch` from bug #60354 (attachment #82142), which retains the underlying Vulkan buffer mapping across GL map/unmap calls. This also works with `HavokNumThreads=2`. Changing `UseMultithreadedRendering` to True/1 does not help. For this "new-game/save-loading" issue, setting HavokNumThreads=1 does not prevent the crash with nouveau/Mesa configuration, although it does with the proprietary NVIDIA driver. The keep-vulkan-mapping.patch prevents the loading crash with both driver stacks. This further supports investigating the underlying buffer-mapping lifetime, while showing that reducing HavokNumThreads is not a reliable workaround across configurations. wine-11.19-151-g20315474eb2 -- 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 60468] New: ntdll: LFH never activates for 1-32 KiB bins under alloc/free churn; multithreaded HeapAlloc/HeapFree serializes on the heap lock
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=60468 Bug ID: 60468 Summary: ntdll: LFH never activates for 1-32 KiB bins under alloc/free churn; multithreaded HeapAlloc/HeapFree serializes on the heap lock Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: taras.official.131(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82296 --> http://bugs.winehq.org/attachment.cgi?id=82296 Reproducer source When several threads repeatedly allocate and free short-lived blocks between 1 KiB and 32 KiB on the process heap, Wine never enables the LFH frontend for those sizes, so every HeapAlloc/HeapFree goes through heap->cs. With a few threads the critical section becomes a convoy and total throughput collapses far below single-threaded speed. Cause: bin_try_enable() in dlls/ntdll/heap.c only applies the allocation-count heuristic (alloc > 0x800) to bins < 0x30, i.e. blocks up to 1 KiB. Larger bins are only enabled once more than 4 MiB worth of blocks are live at the same time (alloc - freed > 0x400000 / block_size), e.g. more than 1724 live blocks for the 2432-byte bin. Code that churns temporaries keeps only a handful alive, so those bins are never enabled. I found this while profiling a D3D12 game under Proton. About 15 job threads performed roughly 160,000 HeapAlloc/HeapFree pairs per second on 2312-byte blocks. perf (LBR call stacks) showed about 22% of all user-space CPU time in ntdll's internal spin_lock, reached via RtlpWaitForCriticalSection / RtlWakeAddressSingle from RtlEnterCriticalSection / RtlLeaveCriticalSection in RtlAllocateHeap / RtlFreeHeap, and about 36% of the time in heap locking overall. Hardware-breakpoint sampling of heap_allocate_block showed 99.8% of the locked-path allocations were 2312 bytes. The attached standalone reproducer (heapchurn.c) shows the same behaviour without the game: N threads each keep 4 live blocks and free + allocate in a loop for 3 seconds. Results on an i7-14650HX (8P+8E, 24 threads), Linux 7.2.9, in millions of alloc+free per second: 1 thr/1000 B 15 thr/1000 B 1 thr/2312 B 15 thr/2312 B Wine 11.19 (upstream) 16.06 183.48 6.47 0.37 Proton-CachyOS 11.0 16.69 195.56 0.53 0.50 Proton-CachyOS 11.0 + LFH change 16.72 191.67 13.74 192.70 1000-byte blocks (bin < 0x30, LFH enabled after 2048 allocations) scale with threads as expected. On upstream Wine, 2312-byte blocks run about 17x slower with 15 threads than with 1. The "+ LFH change" row is a binary patch of Proton-CachyOS's ntdll that enables these bins as soon as they are in use. The proposed source change (attached diff) instead applies the existing count-based rule to all bins: - else if (bin - heap->bins < 0x30 && alloc > 0x800) enable = TRUE; + else if (alloc > 0x800) enable = TRUE; For this workload both behave the same, since 2048 locked allocations happen within milliseconds. The cost is extra LFH group memory for bins that exceed 2048 allocations; I have not measured that, and I have not run the reproducer on Windows for comparison. Steps to reproduce: 1. x86_64-w64-mingw32-gcc -O2 -o heapchurn.exe heapchurn.c 2. wine heapchurn.exe 1 2312 4 3 (one thread) 3. wine heapchurn.exe 15 2312 4 3 (15 threads: total throughput drops instead of scaling) 4. wine heapchurn.exe 15 1000 4 3 (same test, 1000-byte blocks: scales normally) Attachments: - heapchurn.c reproducer source - results.txt raw output of the runs above - 0001-ntdll-enable-lfh-for-larger-bins.diff proposed change against current master -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 60467] New: BioShock 2 Remastered crashes when applying display settings: NULL output in D3D11 FinishCommandList
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=60467 Bug ID: 60467 Summary: BioShock 2 Remastered crashes when applying display settings: NULL output in D3D11 FinishCommandList Product: Wine Version: 11.19 Hardware: x86-64 URL: https://store.steampowered.com/app/409720/BioShock_2_R emastered/ OS: Linux Status: NEW Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82293 --> http://bugs.winehq.org/attachment.cgi?id=82293 backtrace BioShock 2 Remastered (32-bit, Direct3D 11) crashes when applying changes in the Graphics Options menu with Wine's builtin dxgi.dll and d3d11.dll. The crash is reproducible with both the GOG and Steam versions. Native d3dx9_43.dll and d3dcompiler_43.dll installed and used during testing. This appears related to, and may be a duplicate of Wine bug #51211. I'm filing a new report to document the identified failing API call, the root cause in Wine's D3D11 implementation, and a tested patch. Steps to reproduce: 1. Launch BioShock 2 Remastered and open Graphics Options. 2. Change VSync, screen resolution, or Fullscreen to Windowed mode. 3. Click Apply -> the game crashes. Reproducible with both legacy shared-WoW and new WoW64 builds. Using DXVK's dxgi.dll and d3d11.dll avoids these crashes. **The analysis below and the resulting patch were created with AI assistance** When applying display settings, the game calls: ID3D11DeviceContext::FinishCommandList(FALSE, NULL) A D3D11/SEH log shows: ... d3d11_device_context_FinishCommandList iface 006C3208, restore 0, command_list 00000000. d3d11_device_context_FinishCommandList Created command list 006646E8. dispatch_exception code=c0000005 (EXCEPTION_ACCESS_VIOLATION) ... addr=782D9244 ... In dlls/d3d11/device.c, Wine creates the command list and then unconditionally writes through the caller's output pointer: *command_list = &object->ID3D11CommandList_iface; Because `command_list` is NULL, this causes an access violation. Microsoft documents the [`ppCommandList` parameter as optional](https://learn.microsoft.com/en-us/windows/win32/api/d3d11/nf-d3d1…. The initial D3D11 access violation is followed by a C++ exception. Consequently, the final backtrace points to `_CxxThrowException` in msvcr110 and `RaiseException` in kernelbase, obscuring the original failure in d3d11. wine-11.19-151-g20315474eb2 OS: Arch Linux GPU: NVIDIA GeForce GTX 1660 SUPER NVIDIA driver: 615.71.09 -- 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 59901] New: Nintendo Switch Pro Controller is forced as a DirectInput device
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=59901 Bug ID: 59901 Summary: Nintendo Switch Pro Controller is forced as a DirectInput device Product: Wine Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: hibbsncc1701(a)gmail.com Distribution: --- The Nintendo Switch Pro Controller in USB mode (idVendor=057e, idProduct=2009, bcdDevice= 2.00) gets forced into being a DirectInput device on all subsequent prefix launches after the first one when it is plugged in. I.e. When the controller is first detected by a prefix, it's detected correctly as a xinput controller, but after that initial detection done by the prefix, all subsequent launches of that prefix force it into being a DirectInput device. xinput will report no connected controllers to apps, but the "Game Controllers" control panel applet will still show it's button presses on the xinput tab, and all others. The Joysticks tab claims it's DirectInput. Attempting to reset the pro controller back to xinput fails. (The reset button on the joysicks tab doesn't do anything.) Deleting the prefix and recreating it forces wine back into the initial detection behavior, but exiting and relaunching the prefix causes the bug to occur again. Pulling up regedit shows nothing in HKCU\Software\Wine\DirectInput or HKCU\Software\Wine\DirectInput\Joysticks. Looking under HKCU\System\CurrentControlSet\Control\MediaProperties\PrivateProperties\DirectInput shows a key with the controller's VID and PID. (Along with \calibration\0 subkeys.) Deleting the key with the controller's VID and PID, exiting and relaunching the prefix makes wine redetect the controller as xinput again, but the registry key gets recreated and the bug occurs again on subsequent prefix launches. So it appears the existence of this key overrides the xinput controller to DirectInput, but wine's Control Panel applet cannot reset it. Nor is it possible to keep it as a xinput device. -- 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 60465] New: nsiproxy never drops vanished network interfaces; GetAdaptersAddresses and InternetGetConnectedState slow down as containers come and go
by WineHQ Bugzilla Oct. 9, 2026

Oct. 9, 2026

http://bugs.winehq.org/show_bug.cgi?id=60465 Bug ID: 60465 Summary: nsiproxy never drops vanished network interfaces; GetAdaptersAddresses and InternetGetConnectedState slow down as containers come and go Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: iphlpapi Assignee: wine-bugs(a)list.winehq.org Reporter: alexfunk1222(a)gmail.com Target Milestone: --- Distribution: --- The Witcher 3 (Steam 292030, 4.x "next-gen" build, DX12) calls wininet!InternetGetConnectedState about 10 times a second on its main thread. Under Wine each call rebuilds the full adapter list, and the cost keeps growing on a host where network interfaces come and go (Docker/Podman containers, VMs, VPNs), because nsiproxy never forgets an interface. In the game (Proton) this was a 35 ms stall every ~100 ms: 55-63 fps with a 1% low of 17-20, against 88 fps and a 1% low of 63 with the result cached for 2 s in a proxy DLL. Three parts of the current code add up (read at master 63f62f7cd696; Proton 10.0 and 11.0 are the same): 1. dlls/nsiproxy.sys/ndis.c, update_if_table(): adds each interface if_nameindex() returns and never removes one. An interface that is gone stays in if_list for the life of winedevice.exe, and GetAdaptersAddresses keeps returning it. 2. ifinfo_enumerate_all() calls ifinfo_fill_dynamic() for every entry in if_list, and each call opens and scans all of /proc/net/dev (plus a socket, SIOCGIFFLAGS, SIOCGIFMTU and a /sys carrier read). Every /proc/net/dev read makes the kernel collect statistics for every interface on the host, so one enumeration costs (entries in if_list) x (host interfaces) of that work. Some drivers are slow at it: here the Realtek r8127 driver dumps hardware counters, and one /proc/net/dev read takes 0.059 ms natively. 3. dlls/wininet/internet.c, InternetGetConnectedStateExW(): no cache, and GetAdaptersAddresses is called twice per call (a size probe with a NULL buffer, then the fill); GetAdaptersAddresses builds the whole list for the size probe too. That comes to about four ifinfo enumerations per call. adapters_addresses_alloc() also makes one ConvertInterfaceLuidToGuid() round trip to winedevice per interface, though stat[i].if_guid is already in the table it just fetched. Reproducer (attached, also at https://github.com/a-funk/GameSpark/blob/4e39f2711db06bfaeb0794e23e2f0ca823…) times InternetGetConnectedState, GetAdaptersAddresses and ConvertInterfaceLuidToGuid; then polls InternetGetConnectedState at 10 Hz for the given number of seconds and times them again. x86_64-w64-mingw32-gcc -O2 -mwindows -o igcs_cost.exe igcs_cost.c -lwininet -liphlpapi wine igcs_cost.exe 50 out.txt 150 & for i in $(seq 70); do docker run --rm alpine true; done # while it polls Results, each in a fresh prefix on a host with 11 interfaces: adapters InternetGetConnectedState GetAdaptersAddresses Wine 11.19 (WineHQ Ubuntu 24.04 build) start 11 5.0 ms 2.5 ms after 70 containers came and went 115 39.8 ms 21.3 ms Proton Experimental 11.0-20261001 start 11 7.0 ms 3.5 ms after 70 containers came and went 100 45.4 ms 21.3 ms At the end, all but 11 of the adapters no longer existed. In the game, a +iphlpapi,+nsi trace showed 81 ConvertInterfaceLuidToGuid calls per GetAdaptersAddresses (1,047,767 over 12,879), i.e. 81 entries against 11 real interfaces, while another workload on the host started and removed 634 containers. Setup and caveats: NVIDIA DGX Spark (ARM64, Ubuntu 24.04, kernel 6.17.0-1029-nvidia). The x86-64 Wine builds run under the FEX emulator, so Wine's own code runs translated; the /proc/net/dev reads run natively and are roughly half to two thirds of the cost after the churn (estimated from the native read time). Not measured on an x86-64 host, though the code paths above are the same. Possible fixes, smallest first: - update_if_table(): drop entries whose index is no longer in the if_nameindex() result. - ifinfo_enumerate_all(): read /proc/net/dev once per enumeration, not once per interface. - adapters_addresses_alloc(): use stat[i].if_guid instead of ConvertInterfaceLuidToGuid(). - InternetGetConnectedStateExW(): try a buffer sized for typical hosts first so GetAdaptersAddresses usually runs once, or cache the answer briefly. The analysis and the test program were prepared with help from an AI assistant (Claude). The test program is only a reproducer and is not proposed for inclusion in Wine; the fixes above are described rather than written as code, in line with the project's policy on LLM-generated code. -- 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 60394] New: Kubios HRV Scientific installer crashes
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60394 Bug ID: 60394 Summary: Kubios HRV Scientific installer crashes Product: Wine Version: 6.0.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: ck(a)wisdomtree.dev Target Milestone: --- Distribution: --- Created attachment 82189 --> http://bugs.winehq.org/attachment.cgi?id=82189 From the popup I'm using an old version of Wine on Ubuntu 22 so I don't know if this is still a problem, but this installer crashes: KubiosHRVScientific_4.3.0_setup.exe That's the free version from kubios.com/hrv-scientific-lite I've attached what's in the popup, and the console says: MESA-INTEL: warning: Haswell Vulkan support is incomplete 00a8:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@mscms.dll,-1" -> L"C:\\windows\\system32\\spool\\drivers\\color\\srgb color space profile.icm" 00a8:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@C:\\windows\\system32\\ws2_32.dll,-1" -> L"C:\\windows\\system32\\drivers\\etc\\hosts" 00a8:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@C:\\windows\\system32\\ws2_32.dll,-2" -> L"C:\\windows\\system32\\drivers\\etc\\networks" 00a8:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@C:\\windows\\system32\\ws2_32.dll,-3" -> L"C:\\windows\\system32\\drivers\\etc\\protocol" 00a8:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@C:\\windows\\system32\\ws2_32.dll,-4" -> L"C:\\windows\\system32\\drivers\\etc\\services" 00a8:err:setupapi:SetupDefaultQueueCallbackW copy error 1812 L"@wineusb.sys,-1" -> L"C:\\windows\\inf\\wineusb.inf" Could not find Wine Gecko. HTML rendering will be disabled. Could not find Wine Gecko. HTML rendering will be disabled. wine: configuration in L"/home/moi/.wine" has been updated. 0140:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. wine: Unhandled page fault on write access to 0000000000000000 at address 00000003A0452A59 (thread 0134), starting debugger... -- 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 59751] New: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=59751 Bug ID: 59751 Summary: WizTree 4.30: Dropdown menu fails to redraw hovered items with active visual style Product: Wine Version: 11.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Created attachment 80933 --> http://bugs.winehq.org/attachment.cgi?id=80933 Dropdown menu screenshot https://diskanalyzer.com/files/archive/wiztree_4_30_setup.exe WizTree 4.30 download link Dropdown menu fails to redraw hovered items with active visual style of WizTree -- 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 43991] New: Window disappears while changing applications
by wine-bugs＠winehq.org Oct. 8, 2026

Oct. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=43991 Bug ID: 43991 Summary: Window disappears while changing applications Product: Wine Version: 2.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: anonymous.maarten(a)gmail.com Distribution: --- Hey, When changing applications using ALT+TAB or using the WIN key in Gnome 3, the window of this application disappears. It is thus impossible to go to this application using ALT+TAB. Gnome is running on Wayland (if that would matter). Application name: RW Analyze 0.4 Beta URL: http://www.steve-m.com/downloads/tools/rwanalyze/ $ wine --version wine-2.19 (Staging) $ cat /etc/fedora-release Fedora release 26 (Twenty Six) $ sha1sum RWAnalyze.exe 43504ea98322c97311318373050ffa33b30671ca RWAnalyze.exe $ du -b RWAnalyze.exe 265728 RWAnalyze.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.

2 5

[Bug 60464] New: Direct2D collinear joins extend a stroked open path past its endpoint
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60464 Bug ID: 60464 Summary: Direct2D collinear joins extend a stroked open path past its endpoint Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d2d Assignee: wine-bugs(a)list.winehq.org Reporter: rod.huffaker(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82289 --> http://bugs.winehq.org/attachment.cgi?id=82289 pedigree-line-join-probe.c — standalone C pixel reproducer (AI-assisted) A collinear intermediate vertex causes a Direct2D stroked open path to extend well beyond its endpoint. This produces extra tails on connectors in RootsMagic 11's Pedigree and Family views. The attached standalone C reproducer requires no RootsMagic installation or database. It creates a 64x64 DXGI surface at 192 DPI and draws a 1.5-DIP black stroke on a gray background. It compares: 1. A single segment from (2,16) to (8,16). 2. The same path with an intermediate vertex at (6,16). Expected: both paths leave the pixel at x=25 DIP (device pixel x=50, y=32) gray. Actual: the single-segment control leaves it gray, but the collinear path makes it black. Test environment: Linux Mint 22.3, x86_64; 32-bit D3D11/Direct2D; Wine 11.17 Direct2D sources used with this project's Wine 11.0 loader/runtime; Vulkan renderer; 192 DPI. This was a local mixed-version runtime, not a complete stock Wine 11.17 installation. We have not verified the latest unmodified Wine release or run this probe on native Windows. Build: i686-w64-mingw32-gcc -std=c99 -O2 -Wall -Werror pedigree-line-join-probe.c -o probe.exe -ld2d1 -ld3d11 -ldxguid -luuid -lole32 Run: WINEPREFIX=/path/to/test-prefix WINEDLLOVERRIDES='d2d1,dwrite=b;d3d11,d3d10core,dxgi=b' WINE_D3D_CONFIG=renderer=vulkan WINEDEBUG=-all wine probe.exe Recorded results: without the local join fix, the control sampled inside=0, beyond=128, while the collinear case sampled inside=0, beyond=0 (exit 1). With the local join fix both cases sampled inside=0, beyond=128 (exit 0). Investigation points to d2d_geometry_outline_add_join() in dlls/d2d1/geometry.c. The straight-through vertex takes the ccw == 0 branch, which creates join vertices 25 units away. A local proof-of-concept skips the join when ccw == 0 and the normalized tangent dot product is negative, retaining the reversal case. This corrected the pixel probe and the visible connector tails in both application views. This is a diagnosis to review, not a claim of a fully validated upstream fix. This report and standalone reproducer were prepared with AI assistance. -- 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 57749] New: Application crashes when ToastNotification from Windows.UI.Notifications used
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=57749 Bug ID: 57749 Summary: Application crashes when ToastNotification from Windows.UI.Notifications used Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gudvinr+wine(a)gmail.com Distribution: --- Application I run uses Windows.UI.Notifications.ToastNotification class (https://learn.microsoft.com/en-us/uwp/api/windows.ui.notifications.toastnot…) Apparently, when it tries to show notification, app crashes: System.TypeLoadException: Could not find Windows Runtime type 'Windows.UI.Notifications.ToastNotification' -- 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 2

[Bug 60463] New: ARM64EC: re-exported (-import) functions start with a bare x64 jmp [rip+x], which x64 hook detectors flag as an inline hook
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60463 Bug ID: 60463 Summary: ARM64EC: re-exported (-import) functions start with a bare x64 jmp [rip+x], which x64 hook detectors flag as an inline hook Product: Wine Version: unspecified Hardware: aarch64 OS: Android Status: UNCONFIRMED Severity: normal Priority: P2 Component: tools Assignee: wine-bugs(a)list.winehq.org Reporter: tarikcaramanico(a)gmail.com Target Milestone: --- On ARM64EC, functions that a DLL re-exports from another DLL (-import in the .spec file; kernel32.spec has many) are exported as lld's x64 import thunk, a bare FF 25 00000000 (jmp *__imp_X(%rip)). x64 code that resolves such an export (GetProcAddress) sees a function that starts with a 6-byte indirect jump, and x64 hook detectors in games treat that start as an inline hook. On x86_64 Wine the same export starts with winebuild's hot-patch prolog instead. - winebuild, x86_64: the end of output_exports in tools/winebuild/spec32.c (lines 585-622 at 63f62f7cd696) emits for every -import entry eight nops, the label __wine_spec_imp_<name>, the hot-patch prolog 48 8D A4 24 00 00 00 00 and jmp *__imp_<name>(%rip); the export points at that thunk. - winebuild, ARM64EC: the start of the same function (lines 414-439) writes only .drectve directives -export:Name=Name,@ord, so the plain Name of an import is lld's x64 import thunk. - lld: importThunkX86[] = {0xff, 0x25, 0x00, 0x00, 0x00, 0x00} (lld/COFF/Chunks.h). Exports whose target is ARM64EC code get a fast-forward sequence (48 8B C4 48 89 58 20 55 5D E9 ...), as Microsoft's toolchain does; an import thunk gets none. How it shows: Age of Empires IV checks 63 Windows API functions at start-up. Under Proton 11 ARM64EC (GameNative, Android) with FEX, 27 of them were flagged, all in kernel32's .text, all starting with FF 25. Presenting the same jumps as 48 FF 25 (a test change in the emulator) made the check flag nothing. Possible fix (not tested): for ARM64EC -import entries, emit the same x86_64 thunk as on x86_64 and point the -export: directive at it (MR !11975, winebuild assembling ARM64EC output as x86_64, looks like the base for this). arm64x_check_call (dlls/ntdll/signal_arm64ec.c) follows a bare FF 25 so that ARM64EC callers skip the emulator; it would then need to skip the hot-patch prolog as well. Not checked: what Microsoft's own ARM64X kernel32 or link.exe produce for a re-exported import. -- 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 60462] New: NtPowerInformation(ProcessorInformation) opens two cpufreq files per CPU on every call
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60462 Bug ID: 60462 Summary: NtPowerInformation(ProcessorInformation) opens two cpufreq files per CPU on every call Product: Wine Version: unspecified Hardware: aarch64 OS: Android Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: tarikcaramanico(a)gmail.com Target Milestone: --- NtPowerInformation(ProcessorInformation) (dlls/ntdll/unix/system.c, master 63f62f7cd696, lines 4682-4730) opens /sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_max_freq and scaling_max_freq for every CPU on every call, with no caching (CurrentMhz is set to MaxMhz anyway). Some games call CallNtPowerInformation(ProcessorInformation) every frame. Age of Empires IV does, about 45 times per second in a match. On an 8-core Snapdragon 8 Gen 2 (Proton 11 ARM64EC through GameNative, Android) one call took 228.5 us on average (200 calls, game idle at its menu), and in a late-game replay the call took 11 % of the game's main thread. Answering repeat calls from a cache for 250 ms (done outside Wine, in the emulator layer, as a test) brought that to 1.7 % and gave about +0.5 FPS. Possible fix: read cpuinfo_max_freq once, and cache scaling_max_freq for a short time (it can change with power and thermal policy, so not forever). See also bug 58397: battery state queries through NtPowerInformation also read sysfs on every call. -- 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 60461] New: ARM64EC: after a raw x64 syscall instruction, rcx holds the status and r10 the return address
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60461 Bug ID: 60461 Summary: ARM64EC: after a raw x64 syscall instruction, rcx holds the status and r10 the return address Product: Wine Version: unspecified Hardware: aarch64 OS: Android Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: tarikcaramanico(a)gmail.com Target Milestone: --- On x86-64, SYSCALL copies the return address into rcx and rflags into r11, and SYSRET returns through them, so after any syscall rcx holds the address of the next instruction. Native x64 Wine does the same (rcx = rip, r11 = eflags, MR !282). Under ARM64EC, an x64 syscall instruction executed by emulated code goes through dispatch_syscall (dlls/ntdll/signal_arm64ec.c), which resumes the x64 code at invoke_arm64ec_syscall (dlls/ntdll/signal_x86_64.c). That helper calls the syscall like a function: callq *(%r10,%rax,8) movq (%rsp),%r10 pushq 8(%rsp) /* restore ret to caller */ pushq %r10 /* and return to syscall thunk */ ret so the x64 code gets back rax = status, rcx = status (x0 after the ARM64EC entry thunk), r10 = the return address, and rdx/r8/r9/r11 = whatever the ARM64EC callee left in x1-x3/x5. The helper also writes the caller's home slots at [rsp+8] and [rsp+16]. Measured on Proton 11 ARM64EC (GameNative) with FEX on a Snapdragon 8 Gen 2 (Android): a test program loads marker values, issues one raw syscall for NtYieldExecution (number 0x46, taken from ntdll's own x64 stub) and dumps the registers afterwards: register x86-64 hardware Wine ARM64EC rax status 0x40000024 (status) rcx return address (0x1400016cb) 0x40000024 (the status) r10 not defined by the instruction 0x1400016cb (the return address) rdx not defined by the instruction changed (a stack address) Code that checks rcx after its own syscall (some anti-tamper and DRM does) sees a difference from any real x86-64 machine. The code is the same in current master (63f62f7cd696): dispatch_syscall at signal_arm64ec.c:1281-1294 and invoke_arm64ec_syscall at signal_x86_64.c:65-74, unchanged since 8043e1f6b8b7. Expected: rcx = return address and r11 = rflags after the syscall, and the caller's stack above the return address left alone, as on hardware and in native x64 Wine. -- 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 44743] New: Segfault in Wine-d3d. Affected; Anno1404, LAA flag set
by wine-bugs＠winehq.org Oct. 8, 2026

Oct. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=44743 Bug ID: 44743 Summary: Segfault in Wine-d3d. Affected; Anno1404, LAA flag set Product: Wine Version: 3.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: aphid.mmonly(a)gmail.com Distribution: --- Created attachment 60753 --> https://bugs.winehq.org/attachment.cgi?id=60753 Stack backtrace and loaded libraries To reproduce the specific segfault: 1) Install Anno1404, either the steam version or the GoG one. 2) Patch the I.A.A.M. mod over Anno 1404 3) Apply the '4gb patch' to the result (or flag the executable as large-address-aware). 4) Launch the game, play a big map for about 60-70 minutes (or leave it running for that long). Wined3d will segfault at address (+0x34dee) (0x0033f038), according to winedbg. See the attached file for more information. As far as I've tested, it's always that exact spot where the fault happens. Without a debugger attached, a user would experience a freezing program. If ran in full-screen mode, it will also lock up your X session, requiring the user to terminate the wine application from another tty console. -- 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 5

[Bug 60458] New: GTA V Crashing With Wine-11.19 Release
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

http://bugs.winehq.org/show_bug.cgi?id=60458 Bug ID: 60458 Summary: GTA V Crashing With Wine-11.19 Release Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: regression Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: j56cc4cmf(a)mozmail.com Target Milestone: --- Distribution: --- Created attachment 82282 --> http://bugs.winehq.org/attachment.cgi?id=82282 Logs contain the crash issue Howdy Since Wine-Staging released with 11-19 GTA V is crashing as soon as it start not even making it to the loading screen at all. The same happens with the stable version as well. Proton could not even make it to launch the reason using Wine was more pleasing. Before versions as 11-17/18 works perfectly the game boots up and is playable as well with or without overrides. Logs contain the crash issue and also both with/without overrides test as well using +wgl,+d3d,+dxgi. Thanks ! -- 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 48406] New: Epic Games Store fails to install prerequisites with Wine Mono
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=48406 Bug ID: 48406 Summary: Epic Games Store fails to install prerequisites with Wine Mono Product: Wine Version: 5.0-rc3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: sashok.olen(a)gmail.com Distribution: --- Created attachment 66178 --> https://bugs.winehq.org/attachment.cgi?id=66178 log To reproduce the issue, you just need to install Epic Games Store with Wine Staging. After you launch it and it downloads its own files, it will try to install its "prerequisites", which will fail with Wine Mono. The issue disappears if you install "dotnet48" using winetricks, or if you launch EGS with -SkipBuildPatchPrereq flag, but neither are really good solutions as some games don't seem to work with dotnet48 and -SkipBuildPatchPrereq sometimes doesn't work. Should be noted that on real Windows, it seems to install dotnet48 using "Windows Features" component. Attaching standard debug output. Let me know if you need a log with additional debug channels. -- 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 14

[Bug 55669] New: Vulkan is broken on the Wayland driver
by WineHQ Bugzilla Oct. 8, 2026

Oct. 8, 2026

https://bugs.winehq.org/show_bug.cgi?id=55669 Bug ID: 55669 Summary: Vulkan is broken on the Wayland driver Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: m1m1k4tz(a)protonmail.com Distribution: --- When using the Wayland driver you get a error that says Failed to load Wine graphics driver supporting Vulkan. -- 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 15