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

[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 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |gitlab-unknown Product|Wine |WineHQ Gitlab Version|11.15 |unspecified -- 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. 28, 2026

[Bug 60251] New: ~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 Bug ID: 60251 Summary: ~29s stall on ntdll loader_section during startup, tied to a Win32_LogicalDiskToPartition WMI query on the Z: drive Product: Wine Version: 11.16 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)list.winehq.org Reporter: aktaskazimcan0(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 81964 --> http://bugs.winehq.org/attachment.cgi?id=81964 WINEDEBUG=+loaddll,+wbemprox trace showing the loader_section stall Note on environment: I'm running this under a Vinegar-managed prefix with DXVK-Sarek installed (native d3d8/d3d9/d3d10core/d3d11/dxgi overrides) and a custom Wine build (see "Additional information" below). I'm flagging this upfront per the Wine bug-reporting guidelines around native DLL overrides/third-party builds. That said, the stall happens while loading comctl32/compstui/winspool/wbemprox - none of the DLLs DXVK overrides - so it's unlikely to be DXVK-related, but I wanted to be transparent about the setup rather than have that surface later. Description of problem: On startup, my application (Roblox Studio, running under a Vinegar-managed prefix on Linux/CachyOS, btrfs root) consistently stalls for ~29 seconds early in startup, blocking the whole process. With WINEDEBUG=+loaddll,+wbemprox, the trace shows wbemprox.dll being loaded, followed by a ~29 second gap with *no trace output at all* on either channel, during which four other threads time out waiting on the ntdll loader_section (held by the thread that loaded wbemprox.dll). Full trace excerpt attached (winedebug-loaddll-wbemprox-trace.log). After the gap, thread 00fc proceeds through WbemLocator_create -> ConnectServer(ROOT\CIMV2) -> ExecQuery with an ASSOCIATORS query against Win32_LogicalDisk.DeviceID='Z:' (AssocClass=Win32_LogicalDiskToPartition). This query then resolves within the same second (fill_logicaldisktopartition created 1 rows, etc.) - the ~29s delay appears to happen *before* the WMI call chain is even entered (DllGetClassObject itself is the first thing logged after the gap), not within WMI processing itself. I was not able to pin down the exact syscall/operation responsible for the gap via strace - the slowest filesystem-related syscalls captured were on the order of tens of milliseconds, nowhere near 29s, so it does not appear to be filesystem/disk I/O bound in any obvious way. Happy to gather additional traces (e.g. a specific WINEDEBUG channel, or strace focused on a narrower window) if that would help narrow it down further. This reproduces consistently (every launch) on this system. How reproducible: Always (on this system) Steps to reproduce: 1. Launch an application that performs a Win32_LogicalDiskToPartition ASSOCIATORS WMI query against a drive early in startup (observed with Roblox Studio; have not yet tried a minimal WMI-only reproducer). 2. Run with WINEDEBUG=+loaddll,+wbemprox and observe the gap between wbemprox.dll loading and the first wbemprox trace line. Actual results: ~29 second stall, with the whole process blocked (other threads time out on the loader lock). Expected results: No significant stall before the WMI query executes. Additional information: - Wine version: wine-11.16 (custom build via vinegarhq/kombucha, built from upstream Wine commit 8da89f8493b21ebfbe344a54dbef0cde23c7ea59). This build carries 14 local patches; two touch ntdll (one adjusts LFH heap block-group lifetime in dlls/ntdll/heap.c, one narrows known-DLL/ search-path handling specifically for ucrtbase.dll in dlls/ntdll/loader.c - both ported from Valve's Wine/Proton fork). The ucrtbase.dll one does touch find_dll_file/open_known_dll in loader.c, though its actual behavior change is gated on the DLL name being "ucrtbase.dll" specifically, not wbemprox.dll/comctl32.dll/winspool.drv (the DLLs involved in this stall) - so it looks unlikely to be the direct cause, but I can't fully rule out an indirect interaction given it's in the same loader path. Neither patch touches wmi/wbemprox code directly. Happy to attempt a repro against a clean upstream Wine build if that would help isolate this. - Distro: CachyOS (Arch-based), root filesystem is btrfs - The affected drive (Z:) maps to the Linux root filesystem -- 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. 28, 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 --- Comment #17 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I have an atypical personality. I'm not like you, any of you. Regards. -- 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. 28, 2026

[Bug 38481] d2d1/tests/d2d1.c crashes when running under valgrind

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=38481 --- Comment #6 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Austin English from comment #5) > This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG > should only be closed when fixed upstream. > > Setting back to RESOLVED NOTOURBUG. Can we close this bug now that we're no longer triaging valgrind reports? -- 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. 28, 2026

[Bug 60092] Spotify Fails to Login

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60092 --- Comment #3 from spamemail392g(a)gmail.com --- I've uploaded the same version to the Internet Archive for easy access: https://archive.org/details/spotify_installer-1.2.94.583.g60394bd5-x64 -- 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. 28, 2026

[Bug 60140] Signature from BCryptSignHash with RSA 512 key and PSS padding cannot be verified

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60140 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Hans Leidekker <hans(a)meelstraat.net> --- Assuming 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. 28, 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 --- Comment #16 from Stian Low <wineryyyyy(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #13) > Spending token to get an AI to review the code located at a project URL, and then sending the result to the project team, is not "doing the work". Did the OP read and analyze that code review, validate and triage each issue (or even a single one)? No. All the work has yet to be done. Energy was spent so some work was done. Determining actual useful work vs wasted energy will be needed to further expose over-inflated AI bubbles. Assuming and treating AI/LLM reports as wasteful may be valid but whoever does so should be willing to do their duty of exposing the waste. Negative attitudes toward anyone not undermining AI bubbles and motives behind them are understandable so being a jerk at best may feel like a form of tough love. However AI is forced upon folks now more than ever ironically limiting choices and opportunities so empathizing with their situation may help. It's a pity intelligence seems ever degraded by and conflated with the artificial that disregards cost benefit analysis that wisers may have considered not worth the waste but it will take another paradigm shift to escape latest state of slop-overflow. Inability to cite/credit sources and tendency to plagiarize seems the major flaw (by design) meant to sell intelligence vs other less hyped tools and seems the root of the problem of deciding how to treat the HTML report. If AI/LLMs were more transparent then they may be treated as more trustworthy especially regarding risks around WineHQ's current LLM policy. -- 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. 28, 2026

[Bug 60214] bcrypt: BCryptExportKey/BCryptImportKeyPair lack BCRYPT_OPAQUE_KEY_BLOB support for asymmetric keys

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60214 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Hans Leidekker <hans(a)meelstraat.net> --- See comment 2. -- 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. 28, 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 --- Comment #15 from Stian Low <wineryyyyy(a)gmail.com> --- > Actually they did point out 3 issues that are very much real bugs. There are many more real bugs in that report. Even if you are not a fan of AI, you have to admit that it is useful data. Knowing how the report was produced may also be useful for WineHQ. For example, if it just used Coverty with different settings then that's something WineHQ could reproduce but more integral with existing CD/CI workflows. However if it behaves more like a black box unable to clarify to someone how to reproduce the report and is considered a competitor vs user of Coverty then it approaches conflict with WineHQ's current LLM policy. > If you are participating in bug triaging, you are the public face of the project, and you have a responsibility to be nice and welcoming to users, even if they don't conform to your strict idea of the rules. If you can't do that, you'll be asked to stop participating. Generally anyone reporting any bug should be met with appreciation. Excessive slop may warrant criticism but when human touch is sensed such as the case of this report then it should be handled in a less rude manner. Other LLM reports with less human touch may need some extra aggressiveness to help them learn better. Bug reporters stating upfront that they used AI should also be appreciated because it helps devs with context which may warrant more skepticism. Also, LLMs that only report bugs and not patches should also be appreciated because they are learning to conform with WineHQ's LLM policy which considers patch risky since internal Microsoft code could have been used as part of training thus violating mission critical clean rule policies. -- 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. 28, 2026

[Bug 60092] Spotify Fails to Login

by WineHQ Bugzilla

http://bugs.winehq.org/show_bug.cgi?id=60092 --- Comment #2 from spamemail392g(a)gmail.com --- (In reply to Ken Sharp from comment #1) > Tried Wine and Staging 11.16 and it doesn't get that far. It installs, hangs > around for a bit in the background, and exits silently. > > It looks like another CEF app. > > Which workarounds are you using? It seems like it only is able to launch into the login screen on specific versions. When I filed this bug, I was able to get it running on version 1.2.94.58, on Wine 11.14 staging. For it to launch, it needs these following dependencies - corefonts - vcrun2015 - d3dcompiler_47 I haven't tested it with 11.15 or 11.16 yet. However, I've tested more recent 1.2.x versions, and they experience the same thing you described, even with those dependencies installed. If you want to try it, here's the archive for that specific version: https://loadspot.amd64fox1.workers.dev/download/spotify_installer-1.2.94.58… -- 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. 28, 2026