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

[Bug 60216] notepad (and every application): grayed menu items are drawn in a fixed gray 0x808080, ignoring the GrayText system color

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60216 --- Comment #1 from Loïc <loic.simond(a)protonmail.com> --- Created attachment 81917 --> http://bugs.winehq.org/attachment.cgi?id=81917 Terminal output of 'wine --version' and 'wine notepad' (clean prefix) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[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

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.

Aug. 22, 2026

[Bug 60215] esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60215 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #1 from Stian Low <wineryyyyy(a)gmail.com> --- Thanks for reporting and indicating AI assisted which helps devs address bugs more contextually. I'll take a closer look at esync because I'm less familiar but recently interested in diving deeper. In the meantime attaching backtrace and logs may be helpful for comparison with other reports that may be related. If default logs seem less useful then `WINEDEBUG=warn+all,err+all` may include extra hints. Thief 3 bug recently came on my radar which seems related to new WoW64 builds: - https://bugs.winehq.org/show_bug.cgi?id=59897 It may be worth testing old shared wow64 build if you're able. Maybe Thief 1 & 3 share enough code mechs to reproduce bugs across one another. Maybe its related to some other odd subtle bugs between old shared vs new wow64 that I've been collecting. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60214] bcrypt: BCryptExportKey/BCryptImportKeyPair lack BCRYPT_OPAQUE_KEY_BLOB support for asymmetric keys

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60214 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #3 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Erik Hill from comment #1) > Correction to this report. I over-attributed the cause. Might analysis/diagnostic come from AI? If so please state when AI is used for reports to help devs account for contexts where hallucinations may be likely. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60215] New: esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60215 Bug ID: 60215 Summary: esync: eventfd() exhaustion (EMFILE) on sync object creation not handled gracefully, propagates as guest null-pointer crash Product: Wine Version: unspecified Hardware: arm OS: Android Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: aydar.kamaltdinov(a)gmail.com Target Milestone: --- Note: this report was drafted/formatted with AI assistance (for structuring the technical writeup), but all testing, reproduction, log capture, and root-causing (attaching to the process's stderr, extracting the fault address/backtrace, confirming the WINEESYNC=0 workaround across multiple real runs) was done by me personally on physical hardware. Happy to answer follow-up questions or provide additional logs/raw captures directly. Possibly the same root cause as bug 58059 (eventfd leak in wineserver on thread create/destroy with WINEESYNC=1, UNCONFIRMED since 2025-04-04) — filing separately since I have a different real-world reproduction with more diagnostic detail (exact crash address + confirmed workaround), in case it helps unstick triage either way. Feel free to merge/dup if appropriate. ## Summary When WINEESYNC=1 is active and a running application leaks Windows synchronization objects (Events/Semaphores/etc.) faster than it releases them, esync's eventfd()-per-object model eventually exhausts the process's RLIMIT_NOFILE. At that point eventfd() creation fails with EMFILE, but the failure does not appear to be surfaced/handled in a way that prevents the guest application from later dereferencing an invalid/null handle — resulting in a hard crash (EXCEPTION_ACCESS_VIOLATION) instead of a recoverable API-level failure. This is architecture-independent in principle, but is far easier to trigger on platforms with a low default RLIMIT_NOFILE (e.g. Android, ~32768 in my case) than on typical desktop Linux, where the same underlying handle leak in the application would likely go unnoticed for a very long time (or indefinitely, given Windows' much larger practical handle-table ceiling). ## Observed on - A wine-staging-derived ARM64EC/WOW64 fork (used by several Android "run Windows games" projects — built from a "wine-proton-ec" tree, Proton 10.0 base), running on ARM64 Android via FEX-Emu as the WOW64 CPU backend. - I was not able to test on a vanilla x86-64 desktop Wine+wine-staging build to confirm the exact same code path applies verbatim, but the esync eventfd-creation code itself (dlls/ntdll/esync.c) appears architecture-independent, so I believe this is worth tracking upstream regardless of the specific fork. ## Reproduction case Game: Thief (2014), Steam AppID 239160, `Shipping-ThiefGame.exe`. Crashes deterministically (100% reproducible, identical fault address and full backtrace across repeated runs) during active gameplay with `WINEESYNC=1`. Captured via `WINEDEBUG=+seh,+exception`: code=c0000005 (EXCEPTION_ACCESS_VIOLATION) addr=000000014011F9D9 rip=000000014011f9d9 rcx=0000000000000000 ... Shipping-ThiefGame.exe+0x11F9D6: movq (%rbx), %rcx ; load object pointer Shipping-ThiefGame.exe+0x11F9D9: movq (%rcx), %rax <-- FAULT: rcx == 0 Shipping-ThiefGame.exe+0x11F9DC: callq *0x18(%rax) ; virtual call through vtable One capture shows this immediately preceding the crash: eventfd: Too many open files Setting `WINEESYNC=0` for this title eliminates the crash entirely (23+ minutes of gameplay with no crash, vs. a deterministic crash within minutes with esync on). ## Ask Is there existing handling in esync's object-creation path (CreateEvent/CreateSemaphore/etc. server calls) for eventfd() returning EMFILE? If not, would a graceful fallback (e.g. falling back to the non-esync/server-based wait object implementation for that single object, or returning a proper NT status the app is expected to check) be feasible, rather than leaving a handle in a state that leads to guest-side null dereferences? Happy to provide the full captured trace/disassembly if useful. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60214] bcrypt: BCryptExportKey/BCryptImportKeyPair lack BCRYPT_OPAQUE_KEY_BLOB support for asymmetric keys

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60214 --- Comment #2 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Erik Hill from comment #1) > I have retitled this to describe the verifiable API gap rather than assert a > Steam root cause. Apologies for the noise; the opaque asymmetric > export/import is still a genuine gap worth closing on its own merits. That doesn't seem right. BCRYPT_OPAQUE_KEY_BLOB is documented as a symmetric, not asymmetric key format. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60214] bcrypt: BCryptExportKey/BCryptImportKeyPair lack BCRYPT_OPAQUE_KEY_BLOB support for asymmetric keys

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60214 Erik Hill <erik.hill0987(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|bcrypt: |bcrypt: |BCryptExportKey/BCryptImpor |BCryptExportKey/BCryptImpor |tKeyPair do not support |tKeyPair lack |BCRYPT_OPAQUE_KEY_BLOB for |BCRYPT_OPAQUE_KEY_BLOB |asymmetric keys, breaking |support for asymmetric keys |modern Steam login | --- Comment #1 from Erik Hill <erik.hill0987(a)gmail.com> --- Correction to this report. I over-attributed the cause. The OpaqueKeyBlob export gap itself is real (the fixme is definitive, and opaque asymmetric export/import is genuinely unimplemented). But I did NOT prove this gap is what breaks modern Steam login, and I should not have framed it that way. Gcenx, who maintains the macOS Wine packages, has the CURRENT Steam client working with a rendering fix alone: a small steamwebhelper wrapper forcing --in-process-gpu so DXMT's Metal renderer handles the in-process swapchain. That suggests the rendering path, not this crypto gap, may be the actual login blocker. My attempt to isolate which wall gates login was inconclusive: with DXMT + the in-process-gpu wrapper on stock 11.15, rendering failed a different way (GPU context lost) before login was ever attempted, so the crypto path never ran. I have retitled this to describe the verifiable API gap rather than assert a Steam root cause. Apologies for the noise; the opaque asymmetric export/import is still a genuine gap worth closing on its own merits. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

Aug. 22, 2026

[Bug 60214] New: bcrypt: BCryptExportKey/BCryptImportKeyPair do not support BCRYPT_OPAQUE_KEY_BLOB for asymmetric keys, breaking modern Steam login

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60214 Bug ID: 60214 Summary: bcrypt: BCryptExportKey/BCryptImportKeyPair do not support BCRYPT_OPAQUE_KEY_BLOB for asymmetric keys, breaking modern Steam login Product: Wine Version: 11.15 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: bcrypt Assignee: wine-bugs(a)list.winehq.org Reporter: erik.hill0987(a)gmail.com Target Milestone: --- The modern Steam client's device-key login exports an asymmetric key with BCryptExportKey(key, NULL, BCRYPT_OPAQUE_KEY_BLOB, ...). Wine's export_asymmetric_key() in dlls/bcrypt/bcrypt_main.c has no branch for BCRYPT_OPAQUE_KEY_BLOB and returns STATUS_NOT_IMPLEMENTED: fixme:bcrypt:export_asymmetric_key unsupported blob type L"OpaqueKeyBlob" fixme:ncrypt:map_ntstatus unhandled status 0xc0000002 Because this fails locally, every Steam auth session dies before any network traffic (QR generation included). In the client's CEF log this surfaces as: Login: Failed to poll auth session. Result 2. Transport Error: 2 while the client's own CM WebSocket connects normally, which makes the failure look like a networking bug when it is not. REGRESSION BCRYPT_OPAQUE_KEY_BLOB was supported by the older gnutls-backed bcrypt (originally added for Titanfall 2, ~2018). The post-11.0 rewrite to the PE/SymCrypt bcrypt did not carry opaque asymmetric export/import forward. Still absent in master as of 2026-08. HOW REPRODUCIBLE: always (Steam login on Wine, macOS or Linux, wine > 11.0). EVIDENCE IT IS THE CAUSE (not merely correlated) Differential test across three stacks on macOS/M4, 2026-08-22: signal (cef/wine logs) | 11.15 fails | 11.6 works | CrossOver 26 (=wine 11.0) works export_asymmetric_key ... OpaqueKeyBlob fixme | present | absent | absent Failed to poll auth session | continuous | absent | absent reaches QR / logs on | no | yes | yes Transplanting the wine-11.0 bcrypt.dll/ncrypt.dll PE pair plus bcrypt.so into an 11.15 prefix removed the fixme and Steam progressed to QR generation. CrossOver's bcrypt/ncrypt are byte-identical to upstream wine-11.0 (verified against the published CrossOver 26 LGPL source tarball); CrossOver patches bcrypt/ncrypt nowhere. So the difference is purely the dropped opaque support, nothing vendor-proprietary. PROPOSED FIX A patch is available that adds BCRYPT_OPAQUE_KEY_BLOB export/import for asymmetric keys. Opaque blobs are implementation-private by contract (importable only into the same provider), so it serializes the fullest standard blob for the key with an 8-byte tag header and reverses it on import, reusing the existing per-alg helpers. Status of the patch: PROPOSED. The approach is proven by the binary transplant above, but this specific reimplementation still needs a wine build plus the dlls/bcrypt test suite before being sent as a formal patch. It will be attached once built and tested. Draft, patch, and a suggested round-trip test: https://github.com/egnaro9/steam-on-wine-macos/tree/main/wine-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.

Aug. 22, 2026

[Bug 58698] Application goes into an infinite loop under new wow64 but works okay under old wow64

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=58698 --- Comment #8 from Daniel Kamil Kozar <dkk089(a)gmail.com> --- Confirming as fixed. Many 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.

Aug. 22, 2026

[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

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.

Aug. 22, 2026