http://bugs.winehq.org/show_bug.cgi?id=60225 --- Comment #4 from germanshtyrov@gmail.com --- Root cause found, with a patch that fixes it. Please disregard the truncation guess in my first comment - that was wrong, there is no truncation involved. RegisterDragDrop stores the raw IDropTarget pointer in the window property "OleDropTargetInterface", and refuses windows owned by another process: GetWindowThreadProcessId(hwnd, &pid); if (pid != GetCurrentProcessId()) return DRAGDROP_E_INVALIDHWND; so that pointer is only ever valid inside the window's owning process. RevokeDragDrop (dlls/ole32/ole2.c) has no such check: drop_target = GetPropW(hwnd, prop_oledroptarget); if(drop_target) IDropTarget_Release(drop_target); IDropTarget_Release() dereferences the pointer to reach the vtable, which is the faulting instruction. When one process revokes a window that a different process registered, that read hits a foreign address. WINEDEBUG=+ole shows exactly that pairing - the WebView2 browser process registers, the host application process revokes the same window: 0188:trace:ole:RegisterDragDrop (000000000001009A,00001A64009A7D20) 00f4:trace:ole:RevokeDragDrop (000000000001009A) and in the resulting fault RAX is exactly that registered pointer while RBX is exactly that window: rax:00001a64009a7d20 rbx:000000000001009a ole32+0x35e48: movq (%rax), %rdx The application vendor independently confirmed the call path: Tauri calls OleInitialize and RegisterDragDrop during window creation, and their splash window - unlike their main window - does not disable it. This cannot be worked around by configuration. WebView2 is always out-of-process relative to its host application, so any Tauri application can hit it. I also tried forcing the WebView2 renderer and GPU in-process through the documented AdditionalBrowserArguments policy (--single-process): the internal children do collapse into one process (Chrome_InProcGpuThread and Chrome_InProcRendererThread appear), but the WebView2 browser process stays separate from the host and the crash is unchanged. Proposed fix - only release the raw pointer when the current process owns the window. The marshalled drop target and the window properties are cleaned up as before: --- a/dlls/ole32/ole2.c +++ b/dlls/ole32/ole2.c @@ -628,6 +628,7 @@ HRESULT WINAPI RevokeDragDrop(HWND hwnd) IStream *stream; IDropTarget *drop_target; HRESULT hr; + DWORD pid = 0; TRACE("(%p)\n", hwnd); @@ -643,8 +644,15 @@ HRESULT WINAPI RevokeDragDrop(HWND hwnd) if (!(map = get_droptarget_handle(hwnd))) return DRAGDROP_E_NOTREGISTERED; - drop_target = GetPropW(hwnd, prop_oledroptarget); - if(drop_target) IDropTarget_Release(drop_target); + /* The raw pointer in prop_oledroptarget is only valid in the process that + * called RegisterDragDrop, which is always the process owning the window. + * Releasing it from any other process dereferences a foreign address. */ + GetWindowThreadProcessId(hwnd, &pid); + if (pid == GetCurrentProcessId()) + { + drop_target = GetPropW(hwnd, prop_oledroptarget); + if(drop_target) IDropTarget_Release(drop_target); + } RemovePropW(hwnd, prop_oledroptarget); RemovePropW(hwnd, prop_marshalleddroptarget); Verified: I built Wine 11.0 with and without this change and ran the same application against both. Vanilla 11.0 crashes on every start, at the moment the splash window is destroyed. With the patch the application starts and keeps running; its own log gets past the point that used to be fatal: "close_splashscreen: main window shown" "close_splashscreen: splash destroyed" Patch script and the build workflow: https://github.com/G6rm0k/wine-ole32-fix One open question. Skipping the release when a foreign process revokes leaks the owner's reference. Mirroring RegisterDragDrop and rejecting the call outright with DRAGDROP_E_INVALIDHWND may be the more correct behaviour - I did not do that because it changes the return value for existing callers. Happy to redo it either way. -- 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.