none
What's the proper method to display driver trace messages? RRS feed

  • Question

  • The sample drivers use "TraceEvents" macros to display diagnostic and useful information.

    Obviously, I'd like to see these events as they occur, and to offer me help in obtaining information on my driver while it's running.

    Searching on this yields "TraceView".

    The only way I got this to work a bit is to manually copy the driver's PDB file onto the debug target machine, run TraceView there and then point it to the PDB file.

    This is rather cumbersome and requires a few dozen mouse clicks on every attempt. I had rather hoped to see some messages in the debugger when I press F5 on the build machine.

    Any advise on this, there must be a nicer way to get some diagnostic output from the driver?

    Monday, August 24, 2015 8:00 AM

Answers

  • For now, I'm reasonably happy with DbgPrint.

    Strangely, DbgPrint messages do not show up in the (remote) debugger. They do show up when I run DbgView (as admin) on the target machine though.

    Ah well, I got the driver to initialize, aquire and map its resources, and got it to crash the system, probably by having the DMA write to the wrong address, so there's been a lot of progress for me, thanks to all your kind suggestions.

    Next up is to investigate how to get rid of the "friendly" BSOD and get the old one back that at least showed some indication of what actually happened :)

    Tuesday, August 25, 2015 1:33 PM

All replies

  • In Windbg there are a set of commands !wmitrace.* that control tracing.  Take a look at https://msdn.microsoft.com/en-us/library/windows/hardware/ff552961%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 for all the tools and support available.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Monday, August 24, 2015 10:33 AM
  • The link you provide is about Traceview and friends. I've read all that, but it doesn't contain any clue as to how one can look at driver output. Running traceview isn't the problem - it's getting it to run without having to manually copy files over and clicking a few dozen times on various windows to get it to output anything.

    I guess the "wmitrace" commands must be aimed at the debugger. But that won't work, because by the time I get to break into the debugger, the driver initialization messages have long since vanished from the machine's memory, and at this early stage of driver writing, initializing properly is not something that my driver can do yet.

    (I also tried putting breakpoints in the driver, but they don't work at all, the debugger never kicks in unless I press ctrl-C. Guess that's offtopic for this thread.)


    Monday, August 24, 2015 10:51 AM
  • I also tried using "DbgPrint". Compiles fine, but the strings are not being output anywhere. So that's a fail too.

    What does one really have to do to get the equivalent of "printk" in Windows?

    Monday, August 24, 2015 11:44 AM
  • DbgPrint is the equivalent of printk.  You do need to set the registry to see DbgPrint output, get the OsrSysTool http://www.osronline.com/article.cfm?article=537 to easily do this.

    Which debugger are you using, and what is the driver load time?  I have not had good luck with the Visual Studio debugger and kernel debugging (but then I have used Windbg for 20 years).  My recommendation is setup Windbg, boot the system and break into Windbg.  Make sure the symbols are good, and continue.  In your driver hard code a DbgBreakPoint() call at DriverEntry to be sure to catch the start of the driver.  You should then be good to go on debugging.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Monday, August 24, 2015 12:22 PM
  • I'm using Visual Studio 2015. Installed the WDK 10 and I'm using whatever version of the debugger that happens to be built into that and runs when you press F5. The target is a windows 8.1 machine, set up for kernel debugging.

    I don't have the faintest idea what the driver load time is. Should be something like a few milliseconds, as all it tries to do now is enumerate the BARs from the PCIe device and then just happily report that all is fine. I can see the driver in the Device Manager and it is showing the BAR configuration there.

    Monday, August 24, 2015 12:46 PM
  • DbgBreakPoint() seems to be what it takes to get into the debugger. Without it, it will never trigger anything, regardless of whatever breakpoints you may have set.

    Important drawback is that this also triggers when the driver unloads. Really, when the driver is being removed, all the initialization methods are being called. Huh?

    Also, hitting the breakpoint this way causes the system to hang at boot when the driver loads. Debugging it helps it move along...

    Monday, August 24, 2015 2:01 PM
  • Much easier than subscribing to yet another website and downloading an untrusted executable was to simply edit the registry and add the required key to make DbgPrint work.

    Put these three lines into a .reg file and import it with regedit:

    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Debug Print Filter]
    "DEFAULT"=dword:ffffffff

    Monday, August 24, 2015 2:07 PM
  • Just wondering here, all the WDK templates and examples are sprinkled with TraceEvent calls, but no one here actually actually know how to put them to use?
    Monday, August 24, 2015 2:08 PM
  • That is what !wmitrace.* does for you and the page I pointed you to contains a lot more than trace view.  You can get traces in the debugger.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Monday, August 24, 2015 2:14 PM
  • For now, I'm reasonably happy with DbgPrint.

    Strangely, DbgPrint messages do not show up in the (remote) debugger. They do show up when I run DbgView (as admin) on the target machine though.

    Ah well, I got the driver to initialize, aquire and map its resources, and got it to crash the system, probably by having the DMA write to the wrong address, so there's been a lot of progress for me, thanks to all your kind suggestions.

    Next up is to investigate how to get rid of the "friendly" BSOD and get the old one back that at least showed some indication of what actually happened :)

    Tuesday, August 25, 2015 1:33 PM
  • DbgView sets the registry value for the DbgPrint's, I suspect you do not have it set correctly when you try the remote debugger.


    Don Burn Windows Driver Consulting Website: http://www.windrvr.com

    Tuesday, August 25, 2015 1:44 PM
  • the old BSOD screen that showed details is long gone, there is no hidden setting to make it come back.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, August 25, 2015 4:28 PM