COM Server and Container Debugging
This topic applies to:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif "Topic does not apply") |
|
Native only |
|
Standard |
|
|
Native only |
|
Pro and Team |
|
|
Native only |
|
Table legend:
.gif "Topic applies") |
Applies |
|
Does not apply |
.gif "Topic applies but command hidden by default") |
Command or commands hidden by default. |
COM applications perform a number of tasks outside of the programmer's direct control. Communication between DLLs, usage counts on objects, and Clipboard operations are just a few of the areas where you might encounter unexpected behavior. When this happens, your first step is to track down the source of the problem.
You can debug a COM server and container using two projects within the same solution. Set appropriate breakpoints in each project and debug. When the container makes a call into the server that hits a breakpoint, the container will wait until the server code returns (that is, until you finish debugging it). You can also trace into calls that go across process boundaries. For more information, see The Trace Macro.
Debugging a COM container is similar to debugging a standard program. One difference is when you debug an event that generates a callback (such as dragging data over the container application). In this case, you must set a breakpoint in the callback function.
The Visual Studio debugger supports stepping across and into containers and servers. This includes the ability to step across remote procedure calls (RPC).
See Also
Tasks
How to: Debug COM Clients and Servers Using RPC Debugging