I’m investigating possibly converting our NDIS kernel driver from traditional dbgprints to WPP-based ETW prints.
Currently, our our checked-build dbgprints just appear on the windbg screen as they occur. This is *vital* to every kernel developer. But to do the same thing with WPP, you first have to 1)go off and run a user-space app (tracelog, etc) to start an ETW session and redirect it to windbg. And then 2)you have to run the !wmitrace command in windbg itself. I assume you have to re-do step 1 every time you unload and reload the driver as you develop it, please correct if I’m wrong. So there are more steps to follow, just to get the same daily-used functionality we already have for free with dbgprint.
–>My question: is it possible to accomplish step 1 via a command in windbg?
I do know about the WPP_DEBUG macro, but all that does is just copy all the WPP traffic back to dbgprint, which is again what I already have.
I do know that ETW can be helpful from a customer-support perspective, but I’m trying to also make it brain-dead simple for us driver-devs too.
Basically during development you want to have a boot time session been started
In XP and W2K3 you can log your events to the GlobalLogger session. See more on GlobalLogger session on MSDN.
You just configure the globalloger session with tracelog, you add your provider to the globallogger.
In Vista and above you can use the AutoLoggers to configure your boot time session. Also see more on
this in MSDN.
This boot time session continue to run until you stop them, so you can load and unload your driver
with no problem.
One additional question I have now. Is it possible to call DoTraceMessage from a centralized macro which is located in a .h file? The .c files will all call the macro to do tracing. If I try this, I get these compile errors:
Compiling message file - common\messages.mc
BUILD: Compiling c:\code\windows_ixgbe_ndis\common directory
Compiling - common\dce.c
errors in directory c:\code\windows_ixgbe_ndis\common
c:\code\windows_ixgbe_ndis\common\dce.c(100) : error C3861: ‘WPP_CALL_dce_c100’:
identifier not found
c:\code\windows_ixgbe_ndis\common\dce.c(100) : error C3861: ‘WPP_CALL_dce_c100’:
identifier not found
c:\code\windows_ixgbe_ndis\common\dce.c(101) : error C3861: ‘WPP_CALL_dce_c101’:
identifier not found
Basically, right now I have a centralized macro in a .h file that just calls dbgprint. I want to replace the dbgprint with a call to DoTraceMessage. But I get the compile errors above in every .c file on every line that calls the macro. The compile errors seem to indicate that WPP is inserting WPP_CALL_** calls in dce.c file, but is not actually defining that macro in the dce.c.tmh file. Inspection of the .tmh file shows that the macro is indeed not there.
Also, how do I generate a .tmf file during driver build? All I get on my windbg screen is:
Unknown( 10): GUID=f7201102-65ff-413e-8fd7-f90c1b125ba7 (No Format Information found).
Unknown( 10): GUID=f7201102-65ff-413e-8fd7-f90c1b125ba7 (No Format Information found).
Is it possible to just point windbg to my source file directory and the pdb file and get windbg to just read the tmf information automatically?
I have tried using tracepdb but all I get is:
Microsoft (R) TracePDB.Exe (6.0.6001.18000)
⌐ Microsoft Corporation. All rights reserved.
Functionality for Extracting TMF out of PDB file not availalbe
UPDATE your DEBUGGER and use that DBGHELP.dll
I am using the latest debugger. I got rid of all the other dbghelp.dll files on my disk, except the one that comes with the ws08 WDK.
As I’ve stated before, I only use WPP for fre builds and standard
DbgPrint() for chk builds. The same messages are used for each via a
couple small Macros and Functions.
The DDK/WDK samples use WPP so you can use those as examples of how to
implement the nitty gritty details.
Also, how do I generate a .tmf file during driver build? All I get on my windbg screen is:
Unknown( 10): GUID=f7201102-65ff-413e-8fd7-f90c1b125ba7 (No Format Information found).
Unknown( 10): GUID=f7201102-65ff-413e-8fd7-f90c1b125ba7 (No Format Information found).
Is it possible to just point windbg to my source file directory and the pdb file and get windbg to just read the tmf information automatically?
I have tried using tracepdb but all I get is:
Microsoft (R) TracePDB.Exe (6.0.6001.18000)
⌠Microsoft Corporation. All rights reserved.
Functionality for Extracting TMF out of PDB file not availalbe
UPDATE your DEBUGGER and use that DBGHELP.dll
I am using the latest debugger. I got rid of all the other dbghelp.dll files on my disk, except the one that comes with the ws08 WDK.
I just tried adding -DEVENT_TRACING -DWPP_POOLTYPE=NonPagedPool as you suggested, but I still didn’t get a .tmf file. I have lots of .tm*h* files but no .tm*f* files.
Here is my RUN_WPP line:
RUN_WPP=-km -dll -ext:.h.hpp.c.cpp -preserveext:.c.cpp.h.hpp $(SOURCES)
Any other ideas?
I’m still suprised that I can’t point windbg at the .pdb file, since that is where the .tmf information is supposed to come from in the first place. Seems like windbg should be able to get the formatting info right out of the .pdb.
the .tmf files are actual files which endup in a directory named
TraceFormat, AFAIK, they are not compiled in with the .pdb … but
again, I don’t use them on checked builds either if that’s what you’re
looking for.
I just tried adding -DEVENT_TRACING -DWPP_POOLTYPE=NonPagedPool as you suggested, but I still didn’t get a .tmf file. I have lots of .tm*h* files but no .tm*f* files.
Here is my RUN_WPP line:
RUN_WPP=-km -dll -ext:.h.hpp.c.cpp -preserveext:.c.cpp.h.hpp $(SOURCES)
Any other ideas?
I’m still suprised that I can’t point windbg at the .pdb file, since that is where the .tmf information is supposed to come from in the first place. Seems like windbg should be able to get the formatting info right out of the .pdb.
I’m using the autologger setup recommended at the start of this thread. When I boot the OS, the traces do not come out on the kernel debugger, although they are accumulating inside the OS. Is there a registry key to make them go to the debugger like dbgprint does? Otherwise, I have to start traceview and start a new session, redirected to windbg, in order to see the traces on the debugger. And if I’m starting a new session, then the autologger session isn’t helping me any, unless I misunderstand.
Are there any experts out there that are willing to help a newbie through these problems?
I have read all the OSR article, and I’ve also tried using the tracedrv sample. But none of those seem to answer the questions I’m asking about here.