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

[Bug 60526] New: wineserver: OpenProcess ignores enabled SeDebugPrivilege; Backblaze 10.0.2+ backup service can't query its own uploader
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60526 Bug ID: 60526 Summary: wineserver: OpenProcess ignores enabled SeDebugPrivilege; Backblaze 10.0.2+ backup service can't query its own uploader Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: roy.dufek(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82389 --> http://bugs.winehq.org/attachment.cgi?id=82389 OpenProcess ignores enabled SeDebug On Windows, if the caller's token has SeDebugPrivilege enabled, OpenProcess grants the requested access regardless of the target process's security descriptor (MSDN, OpenProcess: "If the caller has enabled the SeDebugPrivilege privilege, the requested access is granted regardless of the contents of the security descriptor"). Wine's server never consults SeDebugPrivilege when opening a process, so the DACL check always applies. -- 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 60524] New: server: Keep an in-process mutex that a process closed while still using it
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60524 Bug ID: 60524 Summary: server: Keep an in-process mutex that a process closed while still using it Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)list.winehq.org Reporter: eggnet(a)gmail.com Target Milestone: --- Distribution: --- Follow-up to https://bugs.winehq.org/show_bug.cgi?id=60417 . A mutex that is unowned when its last handle is closed is destroyed on the server and forgotten, but a wait that was already pending on it holds a duplicate of its fd and can still acquire it, for instance a wait-all whose other objects are signaled later. If that thread then dies, nothing sends `NTSYNC_IOC_MUTEX_KILL` to the mutex, so it is never abandoned and another pending waiter blocks forever. Windows abandons it: in the new test, the second waiter gets `WAIT_ABANDONED_0` as soon as its own event is set. The client side can see when this may happen. The cache entry of an in-process sync is reference counted and a thread in the middle of an operation on the object holds a reference, so `NtClose()` (and `NtDuplicateObject()` with `DUPLICATE_CLOSE_SOURCE`) can tell that another thread is still using a mutex. In that case it passes the entry's serial number with the `close_handle` / `dup_handle` request, and the server keeps a reference to the in-process sync under (process, serial), which keeps the mutex on the list it kills at thread death. The entry's last user releases it with the new `release_inproc_sync` request; a process's records go away with the process. A handle closed while nobody else uses the object, the common case, involves no extra request. This is the arrangement the comment above `struct inproc_sync` in `dlls/ntdll/unix/sync.c` already describes (the object outliving its handle while a waiter uses it), with a serial instead of a handle. Not covered: users of entries that are not cached (a handle value reused while the old object is still in use, or more handles than the cache holds), which `NtClose()` cannot see. Those stay with the orphan list of !<MR 3>. Tested with `/dev/ntsync`: `kernel32:sync` and `ntdll:sync` pass; the new test passes (without the change the second waiter times out); the sequence passes 30 of 30 times as a 64-bit and as a 32-bit program; and the server's fd count is unchanged after 80 runs. The same test binary passes on Windows 11. The test is ordered after the fix: the CI has no ntsync, so a `todo_wine` would succeed there. Patch is here, written by an LLM: https://github.com/jegglest/wine/commit/ntsync-mutex-in-use-after-close -- 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 60523] New: ntdll: Take the in-flight alert when a RtlWaitOnAddress() wait times out after being dequeued
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60523 Bug ID: 60523 Summary: ntdll: Take the in-flight alert when a RtlWaitOnAddress() wait times out after being dequeued Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: eggnet(a)gmail.com Target Milestone: --- Distribution: --- A wake that races the end of a timed-out `RtlWaitOnAddress()` leaves the thread alerted. The wakers dequeue the waiter under the queue lock and alert it after releasing t he lock; a waiter whose timeout expires in between is already dequeued but returns `STATUS_TIMEOUT`, and the alert arrives with nobody waiting for it and stays pending. T he thread's next `NtWaitForAlertByThreadId()` then returns at once, whatever it waits for: an infinite `SleepConditionVariableCS()` or `SleepConditionVariableSRW()` on an unrelated condition variable, an SRW lock, a critical section. On Windows the thread has no alert pending after such a race. The new test shows it: a thread loops `RtlWakeAddressSingle()` or `RtlWakeAddressAll()` on an address while the test makes up to 20,000 `RtlWaitOnAddress()` calls on it with a timeout of 0 or 100 ns, and after each call `NtWaitForAlertByThreadId(NULL, 0)` must not find an alert pending. It passes on Windows 11 (0 pending alerts in each of the four cases) and fails on current Wine in 2 or 3 of the four cases per run, with 23 to 245 of the 20,000 waits leaving an alert pending. The fix is on the waiter's side only. A waiter that finds its entry already dequeued when its wait returns `STATUS_TIMEOUT` has been claimed by a waker that is about to a lert it, so it takes that alert with an untimed `NtWaitForAlertByThreadId()` and reports the wake. The wakers don't change, nothing new runs under the queue lock, and the re are no timing constants: the waker alerts within a few instructions of releasing the lock, which bounds the second wait. Alternatives I dropped: alerting under the que ue lock (a futex wake inside the spinlock on every lock and condition-variable wake), ignoring alerts that arrive while the entry is still queued (an alert does end a `Rt lWaitOnAddress()` wait on Windows), and a bounded grace period for the second wait (a constant, and Windows needs none). !3929 fixed the other way a thread could be left alerted after its wait ended, a waiter alerted twice by `RtlWakeAddressAll()`, for the same symptom (spurious `SleepConditionVariableCS()` wakeups crashing Resident Evil). This is the remaining case. What hits it in practice is zero-timeout waits: they are queued like any other wait and time out at once, so spinlock back-offs that poll with `WaitOnAddress(..., 0)` (gperftools' `SpinLockDelay`, used by tcmalloc) go through the race constantly. Warhammer 40,000: Space Marine 2 crashes mid-mission because of it (https://github.com/ValveSoftware/Proton/issues/8072) its tcmalloc back-off collects a stale alert, an unlooped `SleepConditionVariableCS(INFINITE)` waiting for a batch of file reads then returns early, and the completion callback writes into the dead stack frame. A stress program with 8 threads doing that sequence returns early in 13% of about 530,000 waits in 15 s on current Wine, in 0 of about 100,000 on Windows 11, and in 0 of about 530,000 with this change; the game no longer crashes with it. The test comes after the fix: the race is probabilistic, so a `todo_wine` would sometimes succeed on the unfixed code. This bug report replaces https://bugs.winehq.org/show_bug.cgi?id=60397 and is narrowly scoped to this issue. One way to fix this is here, written by an LLM: https://github.com/jegglest/wine/commit/waitonaddress-stale-alert This test code demonstrates the difference between Windows and wine behavior: https://github.com/jegglest/wine/commit/waitonaddress-stale-alert-test -- 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 60522] New: winebus.sys: input report queue never drops old reports, causing growing controller lag
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60522 Bug ID: 60522 Summary: winebus.sys: input report queue never drops old reports, causing growing controller lag Product: Wine Version: 11.20 Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: hid Assignee: wine-bugs(a)list.winehq.org Reporter: tomcool420(a)gmail.com Target Milestone: --- winebus queues every input report in ext->reports (process_hid_report in dlls/winebus.sys/main.c) and never drops any. If a device sends reports faster than they get read, the queue just keeps growing and the game sees older and older input. How I hit it: Steam Controller through Steam Input on macOS. Steam's virtual Xbox pad (045E/028E, picked up by the IOHID backend) sends a report for every little stick jitter, around 830/s even when you're barely moving. Under load, delivery to hidclass drops to roughly 520-700/s and the backlog never recovers. From a +hid trace of a Diablo IV session: - the queue peaked at ~14,700 reports, about 17 s of input lag - it only clears when Steam stops sending (alt-tab, quit), and then it drains at ~4,000 reports/s Native's HID class keeps input reports in a ring buffer (32 reports by default, see IOCTL_SET_NUM_DEVICE_INPUT_BUFFERS), so stale input can't pile up like this. Wine's own hidclass already does the same per handle. Seen on CrossOver 27 builds (Wine 11.15 and 11.17 based); process_hid_report is the same on current master. MR to follow. -- 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 60520] New: xmllite: Word silently corrupts Cyrillic text when reading DOCX; native xmllite fixes it
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60520 Bug ID: 60520 Summary: xmllite: Word silently corrupts Cyrillic text when reading DOCX; native xmllite fixes it Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: xmllite Assignee: wine-bugs(a)list.winehq.org Reporter: cactucatu4eckuu(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82379 --> http://bugs.winehq.org/attachment.cgi?id=82379 Original programmatically generated DOCX; never saved by Microsoft Word Microsoft Word 2016 running under Wine can silently corrupt Cyrillic text while reading DOCX files. This is not only a rendering issue: Word appears to receive already corrupted text internally. The corrupted text can be copied to the clipboard, and if the document is saved, Word writes the corrupted text back into the DOCX. Replacing Wine's builtin `xmllite.dll` with a native Windows `xmllite.dll` completely fixes the problem with the same original document. == Environment == Host: - Fedora 44 - Kernel: 7.2.9-201.fc44.x86_64 - Locale: ru_RU.UTF-8 for all locale categories; LC_ALL is unset Wine environment: - Bottles 67.4 (Flatpak) - Flatpak runtime: org.gnome.Platform/x86_64/50 - Wine: wine-11.0 (Staging) - 32-bit prefix - Windows compatibility mode: Windows 7 (6.1.7601) Application: - Microsoft Word 2016 MSO (16.0.4266.1001), 32-bit - Microsoft Office Professional Plus 2016 MSI Relevant DLL override present in both tests: - `gdiplus = native,builtin` I have reproduced the problem in Microsoft Word with DOCX files. I have not observed the same problem in Microsoft Excel in this environment. == Steps to reproduce == 1. Configure `xmllite` to use Wine's builtin/default implementation. 2. Open the attached original DOCX in Word 2016. 3. Some Cyrillic text is corrupted at deterministic positions. Reopening the unchanged original document corrupts the same locations again. 4. Copy one of the affected strings from Word and paste it into another application. The copied Unicode text is already corrupted, so this is not only a rendering/font problem. 5. Use "Save As" in Word and save the document to a new DOCX. 6. Open the newly saved DOCX in another DOCX reader, or inspect `word/document.xml`. The corrupted text has been written permanently into the document. 7. Replace Wine's builtin `xmllite.dll` with the native x86 Windows DLL described below and set: `xmllite = native` 8. Completely restart the Wine prefix and open the same unchanged original DOCX again. 9. The text is read correctly and the corruption no longer occurs. Saving the document also preserves the correct text. == Concrete example == The original attached DOCX contains the Cyrillic string: Нет After opening the document with Wine's builtin `xmllite.dll` and saving it from Word, the corresponding `word/document.xml` changes from: <w:t xml:space="preserve">Нет</w:t> to multiple runs containing: Не � w In other words, valid Cyrillic text from the original document is replaced with different Unicode characters, including U+FFFD REPLACEMENT CHARACTER, and the result is then written back to the DOCX. A larger diff between the original and corrupted `document.xml` is attached. == Expected result == Word should read the original DOCX without changing its text content. Opening and saving the document without intentionally editing this text must not alter the Unicode characters stored in the document. == Actual result == With Wine's builtin `xmllite.dll`, some Cyrillic characters are deterministically corrupted while Word reads the DOCX. Word subsequently operates on the corrupted text: - the clipboard contains the corrupted text; - Save As writes the corruption into the new DOCX; - other applications then see the corrupted content in the saved file. This therefore appears to be silent document data corruption rather than a display-only issue. == xmllite A/B test == Wine builtin xmllite: xmllite = builtin/default SHA-256: 52fa173979e9e8651864786a354baac6bc05d30677982e28fb0e6c70fbb77f06 Result: Cyrillic corruption is reproducible. Native xmllite used as workaround: xmllite = native File version: 10.0.18362.295 (WinBuild.160101.0800) Product version: 10.0.18362.295 SHA-256: 7ed70c14f7220eb3b1ca9da83e96abe5d2983852424f426f97f5b8abad34ea28 The native DLL is an x86 Windows `xmllite.dll`, reported as originating from Windows 10 1903 / build 18362. It was obtained from a third-party DLL archive, so I am providing the exact version and hash for reproducibility and am not attaching the Microsoft DLL itself. Changing only `xmllite` from Wine builtin to this native implementation eliminates the corruption for the same original DOCX. == Reproducer / attachments == The original DOCX was generated programmatically specifically to provide reproducible test data. It has not been saved by Microsoft Word before the test. I am attaching: 1. The original programmatically generated DOCX. 2. The same original document after opening and Save As with Wine builtin `xmllite` — contains the corruption. 3. The same original document after opening and Save As with native `xmllite` — text remains correct. 4. A diff of `word/document.xml` from the original document and the document saved with Wine builtin `xmllite`. == Possibly related report == There is an earlier CodeWeavers compatibility forum report for Microsoft Word / Office showing very similar Cyrillic text corruption. That report also mentions Wine's: fixme:xmllite:xmlreader_SetProperty Ignoring MultiLanguage ... and reports that replacing Wine's `xmllite.dll` with a native Windows implementation fixes the corruption. The report is in the CodeWeavers Microsoft Word 365 compatibility forum, message 302733. I do not know whether `XmlReaderProperty_MultiLanguage` is the direct cause of this bug. The corruption may be elsewhere in Wine's XmlLite parsing/encoding implementation. The native-vs-builtin A/B test is the reason I suspect `xmllite`. -- 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 8

[Bug 59954] New: Age of Empires 3: Asian Dynasties have graphical display issues in start screen and in game
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=59954 Bug ID: 59954 Summary: Age of Empires 3: Asian Dynasties have graphical display issues in start screen and in game Product: Wine Version: 11.12 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: robertyutintat(a)yahoo.com Distribution: --- AOE3: The Asian Dynasties show nothing in the start screen (all black) and in the game. Unconfirmed whether it is like this in game, but I will observe. Regression test will be performed at request. -- 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 35

[Bug 60521] New: Enshrouded 1.0 fails to start when HDR is enabled
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60521 Bug ID: 60521 Summary: Enshrouded 1.0 fails to start when HDR is enabled Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winewayland Assignee: wine-bugs(a)list.winehq.org Reporter: zsoli(a)protonmail.com Target Milestone: --- Distribution: --- Created attachment 82388 --> http://bugs.winehq.org/attachment.cgi?id=82388 game and steam logs Running mesa built from git (same happens with stable mesa release). Turning on HDR in Enshrouded 1.0 crashes the game, and since the setting is saved, it will keep crashing on new launches. The cause seems to be that the game initially starts in SDR sRGB colorspace, and then switches to HDR, which causes the following error: wp_color_manager_v1#19: error 1: surface already has a wp_color_management_surface_v1 err:waylanddrv:waylanddrv_unix_read_events Protocol error on wp_color_manager_v1#19 with code 1 Full logs attached. -- 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 60508] New: winsock: TCP SYN MSS and Window Scale negotiation discrepancy under Linux host cellular interfaces
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60508 Bug ID: 60508 Summary: winsock: TCP SYN MSS and Window Scale negotiation discrepancy under Linux host cellular interfaces Product: Wine Version: 10.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)list.winehq.org Reporter: info(a)neurobitlab.com Target Milestone: --- Distribution: --- When executing Windows anti-detect browsers and multi-profile scraping runners (such as AdsPower SunBrowser, GoLogin, or automated Chromium forks) inside Wine on Linux, socket connections initiated through Winsock (WSASocketW / connect) fail to properly inherit or reflect host TCP option parameters when bound to cellular interfaces (4G/5G USB modems with Carrier-Grade NAT). In standard Windows kernel network stacks, the TCP handshake SYN packet contains specific option orderings (MSS, Window Scale, SACK Permitted, Timestamps) defined by IETF RFC 7323 (https://datatracker.ietf.org/doc/html/rfc7323) and standard TCP semantics in RFC 9293 (https://datatracker.ietf.org/doc/html/rfc9293) When Windows applications run under Wine, Winsock delegates directly to the host Linux kernel socket layer. On mobile broadband links subject to GTP-U encapsulation and RFC 6598 carrier NAT, this creates passive OS fingerprint mismatches where upstream WAFs (Cloudflare, DataDome) detect Linux TCP SYN signatures despite the application advertising Windows HTTP headers: https://pxm2.io/blog/post/the-synergy-between-adspower-and-4g5g-mobile-prox… Steps to reproduce: 1. Run a 64-bit Windows Chromium / AdsPower instance under Wine 9.x/10.0 on Linux. 2. Route egress traffic through a local SOCKS5 proxy connected to an LTE/5G USB interface (e.g. Quectel EC25 / RM500Q). 3. Capture the outgoing TCP SYN packet on the egress interface using tcpdump: tcpdump -nn -i wwan0 "tcp[tcpflags] & (tcp-syn) != 0" -c 1 -vvv 4. Notice that Winsock does not allow setting custom TCP_MAXSEG or TCP window scaling flags via setsockopt(), leading to an identifiable discrepancy between the guest Windows user-agent profile and the host Linux SYN packet layout. Expected behavior: Winsock should provide a mechanism or configuration option (or honor socket-level options) to align TCP options negotiation with standard Windows socket behavior. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 58643] New: "floating" combobox dropdown area in winecfg
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=58643 Bug ID: 58643 Summary: "floating" combobox dropdown area in winecfg Product: Wine Version: 10.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: kyle.kcsoftwares(a)gmail.com Distribution: --- Open winecfg Dropdown a combobox While dropdown area is visible, move winecfg main window => dropdown area does not follow its combobox anchor and is kept "floating" at its original position. -- 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 6

[Bug 54858] New: Multiple games call for "Windows.System.DispatcherQueue" (Tannenberg, The Last Stand: Aftermath, The Long Dark)
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

https://bugs.winehq.org/show_bug.cgi?id=54858 Bug ID: 54858 Summary: Multiple games call for "Windows.System.DispatcherQueue" (Tannenberg, The Last Stand: Aftermath, The Long Dark) Product: Wine Version: 8.6 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com Distribution: --- Lots of 0e8c:fixme:combase:RoGetActivationFactory (L"Windows.System.DispatcherQueue", {00000035-0000-0000-c000-000000000046}, 00007FEEE4A0FA00): semi-stub 0e8c:err:combase:RoGetActivationFactory Failed to find library for L"Windows.System.DispatcherQueue" 8.6-29-ga19c1ff1697 -- 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 46