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

[Bug 60211] Rouvy crashes when connecting to a Bluetooth device

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60211 jsbjr(a)jsbjr.fr changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|download |hardware -- 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. 27, 2026

[Bug 60211] Rouvy crashes when connecting to a Bluetooth device

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60211 --- Comment #1 from jsbjr(a)jsbjr.fr --- Created attachment 81953 --> http://bugs.winehq.org/attachment.cgi?id=81953 output logs OK when overwriting the dlls from wine with WINEDLLOVERRIDES="msvcp140,msvcp140_1=n" /opt/wine-devel/bin/wine ~/.wine/drive_c/Program\ Files/VirtualTraining/Rouvy/Rouvy.exe The crash is gone but it doesn't connect to the Bluetooth device. the terminal output shows a lot of fixme and some errors (see attachment) for the details. Three errors about missing DLLS: 00f8:err:module:import_dll Library MSVCP140.dll (which is needed by L"C:\\Program Files\\VirtualTraining\\Rouvy\\Rouvy_Data\\Plugins\\x86_64\\ANT_WrappedLib.dll") not found 00f8:err:module:import_dll Library MSVCP140.dll (which is needed by L"C:\\Program Files\\VirtualTraining\\Rouvy\\Rouvy_Data\\Plugins\\x86_64\\DnsZeroConfLib.dll") not found 00f8:err:module:import_dll Library MSVCP140.dll (which is needed by L"C:\\Program Files\\VirtualTraining\\Rouvy\\Rouvy_Data\\Plugins\\x86_64\\DnsZeroConfLib.dll") not found The ANT_WrappedLib.dll is probably needed for the ANT+ protocol which is a wireless protocol used by lots of older sports devices, modern ones tend to use Bluetooth. The fixme seem to have different causes like like 3d, audio, Bluetooth control or kernel issue: - 3d 00f8:fixme:d3d:wined3d_guess_card No card selector available for card vendor 0000 (using GL_RENDERER "llvmpipe (LLVM 19.1.7, 256 bits)"). 00f8:fixme:dxgi:DXGID3D10CreateDevice Ignoring flags 0x20. 00f8:fixme:d3d11:d3d11_device_CheckFeatureSupport Returning fake Options support data. 00f8:fixme:d3d11:d3d11_device_CheckFormatSupport iface 00007FFFFE7F5580, format 29, format_support 00007FFFFE1FEA98 partial-stub! 00f8:fixme:d3d:wined3d_check_device_multisample_type multisample_type 32 not handled yet. 00f8:fixme:d3d11:d3d11_device_CheckFeatureSupport Unhandled feature 0x3 0200:fixme:d3d_shader:shader_sm4_read_param Skipping modifier 0x00014001. - kernel issue: 020c:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 00007FDAE42DFF50 - audio issue: 020c:fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",00007FDAE42DFEF8): stub - Bluetooth: 0360:fixme:combase:RoActivateInstance (00007FD8CD04E350, 00007FDA0D99FE70): semi-stub 0360:fixme:combase:RoGetActivationFactory (L"Windows.Devices.Bluetooth.Advertisement.BluetoothLEAdvertisementWatcher", {00000035-0000-0000-c000-000000000046}, 00007FDA0D99FE28): semi-stub 0360:fixme:bluetooth:adv_watcher_put_ScanningMode (00007FD9E99C83F0, 1): stub! -- 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. 27, 2026

[Bug 60245] Threadpool worker retirement cancels pending overlapped I/O after callback returns

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60245 Daniel Clark <megadjc(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |11.16 -- 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. 27, 2026

[Bug 60245] New: Threadpool worker retirement cancels pending overlapped I/O after callback returns

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60245 Bug ID: 60245 Summary: Threadpool worker retirement cancels pending overlapped I/O after callback returns Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: megadjc(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81952 --> http://bugs.winehq.org/attachment.cgi?id=81952 Two-patch series implementing ThreadIsIoPending and preventing threadpool worker retirement while thread-owned asynchronous I/O is pending. Wine can cancel ordinary overlapped I/O issued by a threadpool callback when the callback returns and the worker later becomes idle. I encountered this with DxO PureRAW 4, where a Qt threadpool callback issues an overlapped ReadFile() on a named pipe and returns while the read remains pending. Wine subsequently retires that worker after its threadpool worker timeout, which terminates the issuing thread and cancels the outstanding read. This can also be reproduced with a standalone Windows test and does not depend on PureRAW or Qt. Observed Wine behavior ====================== The relevant sequence is: threadpool callback -> ReadFile(named pipe, ..., OVERLAPPED) -> ReadFile returns FALSE / ERROR_IO_PENDING -> callback returns -> worker becomes idle -> Wine worker retirement timeout expires -> worker thread terminates -> pending overlapped read is cancelled -> GetOverlappedResult() reports ERROR_OPERATION_ABORTED With Wine's current: #define THREADPOOL_WORKER_TIMEOUT 5000 the PureRAW failure occurs reproducibly at approximately 5.05 seconds after the worker becomes idle. As an initial diagnostic experiment, changing only that timeout from 5000 ms to 60000 ms caused PureRAW to work correctly. This is not intended as the fix; it demonstrated that worker retirement was causing the I/O cancellation. Native Windows behavior ======================= I tested the corresponding behavior on Windows 11 with standalone programs. First, ordinary thread termination behaves as Wine currently expects: * A thread issues an ordinary overlapped named-pipe ReadFile(). * ReadFile returns ERROR_IO_PENDING. * The issuing thread exits. * The operation is cancelled. * GetOverlappedResult() returns ERROR_OPERATION_ABORTED (995). So Wine's general behavior of cancelling thread-owned asynchronous I/O when an ordinary thread terminates appears correct. Threadpool workers behave differently. Using a custom Windows threadpool with several workers: * one worker issued an ordinary overlapped named-pipe read and returned from its callback while the read remained pending; * the other workers owned no pending I/O; * the pool minimum was subsequently lowered so the workers became eligible for retirement. On native Windows, the workers with no I/O were retired, while the exact worker owning the pending overlapped read remained alive. In my native test the no-I/O workers were still alive at 65 seconds and had terminated by the 66-second sample. This is only an observed boundary and is not intended to imply that Windows has an internal 65-second timeout. The I/O-owning worker remained alive beyond that point. After data was written to the other end of the pipe, the pending read completed successfully. ThreadIsIoPending ================= The native behavior appears to be exposed through the ThreadIsIoPending thread information class. On native Windows: Ordinary event-backed overlapped named-pipe read while pending: NtQueryInformationThread(ThreadIsIoPending) status = STATUS_SUCCESS value = 1 length = sizeof(ULONG) After the operation is no longer pending: value = 0 An IOCP-backed operation that remains valid after the issuing thread terminates reports: value = 0 The IOCP operation also survives issuing-thread termination and later completes successfully. This matches the distinction Wine already makes when cancelling asynchronous operations during thread termination. I additionally tested the native ThreadIsIoPending query contract: * the output size must be exactly sizeof(ULONG); * invalid lengths return STATUS_INFO_LENGTH_MISMATCH; * a NULL output buffer with the correct size returns STATUS_ACCESS_VIOLATION; * THREAD_QUERY_INFORMATION access is required; * THREAD_QUERY_LIMITED_INFORMATION and SYNCHRONIZE alone are insufficient; * a valid handle to an already terminated thread succeeds and returns zero; * failed queries leave the output and ReturnLength untouched. Wine cause ========== Wine associates asynchronous operations with the issuing server thread. When a thread terminates, server/thread.c calls: cancel_terminating_thread_asyncs(thread) and pending async operations associated with that thread are normally cancelled. There is already an exception for operations associated with an I/O completion port and no event: if (async->completion && async->data.apc_context && !async->event) continue; Those operations survive thread termination, matching the native IOCP test above. The threadpool worker retirement code in dlls/ntdll/threadpool.c does not currently check whether terminating the worker would cancel pending I/O. Consequently an idle worker can be retired while an ordinary overlapped operation issued by one of its callbacks is still pending. Proposed fix ============ I have a two-patch series which: 1. Implements ThreadIsIoPending. The server uses the same predicate for both ThreadIsIoPending and cancel_terminating_thread_asyncs(), so the query reports exactly the asynchronous operations whose lifetime is tied to the queried thread. 2. Changes threadpool worker retirement so that, when a worker would otherwise retire, it queries ThreadIsIoPending and remains alive while such I/O is pending. Wine's existing 5000 ms worker timeout is left unchanged. Regression test =============== The patch series adds a deterministic regression test using a custom two-worker threadpool. The test: 1. creates two worker threads; 2. occupies one worker with a blocking callback; 3. has the second worker issue an overlapped named-pipe ReadFile(); 4. allows that callback to return while the read remains pending; 5. verifies that callback completion has occurred; 6. lowers the pool minimum and releases the blocking worker; 7. waits longer than Wine's worker-retirement timeout; 8. verifies that the worker owning the pending I/O is still alive; 9. writes to the other end of the pipe; 10. verifies that the read completes successfully. Without the worker-retirement fix, terminating the issuing worker cancels the read. With the fix, no-I/O workers retire normally while the I/O-owning worker is retained until the operation completes. Application impact ================== This was originally found with DxO PureRAW 4. PureRAW uses Qt named-pipe IPC. Under unmodified Wine the relevant connection is lost approximately five seconds after the callback that issued the pending read returns. A diagnostic Wine build with THREADPOOL_WORKER_TIMEOUT increased from 5000 to 60000 ms avoids the failure. The proposed patches do not change the timeout and do not contain any PureRAW-specific behavior; they implement the native threadpool/I/O semantics instead. Testing ======= Tested with: * native Windows 11 standalone conformance tests; * upstream Wine without the fix; * upstream Wine with the proposed patches; * DxO PureRAW 4; * dlls/kernel32/tests/thread.c; * dlls/ntdll/tests/threadpool.c. The existing ntdll/threadpool test suite has an unrelated pre-existing todo-success failure concerning timer merging. The proposed tests do not introduce an additional failure. -- 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. 27, 2026

[Bug 56681] 3d games continue receiving mouse input while not focused

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=56681 --- Comment #13 from Zhai Can <bczhc0(a)126.com> --- (In reply to Mel from comment #12) > I've just posted a patch here: > https://bugs.winehq.org/show_bug.cgi?id=59740#c2 > > It fixes this bug by fixing the root issue. I've tested it on Warframe > successfully, camera stops spinning and cursor is no longer invisible over > Warframe's surface when it doesn't have the focus. Please test with other > affected software. Tested with 4D Miner and my winit demo. It fixes the issue. But on Hyprland it doesn't work (app still not receiving focus loss on focus change to a non-wine app) for unknown reason. (works for kwin_wayland, mutter, niri, sway compositor but not for hyprland). -- 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. 27, 2026

[Bug 60176] Submit app broken

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60176 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #4 from Rosanne DiMesio <dimesio(a)earthlink.net> --- Closing fixed AppDB bug. -- 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. 27, 2026

[Bug 60176] Submit app broken

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60176 Rosanne DiMesio <dimesio(a)earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Rosanne DiMesio <dimesio(a)earthlink.net> --- This is fixed. -- 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. 27, 2026

[Bug 60241] Claude Core review report(a lot of copy paste and logic bugs uncovered)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60241 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 Nikolay Sivov from comment #2) > That doesn't seems like a reasonable approach. Indeed it seems unreasonable to auto create a bug per item and reporter was wise to guide the tool to avoid flooding Bugzilla. The LLM may have just used existing code analysis tools like SonarQube that predate latest LLM hype to compile the results. Adding a code smeller as part of Gitlab CI/CD workflow may produce a similar report and help devs catch bugs prior rather than after commits/merges which may avoid adding more to the list. Such tools also commonly offer ways to flag false positives so that they may be treated as lesser priority and reduce overall noise. Having these types of code smeller tools as part of Gitlab workflow seems to make more sense than running them as a separate independent efforts. -- 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. 27, 2026

[Bug 56681] 3d games continue receiving mouse input while not focused

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=56681 --- Comment #12 from Mel <pmargeti34(a)gmail.com> --- I've just posted a patch here: https://bugs.winehq.org/show_bug.cgi?id=59740#c2 It fixes this bug by fixing the root issue. I've tested it on Warframe successfully, camera stops spinning and cursor is no longer invisible over Warframe's surface when it doesn't have the focus. Please test with other affected software. -- 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. 27, 2026

[Bug 60244] New: Deadfall Adventures crashes in new WoW64 on NVIDIA when opengl32 exhausts the BAR1 heap

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60244 Bug ID: 60244 Summary: Deadfall Adventures crashes in new WoW64 on NVIDIA when opengl32 exhausts the BAR1 heap Product: Wine Version: 11.16 Hardware: x86-64 URL: https://store.steampowered.com/app/231330/Deadfall_Adv entures/ OS: Linux Status: NEW Severity: normal Priority: P2 Component: opengl Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com Target Milestone: --- Distribution: ArchLinux Created attachment 81951 --> http://bugs.winehq.org/attachment.cgi?id=81951 terminal output 'Deadfall Adventures' is a 32-bit D3D9 game. With current new-WoW64 Wine + wined3d + proprietary NVIDIA, the game crashes while loading the first level. The crash happens with graphical details set to "Very Low" as well as with "Very High". The crash occurs with EGL and with GLX backends too. Reproduced with Wine-11.1, 11.7, 11.16, wine git 11.16-76-g3489c653109 NVIDIA drivers tested: 580.178.04, 595.91.07, 610.57.04. The crash does not occur with: -old-style WoW64 / multilib Wine -nouveau -DXVK d3d9.dll Immediately before the crash: err:opengl:create_buffer_storage vkAllocateMemory failed: -2 fixme:opengl:wow64_map_buffer GL_MAP_PERSISTENT_BIT not supported! So then I asked AI what the issue might be...and it came up with a workaround/diagnostic patch. My NVIDIA GPU has a 256 MiB BAR1 aperture. Vulkan exposes: memory type 5: heapIndex = 2 DEVICE_LOCAL | HOST_VISIBLE | HOST_COHERENT heap 2: size = ~246 MiB During reproduction: main menu: BAR1 Used = 65 MiB second intro video: BAR1 Used = 214 MiB at crash: BAR1 Used = 246 MiB At that exact point vkAllocateMemory() returns VK_ERROR_OUT_OF_DEVICE_MEMORY. As a diagnostic test I changed the default Vulkan memory type selection in create_buffer_storage() in dlls/opengl32/unix_wgl.c: - uint32_t desired_type = type_mask; + uint32_t desired_type = + type_mask & ~VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT; This makes Wine use the HOST_VISIBLE | HOST_COHERENT non-device-local memory type instead. With this one-line change: BAR1 stays at ~19 MiB the first level loads successfully the game runs normally Very Low and Very High graphics settings both work Tested with wine-11.16-76-g3489c653109 NVIDIA GeForce GTX 1660 SUPER NVIDIA 610.57.04 OpenGL 4.60 -- 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. 27, 2026