Zhiyi Zhang (@zhiyi) commented about dlls/mfplat/tests/mfplat.c:
ok(hr == S_OK, "Failed to cancel item, hr %#lx.\n", hr);
refcount = IMFAsyncCallback_Release(&callback->IMFAsyncCallback_iface); - todo_wine ok(refcount == 0, "Unexpected refcount %lu.\n", refcount); + ok(refcount == 0, "Unexpected refcount %lu.\n", refcount);
After 7865026, won't the callback be eventually released in scheduled_item_cancelable_callback() or waiting_item_cancelable_callback()? How does the memory leak happen? If you're referring to the callback reference count should immediately be zero after calling MFCancelWorkItem(), I don't think that's that big of an issue. Is there an application that depends on the reference count being zero immediately after MFCancelWorkItem()? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_63658