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

[Bug 60255] ntdll: NtQuerySystemInformation(SystemPerformanceInformation) causes unhandled page fault (execute access to NULL) on native Win64 app

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60255 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal -- 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. 29, 2026

[Bug 60251] ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #5 from Kazim <aktaskazimcan0(a)gmail.com> --- > Are you sure about that? CoCreateInstance() is essentially a malloc() call > but ConnectServer() taking a long time would explain it. It resolves the > hostname which will time out if there's no response. Good question — I can answer that from the same reproducer's per-step timestamps, though I only posted the summary table above, not the raw per-call breakdown. Across every run I did (both Wine builds, TUN on and off): the elapsed time printed right after ConnectServer() is always within 0-2ms of the value printed right after CoCreateInstance() — e.g. 29830ms then 29830ms, 29821ms then 29821ms, 14ms then 16ms, 17ms then 17ms. So ConnectServer() itself is consistently near-instant (it fails fast with WBEM_E_INVALID_NAMESPACE either way) — it's CoCreateInstance() that swings from ~15ms to ~29800ms depending on TUN state, a ~2000x difference that has nothing to do with ConnectServer()'s hostname resolution. That matches your point about CLSCTX_INPROC_SERVER not needing the network — which is why I flagged it as surprising rather than claiming to understand the mechanism. Happy to strace just the CoCreateInstance() window with TUN on to see which syscall it's blocked in, or paste the full per-run logs here if that's easier to review. -- 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. 29, 2026

[Bug 60251] ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #4 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Kazim from comment #3) > In both "VPN on" runs, CoCreateInstance(WbemLocator) itself is what takes > the ~29.8s (ConnectServer then fails immediately after with > WBEM_E_INVALID_NAMESPACE, likely because this particular VPN setup Are you sure about that? CoCreateInstance() is essentially a malloc() call but ConnectServer() taking a long time would explain it. It resolves the hostname which will time out if there's no response. -- 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. 29, 2026

[Bug 59740] Programs running under Wayland do not notice when they lose focus

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=59740 --- Comment #4 from Mel <pmargeti34(a)gmail.com> --- (In reply to Ken Sharp from comment #3) > Patches aren't picked up from Bugzilla. See > https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patches Got it, thanks for the heads up. Merge request opened here: https://gitlab.winehq.org/wine/wine/-/merge_requests/11790 -- 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. 29, 2026

[Bug 60252] fix wow64 type cast bug + use-after-free of the demuxer context in demuxer_destroy/demuxer_create

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60252 Stian Low <wineryyyyy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy(a)gmail.com --- Comment #6 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Peter from comment #0) > I have been chasing a 'double/invalid free()' crash in WoW64, which did not occur in regular wine. That's the wrong type casting bug of the patch. Context regarding winedmo is important for understanding why this bug has not been encountered/reported until now. winedmo seems to have been introduced around the time new wow64 was being worked/released so it may not have been fully fleshed at the time. winedmo also seems to have been introduced in support of Proton related work which delayed transition to wow64 until more stable. Now that wow64 is considered more stable, transition for some Proton projects has begun so more wow64 specific code may be found needing similar fixes. Given the amount of time/effort just for winedmo to be considered for approval for merge it's understandable why time may have been limited to only supporting most relevant parts vs risking wasting too much time if ultimately rejected. > Like, why the rust people are not giving us a break. Languages supporting most breaks/liberty have their own advantages over restrictions otherwise considered safer and more helpful. Max slack of C vs rust is often conveniently appreciated despite some inconveniences elsewhere that balance for some cost/benefit preferences. (In reply to Rafał Mużyło from comment #2) > Likewise, exact app is irrelevant, when the code is obviously wrong. Providing at least one example of an app broken may still useful regardless to reproduce since tests aren't yet available to verify before/after results. winedmo is still less common so providing a track record of how to use and reproduce results for specific apps may be useful for future folks to set expectations. -- 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. 29, 2026

[Bug 60251] ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #3 from Kazim <aktaskazimcan0(a)gmail.com> --- Created attachment 81967 --> http://bugs.winehq.org/attachment.cgi?id=81967 Minimal reproducer, no DXVK/Roblox involved Update: I isolated this further and it is not DXVK/custom-build related - the actual trigger is a third-party VPN/proxy application (Throne, sing-box-based) running in TUN mode. I wrote a minimal reproducer that just does CoInitializeEx -> CoCreateInstance(CLSID_WbemLocator, CLSCTX_INPROC_SERVER) -> ConnectServer(ROOT\CIMV2) and prints a timestamp after each step (source attached, wmitest.c - compiled with MinGW, no DXVK/Direct3D/Roblox involved at all). Results, varying only Wine build and whether the VPN app's TUN interface is active: | VPN off | VPN on -------------------------------------------- custom Wine (this build) | 16 ms | 29830 ms stock Wine (fresh prefix,| 14 ms | 29821 ms distro package, never | | touched before) | | Same binary, same steps, same machine. The only variable that matters is whether the VPN app's TUN interface is up. Wine build (custom vs. a completely fresh prefix with the distro's stock wine package) makes no measurable difference - 2ms apart when the VPN is off (16 vs 14 ms), 9ms apart when it's on (29830 vs 29821 ms), both trivial next to the ~29.8s swing tied to the VPN toggle. So the local patches and DXVK-Sarek I mentioned in the original report can be ruled out; sorry for not catching this before the initial report. In both "VPN on" runs, CoCreateInstance(WbemLocator) itself is what takes the ~29.8s (ConnectServer then fails immediately after with WBEM_E_INVALID_NAMESPACE, likely because this particular VPN setup doesn't have a working RPC/WMI backend in the test prefix - that failure is expected and not the interesting part). Given CLSCTX_INPROC_SERVER is requested, CoCreateInstance shouldn't need to touch the network at all for a local in-proc COM server - my guess is something in Wine's COM/RPCSS local-server activation path performs a network-touching operation (hostname resolution, or opening some kind of loopback/network socket as part of RPC endpoint setup) that would normally resolve instantly, but this particular VPN app's TUN mode intercepts *all* traffic including what should be purely local/loopback, and that request ends up stuck behind the same kind of slow-path behavior I was tracking down in the original report (I don't have visibility into the VPN app's internals to say more precisely what happens to the request once it's intercepted). I want to be upfront that I have not identified the specific syscall or Wine source location responsible for the network touch inside CoCreateInstance - I can see that it happens and precisely what makes it fast vs. slow, but not the "why" at the Wine source level. Happy to gather more targeted traces (e.g. strace during just this reproducer, or a specific WINEDEBUG channel) if that would help pin it down further. I'm also going to file a separate report against the VPN application's own project, since it seems reasonable that a TUN interface should not intercept purely local/loopback traffic - but wanted to update this report first since it changes the diagnosis substantially from the original DXVK-adjacent framing. -- 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. 29, 2026

[Bug 60252] fix wow64 type cast bug + use-after-free of the demuxer context in demuxer_destroy/demuxer_create

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60252 --- Comment #5 from Rafał Mużyło <galtgendo(a)o2.pl> --- (In reply to Austin English from comment #4) > (In reply to Rafał Mużyło from comment #2) > > (In reply to Ken Sharp from comment #1) > > > Which Wine version? > > > > > > What app is causing this crash? > > > > Could we just call it 'current git head' and move on ? > > $ git describe > > works fine. > > Keep in mind that bugs are often read months/years later. It takes way less > effort for the commenter to write the actual wine version than it does for > someone to try to figure it out via git history after the fact. I'd say you have half a point there. I've said 'current git head', cause I've simply looked at gitlab to see if the code looks like the patch says it looks, not as in git part having any relevance. But if it took a couple months to pick up this thing (and sometimes it does take years), a point of reference is somewhat useful vs rechecking filing date against the list of git tags. -- 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. 29, 2026

[Bug 60235] Chronicles of Mystery / Art of Murder: intermittent vertex explosions with shadows and effects enabled

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60235 --- Comment #1 from Béla Gyebrószki <gyebro69(a)gmail.com> --- I found another game affected by the same regression: Hard Reset Redux. Unlike Art of Murder and Chronicles of Mystery, Hard Reset Redux is a Direct3D 11 game. With the offending Wine commit the game displays severe flashing, corrupted textures during gameplay. An interesting detail is that changing the in-game Vertical Synchronisation option temporarily fixes the rendering corruption. If I then change the graphics preset, for example from Ultra to Medium, which causes the game to reload its graphics resources, the corruption appears again. After restarting the game, the corruption is always present again regardless of which VSync setting was saved. wine-11.16-156-g2ecc2f84b45 -- 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. 29, 2026

[Bug 60207] VirtualDJ 2026: persistent skin corruption (ghost hover highlights, flickering) because d3d11_swapchain_Present1 ignores DXGI_PRESENT_PARAMETERS

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60207 --- Comment #9 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Rafał Mużyło from comment #8) > For the future, you should usually wait with resolving as FIXED till such mr > is actually merged. Agreed but it may be more appropriate to close as duplicate of bug-57473. Technically the description seems wider scoped than bug-57473 but all seem to fall within the same bug and fix. -- 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. 29, 2026

[Bug 35056] 64-bit PTC Pro Engineer Wildfire V5 installer fails (64-bit processors not reported in volatile hardware registry keys)

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=35056 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |ecbc4cf06d6c9253ba92065f320 | |ddd6eeff3177f Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Hans Leidekker <hans(a)meelstraat.net> --- Fixed by ecbc4cf06d6c9253ba92065f320ddd6eeff3177f. -- 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. 29, 2026