Obtaining .NET call stacks in a COM application
The procedure described here might be useful to obtain information about the QuickOPC call stacks when the program appears hung. QuickOPC is mainly written in .NET, and its COM objects are exposed as a layer on top of its .NET objects. This means that even if you are using a COM-based tools, such as VB6, Delphi, PHP etc. to access QuickOPC via COM, the underlying code still runs in Microsoft .NET (managed code). The managed get gets compiled to a native code and is afterwards in principle no different from other native code, but if you use a debugger of your COM-based tool, you won't be able to distinguish the .NET code from any other unknown machine code - specifically, it won't have any symbolic information available. This is unfortunate, because in principle, managed code contained in assemblies always comes with relatively rich metadata, including method names. This allows the .NET-aware debugger to display useful information about the managed call stacks even in absence of the source code or symbol files.
In order to resolve this problem, if a COM application appears hung and you suspect that the cause is in the .NET (managed) code, you need to use a debugger for a managed code. The most common such debugger is Visual Studio. Fortunately, you do not have to own a commercial edition of Visual Studio; it appears that a free edition works OK in this respect. We have tested the steps below with Visual Studio Community 2015.
If a COM application appears hung and you suspect that the cause is in the .NET (managed) code:
- Install Visual Studio.
