http://bugs.winehq.org/show_bug.cgi?id=59522 --- Comment #3 from Robert-Gerigk@online.de --- Thanks for the fast feedback Esme. Regarding Wine Mono: In my setup, Wine Mono is completlly removed. I disable mscoree during wineboot (WINEDLLOVERRIDES="mscoree=") to prevent Mono installation, then install the real Microsoft .NET 4.8 via winetricks dotnet48 and set *mscoree=native,builtin. The application runs on the native Microsoft CLR, not Wine Mono. The deadlock still occurs in this configuration, so it seems to be in Wine's COM infrastructure rather than Mono's threading code. The specific call chain that triggers it: 1. TaskbarProgressManager.Initialize() calls CoCreateInstance(CLSID_TaskbarList) to obtain ITaskbarList3 2. The COM apartment marshalling between threads blocks indefinitly 3. A second deadlock vector: Wizard ViewModel Dispose() methods call back into TaskbarProgressManager to clean up the progress state. 4. A third vector: async state machine MoveNext handler propagates the resulting exception, wich causes a crash My current workaround patches 30+ methods in the application DLL to return immediately (IL opcode 0x2A = ret), completly neutralizing the TaskbarProgressManager. Regarding the Architecture: makes sense to put this in the user driver. For the HWND-to-application mapping: I'm not familiar with BAMF in detail. Does Wine already interact with BAMF or similar window-matching daemons on the desktop side? If not, would matching the process executable name against installed .desktop files work as a simpler first step? That would cover the common Case where one .desktop file launches one Wine application. -- 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.