Bugzilla

1. Ideally, we would have a good way to mock the OS API itself at the OS level (that is, in the registry) and substitute our own implementations of those interfaces that just do logging. I don't think we're going to find an easy and non-extremely hacky way to do that though. So I think what you've got is probably a good move, to just use our own wrapper thing that we dependency inject an implementation of.
2 and 3. So, we should only need locking here to protect our own objects; I looked up the registrations  for these MSCOM objects and they're registered with ThreadingModel=Apartment, which means the COM runtime is already synchronizing/queuing those calls for us. It should not matter whether we're making calls from the main thread or not (provided whatever thread we're on has had a good CoInitialize call done for it already). Consequently, I also don't think it matters which thread issues the final Release call, it should always get marshaled to the object's apartment thread.

1. Ideally, we would have a good way to mock the OS API itself at the OS level (that is, in the registry) and substitute our own implementations of those interfaces that just do logging. I don't think we're going to find an easy and non-extremely hacky way to do that though. So I think what you've got is probably a good move, to just use our own wrapper thing that we dependency inject an implementation of.

2 and 3. So, we should only need locking here to protect our own objects; I looked up the registrations  for these MSCOM objects and they're registered with ThreadingModel=Apartment, which means the COM runtime is already synchronizing/queuing those calls for us. It should not matter whether we're making calls from the main thread or not (provided whatever thread we're on has had a good CoInitialize call done for it already). Consequently, I also don't think it matters which thread issues the final Release call, it should always get marshaled to the object's apartment thread.