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

[Bug 60484] New: wine 11.19 dnsapi parsing a large /etc/hosts stalls fresh prefix initialization
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60484 Bug ID: 60484 Summary: wine 11.19 dnsapi parsing a large /etc/hosts stalls fresh prefix initialization Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dnsapi Assignee: wine-bugs(a)list.winehq.org Reporter: xash(a)riseup.net Target Milestone: --- Distribution: --- Created attachment 82331 --> http://bugs.winehq.org/attachment.cgi?id=82331 bash script to repro the issue Steps to reproduce: 1. Run the attached repro-wine-hosts.sh script. It generates two synthetic hosts files, one with two lines and one with 434,612 lines, then starts wineboot -i with a fresh prefix for each. bubblewrap bind-mounts each file as /etc/hosts only for Wine. 2. Compare the two prefixes and the script output after the 30-second timeout. Actual results on my machine: - Both wineboot commands hit the 30-second timeout (exit 124). - With the two-line hosts file, the prefix reaches a 2,226,829-byte system.reg and has a .update-timestamp file before the timeout. - With the 434,612-line hosts file (13,038,334 bytes), the prefix only reaches a 1,212-byte system.reg and has no .update-timestamp file before the timeout. - A separate WINEDEBUG=trace+dnsapi capture using my real 434,612-line hosts file shows wineboot calling DnsQuery_UTF8 for the local computer name, followed by thousands of get_next_host_entry "parsing line" messages. The 20-second capture timed out while those messages were still being emitted. Expected result: The size of /etc/hosts should not prevent a fresh Wine prefix from initializing. The application executable is not needed to reproduce this. Workaround: Starting Wine with a minimal /etc/hosts bind-mounted via bubblewrap lets the prefix initialize. My real hosts file is 12,476,010 bytes and has 434,612 lines. Related source: The 11.19 dnsapi implementation parses /etc/hosts during DNS queries: https://github.com/wine-mirror/wine/blob/wine-11.19/dlls/dnsapi/query.c The raw WINEDEBUG log contains the contents of my actual /etc/hosts and was not attached. Output of the script: ``` wine-11.19 (Staging) Linux 7.2.9-arch1-1 2 34 /tmp/wine-hosts-repro.bikl8L/hosts-small 434612 13038334 /tmp/wine-hosts-repro.bikl8L/hosts-large 434614 13038368 total small: wineboot exit=124 elapsed=30s large: wineboot exit=124 elapsed=30s ``` -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 60466] New: Battlefield 1942 cannot copy secdrv.sys into c:\windows\syswow64\drivers because directory does not exist.
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60466 Bug ID: 60466 Summary: Battlefield 1942 cannot copy secdrv.sys into c:\windows\syswow64\drivers because directory does not exist. Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bernhardu(a)mailbox.org Target Milestone: --- Distribution: --- Inspired by bug 60439 but lacking those install disks, I tried to check if Battlefield 1942 would work and found it fails in a new regular wineprefix. I noticed, inside my 64-bit prefix, the first start of bf1942.exe installs the secdrv.sys service inside HKLM\System\CurrentControlSet\Services\SecDrv, but fails to copy the file into the syswow64\drivers directory. A WINEDEBUG +file shows a: 0134:warn:file:copy_file Unable to open dest L"C:\\windows\\system32\\drivers\\\\SECDRV.SYS" The last version that created the syswow64\drivers was wine-6.4, wine-6.5 started to omit it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 60410] New: MusicBee: System.OutOfMemoryException when trying to load MusicBee on WINE 11.16, 11.17 in WoW64 mode
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60410 Bug ID: 60410 Summary: MusicBee: System.OutOfMemoryException when trying to load MusicBee on WINE 11.16, 11.17 in WoW64 mode Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: bugzilla(a)flaky.blue Target Milestone: --- Distribution: --- Reporting on behalf of users of mb_MPRISBee. Reporting for WINE as a whole rather than just staging, as staging is only used for the plugin and I don't think staging patches affect this. This happens without the plugin installed too, according to their reports. On WINE versions 11.16 and 11.17, MusicBee will refuse to load, spawning a .NET OutOfMemoryException. The user who reported it to the plugin maintainer showed their system monitor not showing they are actually out of memory. The plugin maintainer tested with 11.16 and 11.17 (and I will test 11.18 in a virtual machine later) One user claims that commits a436d114..548a639e broke .NET's memory checks when running in WoW64 mode, and that using legacy 32-bit mode fixes this. Since some distros are packaging WINE without 32-bit support (such as Arch, where WINE with 32-bit capabilities has been relegated to the AUR) and this is a bug that breaks the ability to load MusicBee I bumped it to critical. Relevant issue: https://github.com/UrbanCMC/mb_MPRISBee/issues/10 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 58418] New: InternetQueryOptionW(proxy_username) crashes with NULL buffer but valid size pointer.
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=58418 Bug ID: 58418 Summary: InternetQueryOptionW(proxy_username) crashes with NULL buffer but valid size pointer. Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: bernhardu(a)mailbox.org Distribution: --- InternetQueryOptionW(INTERNET_OPTION_PROXY_USERNAME) crashes with NULL buffer but valid size pointer. Is reproducible with latest git. >From the forum: https://forum.winehq.org/viewtopic.php?t=41123 md5sum: 48d300a85a00a948f5833bdf266226b3 KubiosHRVScientific_4.2.0_setup.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 4

[Bug 60405] New: ssbs-probe (2026-09-29 source snapshot, ARM64): SSBS cleared after RtlRestoreContext
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60405 Bug ID: 60405 Summary: ssbs-probe (2026-09-29 source snapshot, ARM64): SSBS cleared after RtlRestoreContext Product: Wine Version: 11.18 Hardware: arm OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: thomasabbott916(a)hotmail.com Target Milestone: --- Distribution: --- Created attachment 82206 --> http://bugs.winehq.org/attachment.cgi?id=82206 All the evidence logs Summary: ssbs-probe (2026-09-29 source snapshot, ARM64): SSBS cleared after RtlRestoreContext Product: Wine Component: ntdll Version: 11.18 (exact development commit below) Severity: Normal Comments: The attached ssbs-probe.c (September 29, 2026 source snapshot; SHA256 8490049b715e78716f31367343e0cea2c4c391c25dfcf9ab3ad65187b7e7276c) is a native Windows ARM64 console reproducer. It sets PSTATE.SSBS to 1, calls RtlCaptureContext followed by RtlRestoreContext, and observes SSBS=0 afterward. The zero-state control remains zero. This reproduces with unmodified upstream development Wine in a fresh default prefix, without Proton, FEX, DXVK, Windows DLLs, or DLL overrides. Environment: - Wine reports wine-11.18, built from official WineHQ git commit 6880117619afdf62b4ccc40a8c6268c86613131f. This was the repository HEAD at both checkout and final verification on September 29, 2026. - Build: ../wine/configure --disable-tests; make -j8. No source patches; clean git diff. The option skips building Wine's own test suite, not runtime functionality. - CPU/device: Qualcomm Oryon, AYN Odin 3, aarch64; SSBS and DIT instructions are exposed by Linux. - OS: Fedora 44 userspace in a rootless Podman container on Armada 20260927.42a9d14, Linux 7.2.6. The container executes directly on the ARM64 hardware; Wine was launched directly from its build tree. - GCC 16.2.1, Clang 22.1.8, glibc 2.43. Xvfb supplied the display during prefix initialization. Reproduction: 1. On an ARM64 system exposing SSBS read/write instructions, compile attached ssbs-probe.c using LLVM-MinGW: aarch64-w64-mingw32-clang -march=armv8.5-a -O0 ssbs-probe.c -o ssbs-probe.exe 2. Launch it with native ARM64 Wine in a new prefix, leaving DLL overrides and Wine configuration at their defaults. Exact build-tree invocation and environment are attached. 3. Compare the printed before/after SSBS values for requested=1 and requested=0. The raw register value 4096 means SSBS=1; zero means SSBS=0. Actual: requesting 1 produces before=4096 and after=0. Requesting 0 produces before=0 and after=0. Both first-run and repeat invocations exit successfully and reproduce the same result. Expected/proposed behavior: restoring Windows CPU context should not unintentionally discard the host thread's speculative-store-bypass state when the supplied context only contains arithmetic flags. A native Linux control on the same hardware preserves both SSBS values across ordinary signal delivery/return. I do not have native Windows ARM64 hardware, so I have NOT verified Windows behavior or which non-NZCV Cpsr bits Windows permits applications to change; please confirm the intended compatibility semantics. Analysis: In dlls/ntdll/unix/signal_arm64.c, restore_context assigns context->Cpsr to the whole signal-frame PSTATE, and usr2_handler does the same with frame->cpsr. RtlCaptureContext and the syscall dispatcher can supply NZCV without SSBS. Earlier observation of the Proton-shipped handler directly recorded PSTATE changing from 0x60001000 to 0x60000000. The upstream reproduction above does not use that observer or any modified binary. The attachment includes an extended suspend/GetThreadContext/SetThreadContext/resume diagnostic. Supplying the opposite SSBS bit in Cpsr changes the worker's SSBS in either direction. This demonstrates the second write path; it is not presented as proof of the native Windows filtering contract. Attachments: One archive contains both small source reproducers, native Linux control, complete first-run and repeat terminal output, exact build/environment information, source/binary checksums, duplicate-search notes, and a narrowly scoped SSBS-only candidate patch. The candidate was previously validated as equivalent binary edits in Proton Wine; it has NOT been source-built/tested against this upstream build and is offered for review only. It passes git apply --check against the tested source. It preserves incoming SSBS=0 as well as 1 and does not force speculation on. Searches: Bugzilla ALL SSBS and ALL "RtlRestoreContext" ARM64 returned no matches. Known Issues and FF13's AppDB linked bug list were also checked. Details and links are attached. Limitations: native Windows ARM64 comparison, other CPUs, and macOS are untested. Fresh-prefix logs retain all initialization diagnostics, including Mono helper-architecture, Xvfb/DRI3 and container Bluetooth messages. Repeat runs reproduce the state loss after initialization without the Mono helper messages. The probes are native console programs and do not use .NET, graphics acceleration or Bluetooth. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 60383] New: cmd: stack buffer overflow in search_command with a quoted /c command line longer than MAX_PATH
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60383 Bug ID: 60383 Summary: cmd: stack buffer overflow in search_command with a quoted /c command line longer than MAX_PATH Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: cmd Assignee: wine-bugs(a)list.winehq.org Reporter: dnlbtz(a)gmail.com Target Milestone: --- Distribution: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 Build Identifier: Wine 11.18 (built from the release tarball, --enable-archs=i386,x86_64); the affected code is unchanged in master 9d17984f (2026-09-24) cmd.exe crashes with an access violation when it is started as cmd /c "<program> <arguments>" with the whole command line in one pair of quotes, longer than MAX_PATH and containing a backslash. That is the form Python's subprocess produces for shell=True on Windows, so any Python tool that shells out long MSBuild or compiler lines under Wine hits it; I found it with Axivion's axivion_ci.exe running MSBuild, where every call is 330 to 470 characters. The exit code is 3221225477 (0xC0000005). Depending on what the overflow hits, the crash comes before the program runs or after it has finished. In parse_command_line_parameters the quoted line is probed as a single first parameter (search_command with fast=TRUE) to decide whether the quotes are stripped. Since the line contains a backslash, search_command takes the explicit-path branch: WCMD_get_fullpath on the whole line, then wcscpy of the part after the last backslash into stemofsearch[MAX_PATH] and of the rest into sc->path[MAX_PATH], with no length check (the no-path branch has one, WCMD_LINETOOLONG). Any quoted line over 260 characters overflows one of them and smashes wmain's frame. addr2line on the fault address gives wmain's return (wcmdmain.c:5015 in 11.18), the wcscpy variant of the crash points into search_command, and +relay shows the last calls in pop_batch_context. In master 9d17984f the copies are at wcmdmain.c lines 2035, 2058 and 2080. It does not show up from a shell, because wine cmd /c "..." has its argv re-quoted into a different shape. A batch file passes the line as is, hence the reproducer below. Reproducible: Always Steps to Reproduce: 1. Save this as repro.bat (the argument is 300 x followed by \y; any quoted line longer than 260 characters with a backslash in it does the same): @echo off cmd /c "C:\windows\system32\attrib.exe xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\y" echo inner cmd exit code %ERRORLEVEL% 2. wine cmd /c repro.bat The same happens from any Windows program that runs a command through cmd /c "..." with a long line, e.g. Python: subprocess.call('C:\\windows\\system32\\attrib.exe ' + 'x'*300 + '\\y', shell=True) Actual Results: inner cmd exit code -1073741819 The inner cmd.exe dies with an access violation (0xC0000005) every time. attrib is either not run at all, or has run and the crash comes when cmd returns. Expected Results: attrib runs and cmd returns its exit code. On Windows 11 the same repro.bat prints attrib's "Parameter format not correct -" and then "inner cmd exit code 0". Returning RETURN_CODE_CANT_LAUNCH from search_command when either piece does not fit into its buffer makes the probe in parse_command_line_parameters treat the line as "not a program" and fall back to the old quote handling, which is what it already does for any other unknown first word. With that change the reproducer prints "inner cmd exit code 0" and the MSBuild lines from the Python tool run; verified on 11.18 here. Found while running MSBuild-based tools under Wine; the crash is in cmd.exe itself (wcmdmain.c), not in the started program. -- 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 7

[Bug 60253] New: Incoming (1998) crashes after the intro animation
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60253 Bug ID: 60253 Summary: Incoming (1998) crashes after the intro animation Product: Wine Version: 11.3 Hardware: x86-64 URL: https://archive.org/download/incoming_201401/incoming. exe OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: rbernon(a)codeweavers.com Target Milestone: --- Regression SHA1: 7df175a66faef1804ee84e278feecbd69a30cf37 Distribution: --- Created attachment 81966 --> http://bugs.winehq.org/attachment.cgi?id=81966 terminal output (Incoming demo version) The regression was introduced by commit: 7df175a66faef1804ee84e278feecbd69a30cf37 ddraw: Pass the active device to material_activate. Reverting this commit on current Wine 11.16 fixes the crash completely. The issue is reproducible with the original demo version and the Steam and GOG.versions as well. wine-11.16-156-g2ecc2f84b45 NVIDIA GeForce GTX 1660 SUPER NVIDIA 610.57.04 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 42877] New: SumatraPDF 3.1.2 tabs are covered by wine title bar
by wine-bugs＠winehq.org Oct. 16, 2026

Oct. 16, 2026

https://bugs.winehq.org/show_bug.cgi?id=42877 Bug ID: 42877 Summary: SumatraPDF 3.1.2 tabs are covered by wine title bar Product: Wine Version: 2.6 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ericbasil.rabi(a)gmail.com Distribution: --- The SumatraPDF 3.1.2 has tabs and menu button at the top of the window. These are partially covered by the wine title bar when not in full screen. When in full screen, the tabs and the menu button are almost complete covered. This makes accessing the menu and closing tabs impossible in full screen. I use ubuntu 16.04. -- 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 26

[Bug 59770] New: Broken Input under Neko Project 21/W (Gentoo Linux)
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=59770 Bug ID: 59770 Summary: Broken Input under Neko Project 21/W (Gentoo Linux) 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: enkiferreiracosta867(a)gmail.com Distribution: --- After the update to Wine version 11.9 (from 11.8), I noticed that, when playing Touhou on the Neko Project 21/W emulator, the input seems to be broken when attempting to move around. The game has a "slowdown" feature, where holding the Shift key makes the character you're playing as move slowly while you're moving it, but what happens here is that it feels like this key is kept being held down even if I'm not even touching it, despite me being able to type normally under the initial DOS command prompt. I then tried updating Wine to version 9999 (the live ebuild, updated on the latest commit), but no difference whatsoever. I've then tested the emulator on my Windows partition, and no issues were found there, so it can only be a Wine issue. -- 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 60328] New: Opening a menu in FL Studio instantly selects the menu entry the mouse is hovering - Regression
by WineHQ Bugzilla Oct. 16, 2026

Oct. 16, 2026

http://bugs.winehq.org/show_bug.cgi?id=60328 Bug ID: 60328 Summary: Opening a menu in FL Studio instantly selects the menu entry the mouse is hovering - Regression Product: Wine Version: 11.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: agarplayerarlon(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82092 --> http://bugs.winehq.org/attachment.cgi?id=82092 video of the issue This issue has started happening with wine 11.17, and now whenever I open a menu it instantly selects the menu entry that the mouse is hovering, but it shouldn't do that because I've only opened the menu and I didn't want to select anything. Expected behavior: I click to open the menu and nothing gets selected. Current Behavior Since Wine 11.17, when I click on a menu to open it, it also instantly selects the item that the cursor is hovering with the same click used to open the menu. I'll attach a video of the issue. If you want to reproduce this issue, FL Studio has a free version to download with no registration required. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4