http://bugs.winehq.org/show_bug.cgi?id=59522 --- Comment #5 from Robert-Gerigk@online.de --- Thanks for the pointer on the threading model, Esme. That was the key. I tested two changes against ETS 6.4.0 (KNX building automation, .NET/WPF application using Microsoft.WindowsAPICodePack.Taskbar): Change 1: explorerframe.idl Changed the TaskbarList coclass threading model from "apartment" to "both": - threading(apartment), + threading(both), This eliminates the COM cross-apartment marshalling that caused the deadlock in TaskbarProgressManager.Initialize(). The CoCreateInstance call for CLSID_TaskbarList now completes without blocking. Result: 9 of 11 binary patches in the application DLL became unnecessary (Initialize, set_Progress, set_State, SetState, 3 obfuscated TaskbarProgressManager methods, 3 Dispose methods). Change 2: shcore/main.c Implemented Set/GetCurrentProcessExplicitAppUserModelID (were stubs): static WCHAR *explicit_app_user_model_id; SetCurrentProcessExplicit...: stores the appid via CoTaskMemAlloc GetCurrentProcessExplicit...: returns a copy, or E_FAIL if unset The previous stub returned *appid = NULL / E_NOTIMPL, wich caused "String argument cannot be null or empty" when the application's TaskbarManager tried to read back the ApplicationId it had set. Result: the remaining 2 patches became unnecessary (the obfuscated method accessing ApplicationId, and a tamper check). Combined results: With both changes, all 12 binary patches in the application are eliminated (11 method patches in a ViewModel DLL + 1 anti-tamper bypass in the executable). The application DLLs remain completly unmodified and the integrity check passes on its own. Testing was done by systematically restoring original bytes one patch at a time using a toggle script, confirming each method individually. I would be happy to prepare proper patches for both changes if this approach looks right. The shcore change is straightforward, the explorerframe threading change might need more thought regarding thread safety of the current stub Implementation (though the methods only return S_OK with no shared state). -- 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.