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@list.winehq.org Reporter: aktaskazimcan0@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.