COM Interop hang freezes entire COM system. How to cancel COM call

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?

Yahia · Accepted Answer · 2012-04-25T21:08:33.583

3

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...

edited Apr 25 '12 at 21:08

answered Apr 25 '12 at 18:30

Yahia

69,653
9
115
144

I have updated my question to provide some more details. Let me know if you still need more – Justin Pihony Apr 25 '12 at 19:37
@JustinPihony I updated my answer with an approach which would help with your scenario... – Yahia Apr 25 '12 at 21:09
Well, it sounds like this is the best way...not pretty but it should work. I very much appreciate the help – Justin Pihony Apr 25 '12 at 21:20
Why an .EXE instead of an AppDomain? – H H Apr 26 '12 at 07:37
1

@HenkHolterman in my experience with rather nasty cases the isolation provided by the OS (process boundaries) is superior to what is offered by .NET when using AppDomains (one AppDomains behaving really badly can still bring down the whole process which would contain the "main AppDomain" too)... – Yahia Apr 26 '12 at 07:53
@JustinPihony WCF is overkill IMO... basically any IPC mechanism (like MMF or TCP or UDP etc.) is usable - even exchanging the information via StdIn/StdOut could be an option - it all depends on what you need to transfer etc. Regarding the pseudo-code: which part (i.e. IPC or loading/running the EXE from embedded resources or...) ? – Yahia Apr 26 '12 at 16:28
@Yahia I was looking for the IPC part. I was actually going to do WCF based on suggestions. But now I am thinking namedPipes might work...I need something that can easily send the data to the exe and then hear back. – Justin Pihony Apr 26 '12 at 18:12
@JustinPihony what sort of data are you exchanging (big/small, text only/binary etc.) ? – Yahia Apr 26 '12 at 18:13
@Yahia Well, I will not be wrapping the entire API, so I will need to pass what method is being called along with the params, int, string, bool?...As well as event handling. That seems to me like it might be the more difficult part of wrapping this API – Justin Pihony Apr 26 '12 at 18:22
@Yahia Also, I greatly appreciate the help as this is not my expertise and need to get it done sooner than later...I have over 200 Rep today, so dont want to cancel my 200+ :), but will set a bounty to reward you tomorrow :) – Justin Pihony Apr 26 '12 at 18:27
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/10565/discussion-between-justin-pihony-and-yahia) – Justin Pihony Apr 26 '12 at 18:27
This proposed solution is what Microsoft themselves do with those 'COM Surrogate' processes. See https://devblogs.microsoft.com/oldnewthing/20090212-00/?p=19173. – Hugh W Sep 28 '22 at 17:08

score 1 · Answer 2 · answered Apr 25 '12 at 18:30

The third party DLL has some kind of indefinite wait, loop or deadlock inside it. Attempts to work around it like this will not work. You may have farmed out the hanging call to a worker thread, but that thread doesn't go away; it keeps hanging in that call.

The next call to the COM component freezes most likely because the previous one froze. Maybe it's trying to acquire a lock that the previous one acquired before hanging. Or maybe it's hanging for exactly the same reason, rather than a dependent reason.

Better contact the developers/vendors of this third party thing and ask them if you're misusing it in some way. Is there some missing precondition. Some initialization that wasn't performed. Some necessary configuration, etc.

COM Interop hang freezes entire COM system. How to cancel COM call

2 Answers2

Linked