COM Server and Container Debugging

This topic applies to:

Edition

Visual Basic

C#

C++

Web Developer

Express

Topic does not apply Topic does not apply

Native only

Topic does not apply

Standard

Topic does not apply Topic does not apply

Native only

Topic does not apply

Pro and Team

Topic does not apply Topic does not apply

Native only

Topic does not apply

Table legend:

Topic applies

Applies

Topic does not apply

Does not apply

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 Servers

How to: Debug COM Clients and Servers Using RPC Debugging

Other Resources

COM and ActiveX Debugging