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

[Bug 59937] New: fixme:wlanapi:WlanEnumInterfaces - Unable to find wifi network device
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59937 Bug ID: 59937 Summary: fixme:wlanapi:WlanEnumInterfaces - Unable to find wifi network device Product: Wine-staging Version: 11.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: sexy_b14(a)hotmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Hi guys When using Creality Scan 4.2.2, the software is unable to see the wifi network and device. Can connect to the device wifiAP normaly with NM. Also have tried disconnecting all interface and solely trying the wifi connection. Application looks to be-built with unity and electron. When refreshing wifi in the Creality Scan the following error apears. 02f0:fixme:wlanapi:WlanEnumInterfaces (0000000000000001, 0000000000000000, 000000006AAAF748) semi-stub I have attached output log Thanks heaps. -- 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 59775] New: German umlauts won't be handled correctly by typing
by WineHQ Bugzilla Aug. 23, 2026

Aug. 23, 2026

http://bugs.winehq.org/show_bug.cgi?id=59775 Bug ID: 59775 Summary: German umlauts won't be handled correctly by typing Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: andreas.franz(a)arcor.de Distribution: --- German umlauts (ö, ä, ü) make strange things, if typed on keyboard: - .NET keycode-event don't produce any keycode in an e. g. textbox. But letter is shown correctly in same textbox. Pressing CTRL+<umlaut> produce letter AND keycode. - Pressing "ö" crashes MailStore-Client with "arithmetic" error. Works fine with 11.0 stable. Works fine if Ctrl+ö is pressed, too. I've noticed this behavior since wine 11.8. Copy&Paste works fine in all tested applications. So I think it's something wrong with keyboard-press-eventhandling? Any ideas? regards, Andy -- 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 53

[Bug 60222] New: dxgi_output_GetDisplayModeList is a partial stub: applications that require a mode list never create a swapchain
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=60222 Bug ID: 60222 Summary: dxgi_output_GetDisplayModeList is a partial stub: applications that require a mode list never create a swapchain Product: Wine Version: 11.0 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: hedgar2017(a)gmail.com Target Milestone: --- Created attachment 81923 --> http://bugs.winehq.org/attachment.cgi?id=81923 +dxgi trace excerpt, game process, full call sequence `dxgi_output_GetDisplayModeList` is a partial stub. Two application-visible consequences follow, one fatal and one an accessibility hazard. ## 1. No swapchain is ever created Assassin's Creed Liberation Remastered (`ACLiberation.exe`, x86_64, D3D11) reaches its main menu — audio plays — and renders nothing: a black fullscreen window that accepts no input, ~35% of one core, 1.6 GB resident, 51 threads, GPU utilisation 0%. The attached `+dxgi` excerpt is the game process's complete call sequence: create factory, `EnumAdapters1`, `DXGID3D10CreateDevice` (feature levels 11_1 down to 9_1, device created), `EnumOutputs`, then `dxgi_output_GetDisplayModeList` — twice per output, once with `modes NULL` for the count and once to fill — hitting the stub every time, across three outputs, followed by output, adapter, device and factory all released to refcount 0. **`CreateSwapChain` is never called**, and no further DXGI activity occurs in the minutes the process keeps running. The application then writes `1280x720 / RefreshRate=0` into its own configuration — a fallback, not a detection. **Control:** `ACIII.exe` (Assassin's Creed III Remastered), a different executable in the same directory launched the same way, runs correctly at 3440x1440. It tolerates the stub; this title requires a mode list and has no fallback path. ## 2. Applications are handed modes the display does not have Assassin's Creed Liberation HD, a different 32-bit D3D11 build of the same game, does run — and its in-game resolution list offers `2560x1440@60` on a display whose only 2560x1440 mode is 240 Hz, verified against the platform's own mode enumeration including hidden and duplicate modes, 170 modes total. Selecting that entry makes the application retry the mode change every frame, producing full-screen white strobing at roughly 30–60 Hz. The returned list is not empty, it is fictional, and applications cannot detect that they have been misled. ## Environment Observed under CrossOver 26.3 (`cxoffice-26.3.0rc2`, built 2026-07-15) on macOS 26.6.2, Apple M2 Max. I have no upstream Wine build on this hardware to retest against, so the behavioural observations come from that Wine-derived build; the stub itself is in Wine's `dxgi` and is verifiable from source. Happy to test a patch and report back. -- 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 49939] New: Clive Barker's Jericho Demo claims not enough room on C: (NtMapViewOfSection returns STATUS_NOMEMORY)
by WineHQ Bugzilla Aug. 22, 2026

Aug. 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=49939 Bug ID: 49939 Summary: Clive Barker's Jericho Demo claims not enough room on C: (NtMapViewOfSection returns STATUS_NOMEMORY) Product: Wine Version: 5.18 Hardware: x86-64 URL: https://www.gamepressure.com/download.asp?ID=17454 OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: gijsvrm(a)gmail.com Blocks: 34747 Distribution: ArchLinux Created attachment 68320 --> https://bugs.winehq.org/attachment.cgi?id=68320 logs I wanted to retest bug 34747, but the demo won't install. The last test in that bug is from the 1.9 era and seems to imply that the demo used to install. I also checked on Windows 10 and it installs fine there. For multiple reasons bisecting this might be challenging. Attached is an archive containing +relay,+virtual logs from both vanilla wine and wine-staging (The ForceBottomUpAlloc patchset changes/adds tracing). I tried in both a 64bit and 32bit prefix, same result. Logs are from a 32bit 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.

2 15

[Bug 34747] New: Clive Barker's Jericho Demo intro movies are grayscale (without native d3dcompiler_43 or d3dx9_36)
by wine-bugs＠winehq.org Aug. 22, 2026

Aug. 22, 2026

http://bugs.winehq.org/show_bug.cgi?id=34747 Bug #: 34747 Summary: Clive Barker's Jericho Demo intro movies are grayscale (without native d3dcompiler_43 or d3dx9_36) Product: Wine Version: 1.7.4 Platform: x86 URL: http://www.gamershell.com/download_21174.shtml OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 AssignedTo: wine-bugs(a)winehq.org ReportedBy: andrey.goosev(a)gmail.com CC: wine-bugs(a)winehq.org Classification: Unclassified Intro movies without native d3dcompiler_43 or d3dx9_36 plays in grayscale effect. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

3 15

[Bug 45229] New: Source insight 4 tool bar is too large when installed in wine.
by wine-bugs＠winehq.org Aug. 22, 2026

Aug. 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=45229 Bug ID: 45229 Summary: Source insight 4 tool bar is too large when installed in wine. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: 15236286238(a)163.com Distribution: --- Created attachment 61458 --> https://bugs.winehq.org/attachment.cgi?id=61458 The tool bar of source insight 4 is too large. For source insight 4, the tool bar is too large to use when installed in all version of wine. But source insight 4 tool bar is normal in windows os. The download link of source insight 4 is bellow: https://www.sourceinsight.com/trial/ The official website of source insight 4 is bellow: https://www.sourceinsight.com/ Source insight 3 is normal in windows os or installed in wine in linux os. -- 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 10

[Bug 46856] New: Exact Audio Copy: Unhandled exception at EACWnd2.264 -> INDEX-RANGE
by wine-bugs＠winehq.org Aug. 22, 2026

Aug. 22, 2026

https://bugs.winehq.org/show_bug.cgi?id=46856 Bug ID: 46856 Summary: Exact Audio Copy: Unhandled exception at EACWnd2.264 -> INDEX-RANGE Product: Wine Version: 4.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: newbie13xd(a)gmail.com Distribution: --- Greetings! Sometimes, not always, when I close a window in Exact Audio Copy (which I hereafter will refer to as EAC) EAC throws an error message to me with the title "Unhandled Exception" and body "at EACWnd2.264 -> INDEX-RANGE. Most recently this occurred after I had finished ripping a CD and pressed OK on the window where it shows you how well the ripping went. This error message appeared very shortly after said window had closed. After closing the error box by clicking "ok", EAC freezes, and moments after closes. EAC was downloaded from here: https://www.netzwelt.de/software-download/38342-exact-audio-copy-eac.html It is what seems to be the only official mirror, looking here: http://www.exactaudiocopy.de/en/index.php/resources/download/ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 16

[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