Question

I am using a third party dll that is exposed via a COM Interop wrapper. However, one of the COM calls often freezes (never returns at least). To try to at least make my code a little more robust, I wrapped the call asynchronously (_getDeviceInfoWaiter is a ManualResetEvent)

var backgroundWorker = new BackgroundWorker();
      backgroundWorker.DoWork += 
        (sender, eventArgs) =>
          {
            var deviceInfo = _myCom.get_DeviceInfo(0);
            _serialNumber = deviceInfo.SerialNumber;
            _getDeviceInfoWaiter.Set();
          };
      backgroundWorker.RunWorkerAsync();
      var waitFifteenSecondsForGetInfo = new TimeSpan(0, 0, 0, 15);
      _getDeviceInfoWaiter.WaitOne(waitFifteenSecondsForGetInfo, true);
      if(String.IsNullOrEmpty(_serialNumber))
        throw new ArgumentNullException("Null or empty serial number. " +
            "This is most likely due to the get_DeviceInfo(0) COM call freezing.");

However, the very next call to any COM component will freeze the code. Is there something I am not thinking of, or is there some way to keep my main thread from dying?

UPDATE

Basically, this is a COM call that is called whenever a new device is plugged into the PC so that we can log the information appropriately. However, as I said, ANY COM component will freeze if this one is waiting (a custom COM of our own locks if the third party locked)

UPDATE 2

The above code DOES work, and delays the hanging of the UI thread until the next COM call. The reason for this attempted workaround was because var deviceInfo = _myCom.get_DeviceInfo(0); was already locking the UI thread. However, this info is not important and is only used for logging, so this approach is to allow for “give up and move on after 15 seconds” scenario

Another workaround here would be to find a way to cancel the COM call after x seconds?

Answer 1

UPDATE – after the second update from the OP

IF you have some problematic component you can always make your usage of it more robust by using the following approach:

Create a process (EXE) which wraps the usage of that component and exposes an API (for example via any IPC mechanism). You can then start that EXE as a separate process (from your main EXE) and use it… IF you need to kill that component after a certain time and/or when some condition is met you can always kill that “wrapper EXE” from your main EXE… depending on the specific component it might even be useful to implement some special “cleanup code” (possibly in a separate thread) within that “wrapper EXE” which gets executed when you need to kill that “wrapper EXE”.

Since you are implementing this in .NET you can even have that “wrapper EXE” as “embedded resource” in your main executable and start it even from RAM without writing it to the filesystem…