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

[Bug 60216] New: notepad (and every application): grayed menu items are drawn in a fixed gray 0x808080, ignoring the GrayText system color
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60216 Bug ID: 60216 Summary: notepad (and every application): grayed menu items are drawn in a fixed gray 0x808080, ignoring the GrayText system color Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: loic.simond(a)protonmail.com Target Milestone: --- Distribution: --- Created attachment 81916 --> http://bugs.winehq.org/attachment.cgi?id=81916 Grayed 'Undo' in notepad on wine-11.16: default Aero prefix (top) and custom scheme (bottom), at rest and highlighted - text is 0x808080 in all four, GrayText is 106 106 106 / 0 200 0 Disabled (grayed) menu items do not follow the GrayText system color. Their text is always drawn in gray 0x808080, with a white copy offset by +1,+1 (embossed look) when the item is not highlighted. This happens in every application, including Wine's builtin notepad, with Wine's default configuration. Steps to reproduce, in a clean 64-bit prefix (no override, nothing changed): export WINEPREFIX=~/wine-bugtest wineboot wine reg query "HKCU\Control Panel\Colors" /v GrayText wine notepad In a new prefix the bundled Aero theme is active by default and the query shows GrayText = 106 106 106 (from the [SysMetrics] section of dlls/aero.msstyles/aero.rc). In notepad, open the Edit menu: "Undo" is grayed. Observed: "Undo" and its "Ctrl+Z" column are drawn in 0x808080 with a white (0xFFFFFF) copy shifted one pixel down-right (invisible on the white Aero menu, plainly visible on the dark scheme below); when highlighted, in 0x808080 on the highlight color (0x3096FA). Measured on the attached screenshots: the "Undo" row contains the exact value 0x808080 in both states, and 0x6A6A6A never appears. Expected: the text drawn with the GrayText system color (0x6A6A6A here), the way every other menu color (Menu, MenuText, Hilight...) follows the scheme. With a custom color scheme the effect is much worse. For instance, in the same prefix: wine reg add "HKCU\Control Panel\Colors" /v GrayText /t REG_SZ /d "0 200 0" /f wine reg add "HKCU\Control Panel\Colors" /v Menu /t REG_SZ /d "38 43 51" /f wine reg add "HKCU\Control Panel\Colors" /v MenuBar /t REG_SZ /d "38 43 51" /f wine reg add "HKCU\Control Panel\Colors" /v MenuText /t REG_SZ /d "220 220 220" /f wine reg add "HKCU\Control Panel\Colors" /v Hilight /t REG_SZ /d "143 134 184" /f wine notepad The green GrayText is ignored while the other four keys are honored: the white embossed copy glares on the dark menu (0x808080 + 0xFFFFFF on 0x262B33), and a highlighted grayed item is barely readable on the mid-luminance selection color (0x808080 on 0x8F86B8) — bottom row of the attached screenshots. High contrast schemes, which rely on GrayText for readable disabled text, are affected the same way. Analysis: in dlls/win32u/menu.c, draw_menu_item() selects get_sys_color(COLOR_GRAYTEXT) for grayed items in its "Setup colors" block (lines 2439 and 2448 in wine-11.16), but the text drawing code below overrides it with hardcoded literals: RGB(0x80,0x80,0x80) at lines 2700 and 2728 (main text and shortcut column), and RGB(0xff,0xff,0xff) for the embossed pass at lines 2696 and 2724. Using get_sys_color(COLOR_GRAYTEXT) (already computed by the function) instead of the gray literal, and get_sys_color(COLOR_3DHILIGHT) for the embossed pass, would keep the default rendering identical (both system colors default to the current literals) while honoring custom schemes. Tested on wine-11.16 (Arch Linux package, x86_64, unmodified); the code is identical on current git master. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 58698] New: Application goes into an infinite loop under new wow64 but works okay under old wow64
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=58698 Bug ID: 58698 Summary: Application goes into an infinite loop under new wow64 but works okay under old wow64 Product: Wine Version: 10.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: dkk089(a)gmail.com Distribution: --- Created attachment 79297 --> http://bugs.winehq.org/attachment.cgi?id=79297 WINEDEBUG=+virtual under "new wow64" Application goes into an infinite loop under new wow64 but works okay under old wow64 I have an application that enters an infinite loop under "new wow64" but works okay with "old wow64". Running under actual 64-bit Windows is okay too. The problem seems to be caused by application logic which calls VirtualAlloc() repeatedly in order to (presumably) find out the maximum available amount of memory that the application is able to allocate. The first hint that this might be somehow related to memory were the error messages reported when running under "old wow64" : 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x74010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 74000000 Running the application with WINEDEBUG=+virtual showed the NtAllocateVirtualMemory calls that are made by the application, starting with a size of 0x7fffffff, exploring a number of different sizes, and then eventually settling on 0x701f0000 : 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 7fffffff 2000 00000004 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x80010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 80000000 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 3fffffff 2000 00000004 01a0:trace:virtual:map_view got mem in reserved area 0x11050000-0x51050000 01a0:trace:virtual:dump_view View: 0x11050000 - 0x5104ffff (valloc) 01a0:trace:virtual:dump_view 0x11050000 - 0x5104ffff --rw- 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff 0x11050000 00000000 8000 -- snip : successful calls after that with sizes 0x5fffffff , 0x6fffffff -- 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 77ffffff 2000 00000004 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x78010000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 78000000 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 -- snip : goes on to try sizes starting with 0x70 ... -- 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 701f0001 2000 00000004 01a0:err:virtual:map_view anon mmap error Cannot allocate memory, size 0x70201000, unix_prot 0 01a0:err:virtual:allocate_virtual_memory out of memory for allocation, base (nil) size 701f1000 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 01a0:trace:virtual:NtAllocateVirtualMemory 0xffffffff (nil) 701f0000 2000 00000004 01a0:trace:virtual:map_view got mem with anon mmap 0x80000000-0xf01f0000 01a0:trace:virtual:dump_view View: 0x80000000 - 0xf01effff (valloc) 01a0:trace:virtual:dump_view 0x80000000 - 0xf01effff --rw- 01a0:trace:virtual:NtFreeVirtualMemory 0xffffffff (nil) 00000000 8000 The application makes the same calls under "new wow64", but since none of those calls ever fail, it seems to get confused, reaches size=0, and then gets stuck on that size : 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 7fffffff 2000 00000004 016c:trace:virtual:map_view got mem with map_free_area 0x7fff0000-0xffff0000 016c:trace:virtual:dump_view View: 0x7fff0000 - 0xfffeffff (valloc) 016c:trace:virtual:dump_view 0x7fff0000 - 0xfffeffff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x7fff0000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 3fffffff 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x11050000-0x51050000 016c:trace:virtual:dump_view View: 0x11050000 - 0x5104ffff (valloc) 016c:trace:virtual:dump_view 0x11050000 - 0x5104ffff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x11050000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 1fffffff 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x11050000-0x31050000 016c:trace:virtual:dump_view View: 0x11050000 - 0x3104ffff (valloc) 016c:trace:virtual:dump_view 0x11050000 - 0x3104ffff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x11050000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 0fffffff 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x11050000-0x21050000 016c:trace:virtual:dump_view View: 0x11050000 - 0x2104ffff (valloc) 016c:trace:virtual:dump_view 0x11050000 - 0x2104ffff --rw- -- snip : repeated calls with size right-shifted by 1 -- 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 0000000f 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000007 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000003 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000001 2000 00000004 016c:trace:virtual:map_view got mem in reserved area 0x3750000-0x3751000 016c:trace:virtual:dump_view View: 0x3750000 - 0x3750fff (valloc) 016c:trace:virtual:dump_view 0x3750000 - 0x3750fff --rw- 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff 0x3750000 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 016c:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00000000 2000 00000004 016c:trace:virtual:NtFreeVirtualMemory 0xffffffffffffffff (nil) 00000000 8000 It then loops on the call with size=0 indefinitely and keeps running until I kill the wineserver. Unfortunately, this is a proprietary legacy application so I can't share it, however I'll be more than glad to accept pointers on which debug channels to activate, any other further debugging steps, or changes to the code that might fix this. Thanks in advance. -- 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 60213] New: wineserver crashes with SIGSEGV (memset in free_shared_object) after an application allocates 32744 user handles; client aborts with "alloc_user_handle: Assertion `index < MAX_USER_HANDLES'"
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60213 Bug ID: 60213 Summary: wineserver crashes with SIGSEGV (memset in free_shared_object) after an application allocates 32744 user handles; client aborts with "alloc_user_handle: Assertion `index < MAX_USER_HANDLES'" Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: tnatkinn(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81915 --> http://bugs.winehq.org/attachment.cgi?id=81915 Repro code When a process exhausts the shared user handle table (MAX_USER_HANDLES = 32744 entries — which EmEditor 20.6.1 does within a day because of bug #60212), the next handle allocation does not fail gracefully: the client process aborts with ../wine/dlls/win32u/window.c:98: alloc_user_handle: Assertion `index < MAX_USER_HANDLES' failed. and while wineserver cleans up that process it crashes: kernel: wineserver[406414]: segfault at ... in libc.so.6 (memset, rsi=0xfe = mark_block_noaccess fill) #1 wineserver free_shared_object() ... (full coredumpctl output attached) Cause: server/user.c alloc_user_entry() never checks nb_handles against MAX_USER_HANDLES. When the table is full it hands out index 32744, writing a user_entry past the end of user_entries[] into the session shared objects and past the end of the static server_objects[] array. The client asserts on the returned index, and the shared object headers are corrupted (size field 0xfefefefefefefefe), so free_shared_object() later memset()s far past the mapping. Test case: cursorleak.c from bug #60212, "wine cursorleak.exe 40000" (leaks >32744 cursor handles) — terminal output and coredumpctl info attached. Any application leaking that many USER handles triggers it. Expected: the allocation fails (like Windows' USER handle quota) and the client API returns an error; the server must not corrupt memory. Tested with wine-11.15 (distro package) and wine-11.16 built from git, clean 64-bit ~/.wine, no DLL overrides, CachyOS Linux (Arch-based) x86-64. (Also seen with CrossOver 26.3, same code.) Patch attached (server: fail the allocation with STATUS_NO_MEMORY when the table is full; tested on wine-11.16: LoadCursorW fails with ERROR_NOT_ENOUGH_MEMORY after 32717 calls, wineserver keeps running). Attachments (bundled in bug2-attachments.tar.gz): coredumpctl-wineserver.txt (two cores: original EmEditor crash, and the test case on wine-11.15) cursorleak-40000-output.txt (terminal output) cursorleak.c, test.rc, test.cur 0001-server-Fail-user-handle-allocation-...patch -- 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 60212] New: EmEditor 20.6.1: crashes after about a day of use with "alloc_user_handle: Assertion `index < MAX_USER_HANDLES' failed" (leaks a USER handle on every mouse move)
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60212 Bug ID: 60212 Summary: EmEditor 20.6.1: crashes after about a day of use with "alloc_user_handle: Assertion `index < MAX_USER_HANDLES' failed" (leaks a USER handle on every mouse move) Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)list.winehq.org Reporter: tnatkinn(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81914 --> http://bugs.winehq.org/attachment.cgi?id=81914 Bug repro code EmEditor 20.6.1 (64-bit text editor) aborts after a day or so of normal editing; the terminal shows ../wine/dlls/win32u/window.c:98: alloc_user_handle: Assertion `index < MAX_USER_HANDLES' failed. and wineserver crashes right afterwards (filed separately as bug #XXXXX, it is a different problem). Cause: EmEditor loads its resource DLL emedres.dll with LOAD_LIBRARY_AS_IMAGE_RESOURCE and calls LoadCursorW(hResDll, id) + SetCursor() on every WM_SETCURSOR. In Wine each of these LoadCursorW calls returns a *new* cursor handle (on Windows LoadCursor returns the same shared handle every time and the app correctly never destroys it), so the process leaks one USER handle per mouse move (~150/s while the mouse moves) until the session's user handle table is full. Why: dlls/user32/cursoricon.c CURSORICON_Load() only consults the shared cursor/icon cache when LdrGetDllFullName(hInstance) succeeds. It fails for handles of modules loaded with LOAD_LIBRARY_AS_DATAFILE / LOAD_LIBRARY_AS_IMAGE_RESOURCE (low bits set, not a loader module), so the lookup is skipped and a new cursor object is created every time (the module name is also missing when the object is recorded, so it can never be found later). Standalone test case attached (cursorleak.c + test.rc + test.cur, build with mingw-w64; source only). It loads a copy of itself with each LOAD_LIBRARY_AS_* flag and calls LoadCursorW 1000 times: normal module : 0 of 1000 calls returned a NEW handle (ok) LOAD_LIBRARY_AS_IMAGE_RESOURCE: 1000 of 1000 calls returned a NEW handle (LEAK) LOAD_LIBRARY_AS_DATAFILE : 1000 of 1000 calls returned a NEW handle (LEAK) With "cursorleak.exe 40000" the assert above is hit (and wineserver crashes, see the other bug). Tested with wine-11.15 (distro package) and wine-11.16 built from git, clean 64-bit ~/.wine, no DLL overrides, CachyOS Linux (Arch-based) x86-64, KDE Plasma/Wayland (XWayland). First noticed under CrossOver 26.3 (same Wine code, same behaviour). A patch (user32 fix + conformance test in user32/tests/cursoricon.c, tested on wine-11.16: cursoricon 0 failures, test case 0 leaked handles) is attached. Download: EmEditor 20.6.1 64-bit, https://www.emeditor.com/download/older-versions/ emeditor-professional-20-6-1-64bit.msi sha1 c970f1414f5d2896fc839f688bf8a67f14de210b (runs as free/trial without a license). Reproduce: open any file, move the mouse over the text for a while; watch the USER handle count (see attached monitor_handles.py which reads the wineserver session shared memory) or just wait for the assert. Attachments (text/plain unless noted; bundled in bug1-attachments.tar.gz): cursorleak.c, test.rc, test.cur (test case source) — keyword testcase cursorleak-output.txt (terminal output of the test case, wine-11.15 / 11.16) emeditor-terminal-output.txt (EmEditor +relay,+cursor excerpt showing the leak, one WM_SETCURSOR) 0001-user32-tests-...patch, 0002-user32-Share-cursors-...patch — keyword patch monitor_handles.py (optional helper to watch USER handle counts) -- 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 56990] New: Implement "getdfDIJoystick"
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=56990 Bug ID: 56990 Summary: Implement "getdfDIJoystick" Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: EpicTux123(a)proton.me Distribution: --- Created attachment 76823 --> https://bugs.winehq.org/attachment.cgi?id=76823 "getdfDIJoystick" message Hello. I am using Wine from GloriousEggroll's Proton version 9.10. Playing L.A. Noire (Rockstar Games game) with V-Patch modification. When the game launches, a message box with "getdfDIJoystick" appears. Clicking OK makes the game launch as normal. I don't know what this is for, but I believe a dummy "getdfDIJoystick" could be implemented so it "passes" the check. This only happens via Wine/Proton, and does not happen in native Windows (according to other users). I don't have a Windows machine to test. I did not test this with "pure" Wine, but I believe this is a Wine issue rather than a Proton issue. I'll leave a screenshot attached. INFORMATION/LINKS OS: Fedora Linux 40 Game: https://store.steampowered.com/app/110800/LA_Noire/ Proton used: https://github.com/GloriousEggroll/proton-ge-custom/releases/tag/GE-Proton9… V-Patch modification: https://github.com/VaanaCZ/LANVP ADDITIONAL CONTEXT The author of V-Patch is currently remaking the mod to use Ultimate ASI Loader (see https://github.com/VaanaCZ/LANVP/issues/26) so the problem of "getdfDIJoystick" should go away, but I think it would be nice to implement this in Wine anyway (even if it is a dummy check). WINEDLLOVERRIDES="dinput8=n,b" is necessary to make the patch work. Thanks for your attention. -- 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 10

[Bug 60190] New: rsaenh: Wrong private exponent for RSA keys with public exponent 1
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60190 Bug ID: 60190 Summary: rsaenh: Wrong private exponent for RSA keys with public exponent 1 Product: Wine Version: 11.15 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: rsaenh Assignee: wine-bugs(a)list.winehq.org Reporter: Urias.Uhle(a)web.de Target Milestone: --- Distribution: --- Autodesk Fusion 360 renders a black 3D canvas since Wine 11.11 while its Qt interface works. The cause is not graphics related. This supersedes bug 60010, which I filed against win32u before the root cause was known. Fusion imports a 512 bit RSA private key whose public exponent is 1 through CryptImportKey. Before 11.11 libtomcrypt handled that key. Since d22453b rsaenh uses SymCrypt, which rejected it; 0cb249ce (!11182) made the import succeed again. The import succeeds now, but the derived private key is wrong. SymCryptRsakeyCalculatePrivateFields() in libs/symcrypt/lib/rsakey.c computes the private exponent with SymCryptIntExtendedGcd(), which derives the inverse as -((B1*Src1 - Gcd)/Src2) mod Src1. That does not hold for Src2 == 1, so the private exponent and both CRT exponents come out wrong. The public operation is correct, the private one is not, so Fusion's 3D subsystem never initialises. With e == 1 both RSA operations are the identity, m^1 mod n == m, so the private exponent has to be 1 as well. Setting piPrivExps[i] to 1 directly when au64PubExp[i] == 1, and skipping the gcd path, makes d, dp and dq come out as 1 and both operations become the identity again. I verified that on 11.14 and on current master, and ordinary RSA keys stay byte identical. test_pubexp() in dlls/rsaenh/tests/rsaenh.c only imports the key, which is why this was not caught. An encrypt and decrypt round trip with the same blob shows it. I am not opening a merge request, because I worked this out with LLM assistance and the WineHQ contributor policies ask contributors to refrain from that. -- 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 9

[Bug 56887] New: Total Commander ftps connection (TLS1.2)
by WineHQ Bugzilla Aug. 21, 2026

Aug. 21, 2026

https://bugs.winehq.org/show_bug.cgi?id=56887 Bug ID: 56887 Summary: Total Commander ftps connection (TLS1.2) Product: Wine Version: 9.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)winehq.org Reporter: daniel.becker(a)quippy.de Distribution: --- Created attachment 76704 --> https://bugs.winehq.org/attachment.cgi?id=76704 The stacktrace of wine that came with that error This used to work - however, I do not know with what version of wine. It stopped working a while ago. Tried to switch Operating System (XP, Win10, ...) but without success. This works in "real" windows (WinXP, Win7, Win10, Win11). See the stack trace for more information. This happens when I try to open a FTPS connection that is secured. FTP without encryption still works. I haven't tried SFTP, if that fails as well, as I do not have an FTP server supporting this. Total Commander is run in 64bit environment. -- 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 12

[Bug 60125] New: Yabridge overlaping windows on some WM produce dead zone for input (regression 11.13)
by WineHQ Bugzilla Aug. 21, 2026

Aug. 21, 2026

http://bugs.winehq.org/show_bug.cgi?id=60125 Bug ID: 60125 Summary: Yabridge overlaping windows on some WM produce dead zone for input (regression 11.13) Product: Wine Version: 11.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: gogokily(a)gmail.com Target Milestone: --- Distribution: --- Had some trouble for a longer time and identified the bad commit with bisect: ff4a5a3b917d44e3a0ca3bf9fec4ad95086d85da is the first 'bad' commit commit ff4a5a3b917d44e3a0ca3bf9fec4ad95086d85da Author: Rémi Bernon <rbernon(a)codeweavers.com> Date: Tue Jun 30 08:20:45 2026 +0200 winex11: Remove now unnecessary update_window_zorder call. dlls/winex11.drv/mouse.c | 27 +++++---------------------- 1 file changed, 5 insertions(+), 22 deletions(-) So what happens is when two windows overlap in x11/wayland space you cannot raise the bottom one any more and that overlapping zone becomes input dead zone. For reproduction: 1. Install xwayland-satelite 2. Install yabridge 3. Daw of choice (Reaper on my end) 4. Open two SAME plugins (what matters is that one covers buttons/knobs of another) 5. Try to click on knobs, buttons on first plugin 6. Mouse input does not work at all Image for context: https://imgur.com/XNABxKF I found this issue while writing my own wm and noticed that native linux vst3 plugins act normal but yabridge plugins I have that deadzone for input. After I tried xwayland-satellite and saw that it has same issue. In both my and yabridge case we create all windows at 0,0 so multiple windows will overlap. I XRaise the window in on-enter event and that works fine for native plugins but yabridge does not give mouse input (window stack is raised I can confirm that via xwininfo but mouse suffers from dead zone. This issue however does not happen on standard xwayland (hyprland etc). So not sure whats exactly is the problem. Anyway this commit is the cause of described issue. 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 15

[Bug 49792] New: pfx import does not works
by WineHQ Bugzilla Aug. 21, 2026

Aug. 21, 2026

https://bugs.winehq.org/show_bug.cgi?id=49792 Bug ID: 49792 Summary: pfx import does not works Product: Wine Version: 5.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)winehq.org Reporter: eugene_s_s2(a)mail.ru Distribution: --- Created attachment 68106 --> https://bugs.winehq.org/attachment.cgi?id=68106 logs with WINEDEBUG=+crypt I have Debian 9 and Wine 5.0.2 (also tried 5.16) I run "wine control" to add new certificate from pfx-file (in attachment, it's not secret, password is 1) But when i try to add pfx from certificate import wizard i receive message, that file format is not supported (i do not know exact english error, because i receive it in russian). I tried to make pfx by openssl 1.0.1, also by microsoft windows built-in export-to- -pfx wizard. Also tried making pem-files, but got succesfull import only for public part of certificate. Also I tried making certificate request by windows CA and by Openssl, but still no luck. Also tried importpfx.exe -f certificate.p12 - p "1" -t USER -s MY. (With MACHINE parameter also) The output says that import suceeded. But i did not see any certificates in wine control. Importing of cer-files works. What am i doing wrong? All that i know is that from wine 5.0 (as in release notes) importing of pfx blobs is supported. -- 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 17

[Bug 59757] New: SteelSeries GG 110.0 crashes on startup in .NET System.Security.Cryptography.X509Certificates.StorePal.Export
by WineHQ Bugzilla Aug. 21, 2026

Aug. 21, 2026

http://bugs.winehq.org/show_bug.cgi?id=59757 Bug ID: 59757 Summary: SteelSeries GG 110.0 crashes on startup in .NET System.Security.Cryptography.X509Certificates.StorePal .Export Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)list.winehq.org Reporter: toadking(a)toadking.com Distribution: --- Created attachment 80951 --> http://bugs.winehq.org/attachment.cgi?id=80951 WINEDEBUG=trace+crypt trace Follow-up to bug 59746. A trace is attached. The crash seems to be inside crypt32.PFXExportCertStore/PFXExportCertStoreEx. -- 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