Here are three hot tips that'll help you use WPP tracing in drivers:
The first tip is to not include the WPP_INIT_TRACING macro in more than one module. Here's an sneak peak at an upcoming article from The NT Insider that explains the problem:
If you happen to be conditionally compiling your driver to work for XP and Windows 2000, you might notice that the WPP_INIT_TRACING macro on XP and later takes a pointer to your driver object instead of a device object. Therefore, you only need to call the macro once during DriverEntry processing. There is something to watch out for here though that tripped me up for a while. The WPP preprocessor will not tolerate the WPP_INIT_TRACING macro being in more than one module even if it is conditionally compiled out of one of the modules. So, if you call WPP_INIT_TRACING in your DriverEntry in one module if compiling for XP and call WPP_INIT_TRACING in your PnP module if compiling for Windows 2000, you will get compiler errors due to multiple definitions. The only solution is to add a separate module that exports functions that call the macros.
The second tip comes from a question that showed up on NTDEV the other day. If you want to conditionally compile your driver such that WPP tracing is enabled in the free build and DbgPrint is used in the checked build, you can't just define a macro that calls the trace function in the free build and DbgPrint in the checked build. The issue arises for a similar reason to that of the first tip, the WPP preprocessor and the C preprocessor don't exactly go out for drinks after work. Your best bet is to code up something like this in your SOURCES:
RUN_WPP=(Other parameters here) \
-func:OsrTracePrint(LEVEL,FLAGS,(MSG,...))
And this in your main include file:
#ifdef DBG
#define OsrTracePrint(_level,_flag_,_msg_) \
if (OsrDebugLevel >= (_level_) && \
OsrDebugFlags & (_flag_)) {\
DbgPrint (DRIVER_NAME": ");\
DbgPrint _msg_; \
}
#else
//
// Just let WPP define OsrTracePrint
//
#endif //DBG
The last tip to round out the trifecta is the WPP_DEBUG macro. If you define this to be the tracing function of your choice (say, KdPrint) your messages will be sent not only to the WPP trace consumer but also to the tracing function specified in the WPP_DEBUG macro. This is a cheap way to achieve a similar effect to that of the second tip.
#define WPP_DEBUG(_msg_) KdPrint _msg_
What the hell, I'm feeling a bit on the wild side today. Here's two more quick tips to help in debugging some of your WPP issues:
1) Add -v4 as an option to your RUN_WPP macro to put the trace preprocesser into verbose mode. This might help track down any compiling issues you may have
2) You can also define the WppDebug function, which spits out internal debug messages from the tracing code that is built into your driver:
#define WppDebug(_level_,_msg_) KdPrint (_msg_)
Post Your Comment
