http://bugs.winehq.org/show_bug.cgi?id=60251 --- Comment #3 from Kazim <aktaskazimcan0@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.