Debug with RPC

• Download BlackBox.zip - 121.9 KB
• Download Hello_rpc.zip - 9.4 KB

Introduction

This tip is not for NMAKE experts.

Background

At start we have our project cool_addon.dll that is intended for use with a non-debugable host. In practice such are most add-ons for known big applications like AutoCAD or IE. Here is an abstract sample of how to debug such an add-on with minimal recanting from a common developing process. As a base we use an ubiquitous Hello World from PSDK. This sample is live but uses a wide protocol that does not want to work on my single local machine. But MSDN has notes about the same project with a pipe oriented connection. It is a fish to consolidate them, all working as described. This NMAKE project has the main structure of our debug solution. Only things missing are compatible wrappers on both ends. Thus we begin.

Using the code

I use VS9 so all comments are about this environment.

First create a separate solution, and at once create a BlackBox - host simulator.  It used to study developing this system. BlackBox must load cool_addon.dll and make its testing calls. Place a reference to the compiled release at a convenient place like Service->External tools or near shortcut.

Next create an optional empty project rpc_core_dbg. To avoid compile errors set it as the tool project or .lib maybe. This project only launches MIDL, the purpose is not binary, RPC code only. Add a renamed copy of .idl and .acf from 'Hello world'. In my case VS does not understand the .acf format and I excluded it from compiling. It is reached with MIDL settings. Changing interface the name, uuid and implicit_handle name are not required, as you wish. The content of the interface can be fully cleared except the Shutdown function. It will be used for debugging the control. Now to the body of the interface declaration add declarations of functions listed in your .def, suffix/prefix and attribute them as demand RPC. Rename functions needed to be distinguish RCP from target to bind. Here it is all pithiness of the content of this project - create RPC transport code with compatible interface. To generate the common way, in project settings change the MIDL output header to rpc_core_dbg.h and output the path to  $(SolutionDir) for simply reaching current result - rpc_core_dbg.h, rpc_core_dbg_c.c, rpc_core_dbg_s.c in the relative projects. Where the .c generated transport code is for implementation on the appropriate end. rpc_core_dbg.h is solely for this transport. Extend MIDL command line with

/acf rpc_core_dbg.acf /client stub /server stub /rpcss /target NT51

This switches subjects for experiment, as do other MIDL settings. Performing the compilation of this project real only generates code, no binary executable. So it must be excluded from any configuration, because _.c files still need correction and surplus regeneration will harm its full ready view. Other settings has no effect on this task. I clear them.

The host simulator is on, now the client stub.  Add to solution new DLL project face_addon that fully repeated main cool_addon with settings and dll interface. Best way is using the same .def directly from source project and other shared files from solution top, so set additional include directoryes to $(SolutionDir). Add to this project rpc_core_dbg.h rpc_core_dbg_c.c . Set output binary name as original cool_addon.dll. Generally it is wrapper to rpc calls with interface of original cool_addon.dll. Changes about rpc for dllmain are borrowed from Hello project. Preparing and finalising of rpc calls united to singles at begin and to unloading library respectively. Clear prc is not wait apperance of target. It return error and client continues self wait in this situation. Simplest compilation will rise C1853 - C++c disaccord on rpc_core_dbg_c.c . It require separate .pch. Setting for precompiled header of this file: Create new nonStdAfx.h, named other.pch. But compiler again rises C1189 - version wrong, MIDL defines it for self only.  Well, strictly define required version:

#ifdef TARGET_IS_NT51_OR_LATER
#undef TARGET_IS_NT51_OR_LATER 
#endif
#define _TARGET_IS_NT51_OR_LATER 1

Anywhere inside nonStdAfx.h, I place it to shared targetver.h near others. Linker must have Rpcrt4.lib reference. Write it to project settings or like #pragma comment(lib, "Rpcrt4.lib") i place to StdAfx.h. Regenerated by MIDL rpc_core_dbg_c.c   not conatains required reference to its precompiled header #include "nonStdAfx.h".   I am add this stroke handly each time. That is "payment")  lazy write corrector).

Last step - server stub and back wrapper. Create executable Debugee project, not principal console or window. Anywhere call RPC server implementation. RPC server never leaved listen mode and is invisible/nonobstacle for debugging. So calm debugee seems like deadlock. RPC activity occurs direct in interface implementation where we place target call. Any requirements are the same as for client. Exept rpc_core_dbg_s.c using, note - _s postfix. Rename in cool_addon project settings binary output as dbg_addon.dll and use it in Debugee. Renaming output required another .def for this name. Or point output of Debugee and cool_addon to another folder. Maybe you prefer superpose original code in one project as .exe when debug and target .dll on release. This allow skip wrappers on server side but obtain naming conflicts that of course can solved witn #if. In conjunction with separating output such config seems more beauty. But i gather worst variant here). Here very many words, graph inside attached zip can help to sort dependencies. 

Points of Interest

Test. What you launch first doesn't matter. Set breakpoints in the cool_addon project, input any stroke in the host simulator. Debug.

Preparing exchanges is separate theme. Interesting point - interface function: double ArrayStringMess_dbg([in,out, size_is( 3 ), string]char**pp); generates a MIDL2291 warning, but code still truly work in both directions.

Sorry for bad English. Good luck!