Learning DCOM

Breaking into the Server

On the client side, it is very easy to set a breakpoint because you are in full control of the client component. You can set a breakpoint and debug the client component as a normal application. The execution will stop at the breakpoint because your client component is being interactively debugged.

However, it is much more difficult to set a breakpoint for server components. Recall from Chapter 4, that a class object that is registered (via the CoRegisterClassObject API function) to be REGCLS_SINGLEUSE can be used only by one client. This is because REGCLS_SIGNLEUSE tells COM to remove the class object from public view once a client has connected to it. A second client needing this class object will cause another component (i.e., a totally different process) to be activated.

For example, let’s assume that you start this kind of server component using Visual C++’s debugger and set a breakpoint at a specific location in the server code. Let’s further assume that the class object has been removed from the public view by the mere fact that its hosting component is executing (because it is being debugged).^[115] In this case, if a client requests to activate this class object, a separate process will be spawned to host the newly activated object. Therefore, you will never reach the breakpoint that you’ve set for the first activated component, which is still patiently sitting in the debugger waiting for a breakpoint that will never occur.

Assuming there’s no security ...