I think this should be reverted and overall it doesn't look like to be a similar scenario as what b4da14035741f287130002b512c7d0e9117da80a is addressing (fwiw I added a test for b4da14035741f287130002b512c7d0e9117da80a in !8235 which shows that it was correct indeed). The `apartment_get_current_or_mta` functions returns the current thread apartment first, then the MTA if it exists, or NULL if neither. The `ClientRpcChannelBuffer` oxid is set in `rpc_create_clientchannel`, called from `std_unmarshal_interface`, from the apartment returned by `apartment_get_current_or_mta` at that time. In `ClientRpcChannelBuffer_IsCorrectApartment`, it was compared to the oxid of the apartment returned from `apartment_get_current_or_mta`, when any remote method is being called. In Wine, OXID are not dynamically generated but instead are based on PID:TID for STAs, and PID:0xcafe for the MTA, so they would only change between thread STAs and between STA and MTA, even if apartments are re-created. So, IIUC the check would fail if: * Interface has been unmarshaled in the MTA, and: * The thread calling the method is in an STA. This is tested already by `implicit_mta_unmarshal_proc` and `implicit_mta_use_proc`: calling from another thread in the MTA works but if that thread joins an STA it should fail. * The thread calling the method doesn't have an apartment. This is tested in `test_proxy_used_in_wrong_thread` already and should fail. * Interface has been unmarshaled in an STA, and: * The thread calling the method is not in an apartment. This is tested in `test_proxy_used_in_wrong_thread` already and should fail. * The thread calling the method is explicitly in the MTA. This is tested in `test_proxy_used_in_wrong_thread` already and should fail. * The thread calling the method is in an implicit MTA. !8235 adds such a case to `test_proxy_used_in_wrong_thread` but it should fail too. * The thread calling the method is in another STA. !8235 adds such a case to `test_proxy_used_in_wrong_thread` but it should fail too. I don't see any other case where the check could be wrong, so if there's something going on it probably comes from somewhere else and the change should be reverted. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8021#note_105745