Windows Driver Debugging

Posted April 9, 2003

Chat Date: March 27, 2003

Please note: Portions of this transcript have been edited for clarity

Chat Participants:

• Martin Chisholm, Tester in the Active Directory team
• Adi Oltean, Developer in the Storage Services team, Windows group
• Jamie Hanrahan, MSFT MVP, Driver consultant and seminar leader
• Larry King, Writer for debugger documentation
• Brian Catlin, MSFT MVP, Driver consultant and seminar leader
• Laura Keller, Program manager, Technical & Strategic Communications
• Eric Sassaman, Program manager, Product Support Services

We know that thousands of people read these transcripts on MSDN, but we would like to know how useful they are to you. Please send us an email at ATEO@Microsoft.com and tell us how this information or redirection to other information sources helped you do your job.

Moderator:Eric S (Microsoft)
Hello, today's chat on Windows Driver Debugging will begin shortly. Thank you for your patience. Please hold your questions until the chat begins.

Host: Larry (Microsoft)
Q: Larry, thanks for the improvement to the documentation over the last two years! The improvements have helped dramatically!

A: You're very welcome. As always, we welcome your suggestions for how the documentation can be even more improved!

Host: Martin (Microsoft)
Q: I used '!process <process> f'. How do I get good call stacks for user mode?

A: Use '.process /p <process>' first. Then proceed with the '!process'

Host: Brian (Microsoft)
Q: I am not exactly sure if this is on topic but I wonder why is it you only can get a checked build by purchasing the MSDN subscription?

A: From what we understand (since none of us work for MSDN), is that MSDN is the channel that is used, because there hasn't been enough requests to do it otherwise. It also makes it easier because all the developer material ships with MSDN.

Host: DHolcomb (Microsoft)
Q: I used '!process <process> f'. How do I get good call stacks for user mode?

A: After doing .process <process> you should .reload /user

Host: Larry (Microsoft)
Q: For extension dll writer support, have you considered adding some utility template functions to the extension header files? I've written a few of my own which made copying objects out of dump files much easier.

A: Do you have any specific suggestions? (By the way, documentation of the debugger extension API will hopefully be ready sometime this year.) To be more specific, I mean dbgeng.h (and possibly also wdbgexts.h).

Host: Brian (Microsoft)
Q: Hi, my question is related to the way the debugger loads symbols. Will the debugger still load symbols from the symbol server/tree if the header info of the image file is not available/paged out?

A: Not always. Sometimes if the image path is specified the debugger will find it. Y=ou can also try .reload -i

Host: DHolcomb (Microsoft)
Q: Hi, my question is related to the way the debugger loads symbols. Will the debugger still load symbols from the symbol server/tree if the header info of the image file is not available/paged out?

A: BTW, the latest debuggers will search the symbol path for binaries if the image path is not set

Host: Brian (Microsoft)
Q: Followup BrianC_azius: For small developers it is very hard to afford the MSDN. Guess there would be some request for it as a standalone version

A: We'll pass the request along

Host: Brian (Microsoft)
Q: Are there any new debugger features explicitly targeted for Windows 2003?

A: The debugger is largely independent of the operating system version; however, the kernel extension DLL is updated to reflect new capabilities of the OS

Host: Larry (Microsoft)
Q: Sure. I've got a non-templated function, CopyDataFromSymbolName, which takes a pointer to fill in, a size, and a symbol. Then I have a templated CopyObjectFromSymbol function that takes a pointer to storage for a type T and then calls CopyDataFromSymbol name with that T* and sizeof . I've got variants of this that work on Address as well as Symbol, and variants that will allocate a byte array of sizeof and copy the data in there. These wrappers are just convenience functions, but they made my life significantly easier.

A: Well, let's break this into two questions. First, will we add additional "convenience functions" to dbgeng.h that make the interface easier to use for many common extension tasks? Second, will those convenience functions utilize C++ templates (as opposed to macros, etc.)? The answer to both questions is: I don't know, but I'll pass this suggestion on to our developers.

Host: Brian (Microsoft)
Q: As com ports can no longer be taken for granted on some the new hardware platforms, what alternative connections are available for connecting a debugger to a target?

A: My particular favorite is 1394. It is *much* faster than serial ports, the only problem is that both the host and target must be running WinXP

Host: Larry (Microsoft)
A: (addendum to BrianC) ... or Windows Server 2003!

Host: Brian (Microsoft)
Another nice feature of 1394 is that you can have multiple targets on the same 1394 bus. A word or caution when using 1394: Don NOT have any 1394 disks on the same bus as a debug target

Host: Jamie (Microsoft)
Q: How do I specify the 1394 interface in the boot.ini?

A: It's in the doc. for example /debugport=1394 /channel=42 Then on the host, pick the 1394 tab in the kernel debugger dialog and specify the channel number.

Host: DHolcomb (Microsoft)
Q: As com ports can no longer be taken for granted on some the new hardware platforms, what alternative connections are available for connecting a debugger to a target?

A: Also, there are some known issues with 1394 where you have to disable the 1394 bus host controller (not the network adapter) on the target system.

Host: DHolcomb (Microsoft)
Q: Are there any new debugger features explicitly targeted for Windows 2003?

A: kdbgctrl.exe is the main debugger feature that received changes specific to Windows 2003. There are features there that enable you to control the dbgprint buffer size and control usermode exception handling. In Longhorn you will be able to extract a "triage" kernel dump from a live system by

Host: Brian (Microsoft)
Q: Wow! That's great for the multiple targets. Can I break all the targets simultaneously? Could be real handy for some distributed problems!

A: Sure, why not? Y=ou can have multiple instances of the debugger running, each of which is connected to a different target. Y=es, 1394 rocks!

Host: DHolcomb (Microsoft)
Q: If I start windbg with the -kl switch, is there any way I can save the memory dump for offline analysis without crashing the server?

A: No, but if you are using 1394 to live kernel debug the target, you can use .dump /f to create a full memory dump quickly. I have created 1GB dumps in less than two minutes. You just have to pause the target temporarily while you create the dump.

Host: Brian (Microsoft)
Q: The 1394 windbg interface has a bug where you have to disable the 1394 HC driver on the target system for the debugging to proceed consistently. Once the 1394 HC driver on the target system is disabled, 1394-based debugging should work fine. If you don't disable it, you will experience flaky debugger connection behavior.

A: This is mostly fixed in service pack 1, and it doesn't happen universally. For example, I've never had it happen to me

Host: Jamie (Microsoft)
Q: If I am have a dump in which I am out of non-paged pool memory, and pool taging was not enabled, what's the best way to find the who drained the nonpaged pool resource?

A: There isn't a trivial method. "Pool tags" still exist with tagging disabled, and are visible in things like !pool output, but getting a summary by tag requires pool tagging.

Host: Larry (Microsoft)
Q: Is there anyway that WinDbg will ever be changed to allow me to set breakpoints, and have those breakpoints work without breaking into my driver first? This is one thing the old WinDBG actually did quite well, and something I have been complaining about since version one, and something that every new person I show this debugger too complains about.

A: Two ways. First, you can use BU (instead of BP) to set your breakpoints -- these can be set before your driver is loaded. Second, if your driver is loaded and breakpoints are set, you can save your settings in a Workspace. Then next time you debug the same driver, the Workspace settings will be applied and you won't have to reset your breakpoints. See the docs for details on BU and details on Workspaces.

Host: Brian (Microsoft)
Q: Does someone know how I can recompile my driver and regenerate the new pdb file without having to exit the debugger first? It seems that once the debugger uses the pdb file, it will not allow a new version to be written to disk.

A: The ".reload /u drivername" command will unload the PDB file and allow you to rebuild your driver

Host: Larry (Microsoft)
Q: BU doesn't work for me consistently (even in the latest version) and isn't what is used by default by F9 for some reason?? Also, saving the workspace does not work at all.

A: If you are encountering bugs like this, you might want to contact PSS or post to the WinDbg newsgroup. However, it's also possible that the way workspaces come in so many layers is causing problems. You might try clearing your workspaces – all layers -- and starting over. Personally, I only use the "base workspace" to hold my default font and window size -- everything else goes into the target-specific workspaces.

Host: DHolcomb (Microsoft)
Q: Does someone know how I can recompile my driver and regenerate the new pdb file without having to exit the debugger first? It seems that once the debugger uses the pdb file, it will not allow a new version to be written to disk.

A: .reload /u will unload the loaded symbol then you can compile and .reload it again

Host: DHolcomb (Microsoft)
Q: @dholcomb\_MS Thanks, what I'm really looking for is a way to capture a kernel dump for offline analysis without forcing a server to crash (eg to analyze hung process situations). Would 1394 be the best way then?

A: Yes. When you break into the target you simply pause everything on the system. Take a .dump over 1394 and let everything continue with "g". Works like a charm.

Host: Brian (Microsoft)
Q: Also, does someone know how I can dump the device stack from the debugger, eg. KS -> AVStream -> USBAudio -> USBCCGP -> USBHub -> USBPort -> USBOhci -> PCI -> ACPI ->

A: Y=ou can use !devstack and !devnode to look at the device objects that are layered for a

Host: Brian (Microsoft)
Q: Is it possible to debug early stage of S3/S4 resume via 1394 debugging?

A: As far as I know, there is no difference in capabilities between 1394 vs. serial, so if you can do it with serial, you can do it with 1394

Host: DHolcomb (Microsoft)
Q: BU doesn't work for me consistently (even in the latest version) and isn't what is used by default by F9 for some reason?? Also, saving the workspace does not work at all.

A: I just confirmed that F9 does set bu breakpoints so they should get saved to workspaces. If you find that is not the case, please report the bug to windbgfb@microsoft.com.

Host: DHolcomb (Microsoft)
Q: I know that documentation is an ongoing task for the debugger team, but can you give a sense of the timeline you're looking at? Without docs the learning curve for these tools is very steep.

A: Can you be more clear what kind of information you feel you are missing from the docs?

Host: Larry (Microsoft)
Q: I know that documentation is an ongoing task for the debugger team, but can you give a sense of the timeline you're looking at? Without docs the learning curve for these tools is very steep.

A: First, anything I say here is a guess -- no guarantees! But hopefully this summer we'll have more short "techniques" and a lot more existing debugger extensions documented. Then possibly this Fall we'll have a whole new document explaining the debugger engine interface (dbgeng.h) and how to write debugger extensions.

Host: DHolcomb (Microsoft)
Q: Is USB-based debugging supported yet?

A: No. It is in the works. When it is supported, it will only work for USB 2.0.

Host: Adi (Microsoft)
Q: Thanks, what I'm really looking for is a way to capture a kernel dump for offline analysis without forcing a server to crash (eg to analyze hung process situations). Would 1394 be the best way then?

A: Today, I usually have a special script to analyze hung processes. The way that it works is the following:

A: (a) identify the PID of the processes using "tasklist /svc | findstr /i YourProcessName"

A: b) then run NTSD to create an quick dump and then immediately detach the debugger.

A: This command will create a dump and then exit: ntsd -p YourPID -cf dump_commands.txt

A: Where dump_commands.txt contains

A: .dump /mhuip /ba /u c:\dump_dir\mydump.cab

A: qd

Moderator:Eric S (Microsoft)
That's about all the time we have left for today's chat. Lets give our hosts our thanks and we'd like to thank you for your questions.

Moderator: Laura (Microsoft)
Microsoft.public.development.device.drivers, Microsoft.public.windbg, and Microsoft.public.windowsxp.winlogo.

Moderator: Laura (Microsoft)
Thanks for joining us today and thanks for the questions. It's time for us to go now.

Moderator: Laura (Microsoft)
Thank you all for hosting and attending!

For further information on this topic please visit the following:

Newsgroups:

Microsoft.public.development.device.drivers

Microsoft.public.windbg

Windows Drivers Transcripts: Read the archive

Website: Visit the Community Home Page for Windows Platform Development

Top of page