Home/ Questions/Q 8612695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T04:41:28+00:00

I have a very strange situation, I haven’t seen such a thing before. I’m

  • 0

I have a very strange situation, I haven’t seen such a thing before.

I’m using the COM interface of third-party app, to communicate with the program. It’s in-process COM server. I use dynamic typing to access the object model of target application.

dynamic app = Activator.CreateInstance(Type.GetTypeFromProgID("SomeProgId"));

I use that app object to get other dynamic objects of the application. One of such objects represent quite large array, elements of which have numerous properties. I traverse all the elements of this array, and read all their properties, i.e. I parse the said object in a big loop (executing several minutes).

The problem is the following: sometimes, say once in ten tries, the thread just “hangs” when reading one of such properties (different one everytime):

string someString = app.SomeArrayObject.Get(i).SomeStringProperty;

I use the background worker to do this, and it just hangs on the above assignment. Quick note: the above statement is one-line simplification, in reality I access the objects one level at a time (“only one dot in each statement”), so it actually hangs on reading the SomeStringProperty property. Doesn’t throw exception, or anything, just hangs indefinitely. I noticed that The thread '<No Name>' (0x1240) has exited with code 0 (0x0). message is posted in the debugger’s output window just before that, so I believe some of the threads terminate unexpectedly (though no exceptions recorded!). When I break the debugging, the call stack is practically useless, as its usage is quite limited in such scenarios (inside COM object).

I don’t know why that happens, and how that’s even possible. Reading the simple string property results in a permanent hang. Do you have any ideas?..

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It was revealed, that the COM server was registered as being MTA-capable, but actually was designed for the STA mode only. The framework assumed it was ok to use it in MTA mode (as the corresponding registration entry in registry stated MTA was supported), and probably was creating some background threads periodically that resulted in exception. Setting thread’s mode to STA, or changing COM server’s parameters in registry to report STA-only, solved this mysterious random crashing problem.

    • 0