This is my first time to debug a kernel driver remotely and I’m stuck. The target is running Vista SP1 (Retail). It is connected to the host (XP SP2) with a 1394 cablle. On the target I have run “bcdedit /dbgsettings 1394 CHANNEL:44” and booted with the “Enable Debugging” option. The “kdbgctrl -e” command reports that debugging is already enabled. On the host side, I launch windbg and select File->Kernel Debug, choose the 1394 tab and specify channel 44. At that point, I get a flurry of messages indicating that Channel 44 is now open and then it hangs with a “waiting to reconnect…” message.
Can someone either spot what I’m missing or point me to another “how-to” source? Do I need a “checked OS” installed on the target?
Welcome.
I think that it’s possible that all you need to do at this point it to (in windbg) either take ‘Break’ from the ‘Debug’ menu or press ‘ctrl-break.’
Until you tell windbg to break in, it will just sit there, unless something exceptional happens on the target.
Although what you’re doing with ‘Enable Debugging’ will work,if you want, you can avoid this step by enabling debugging with bcdedit:
bcdedit /set debug on
You do not need to install the CHK build at this point, and I would personally not recommend installing it at this point. Once you get windbg working, what might me a good idea to look in to is installing a partial CHK build. See the windbg docs for the details, but, again, I’d get windbg working first.
Finally, a small note about terminology. What you’re trying to do with windbg really is not ‘remote’
debugging. It’s kernel debugging. The only reason that this matters is that ‘remote debugging’ is something else you can with windbg, and it can take maybe ten forms itself, so the terminology around windbg gets very confusing, very quickly, and it helps people on these lists if you use it consistently, especially because pretty much all the standard terms for a two machine setup - remote, client, server, host, target and many more - all have already been assigned windbg specific meanings, and they’re not always exactly crystal clear.
Good luck,
mm
Thanks! I’ll give that a go Monday morning. I was using “remote” to
distinguish from running WinDbg on the target machine itself, which I
understand is possible. But since what I’m trying to resolve is a BSOD
issue, it seemed better to be running the debugger on a separate box.
xxxxx@evitechnology.com wrote:
Welcome.
I think that it’s possible that all you need to do at this point it to (in windbg) either take ‘Break’ from the ‘Debug’ menu or press ‘ctrl-break.’
Until you tell windbg to break in, it will just sit there, unless something exceptional happens on the target.
Although what you’re doing with ‘Enable Debugging’ will work,if you want, you can avoid this step by enabling debugging with bcdedit:
bcdedit /set debug on
You do not need to install the CHK build at this point, and I would personally not recommend installing it at this point. Once you get windbg working, what might me a good idea to look in to is installing a partial CHK build. See the windbg docs for the details, but, again, I’d get windbg working first.
Finally, a small note about terminology. What you’re trying to do with windbg really is not ‘remote’
debugging. It’s kernel debugging. The only reason that this matters is that ‘remote debugging’ is something else you can with windbg, and it can take maybe ten forms itself, so the terminology around windbg gets very confusing, very quickly, and it helps people on these lists if you use it consistently, especially because pretty much all the standard terms for a two machine setup - remote, client, server, host, target and many more - all have already been assigned windbg specific meanings, and they’re not always exactly crystal clear.
Good luck,
mm
WINDBG is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
.
–
Daryl Lee
Principle Software Engineer
Novint Technologies
It is indeed necessary to use a two machine setup.
The one machine setup you were referring to (not very useful for general debugging) is called ‘local kernel debugging,’ so I can see why ‘remote’ seems reasonable, but no one ever said that the windbg docs are reasonable.
Good luck,
mm
Thanks, that seems to have opened up the door into a mysterious new world.
Now there’s a LOT to learn!
Daryl Lee
Principal Software Engineer
Novint Technologies, Inc.
xxxxx@evitechnology.com wrote:
Welcome.
I think that it’s possible that all you need to do at this point it to (in windbg) either take ‘Break’ from the ‘Debug’ menu or press ‘ctrl-break.’
Until you tell windbg to break in, it will just sit there, unless something exceptional happens on the target.
Although what you’re doing with ‘Enable Debugging’ will work,if you want, you can avoid this step by enabling debugging with bcdedit:
bcdedit /set debug on
You do not need to install the CHK build at this point, and I would personally not recommend installing it at this point. Once you get windbg working, what might me a good idea to look in to is installing a partial CHK build. See the windbg docs for the details, but, again, I’d get windbg working first.
Finally, a small note about terminology. What you’re trying to do with windbg really is not ‘remote’
debugging. It’s kernel debugging. The only reason that this matters is that ‘remote debugging’ is something else you can with windbg, and it can take maybe ten forms itself, so the terminology around windbg gets very confusing, very quickly, and it helps people on these lists if you use it consistently, especially because pretty much all the standard terms for a two machine setup - remote, client, server, host, target and many more - all have already been assigned windbg specific meanings, and they’re not always exactly crystal clear.
Good luck,
mm
WINDBG is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
.
Thanks to all your help, I am at the point where I can set breakpoints and actually hit them. I finally feel like I’m gaining control. Now I’m trying to figure out the next big item.
I have a lot of DbgPrint (actually DebugPrint, with the macro defined as shown below) statements scattered throughout my code, but I’m seeing none of them in the debugger. Is there something I’m supposed to do to enable output?
This is the macro that makes DebugPrint disappear in free builds and do DbgPrint in checked:
#if DBG
#define DebugPrint(x) { DbgPrint (“VHIDMINI:”); DbgPrint x; }
#else
#define DebugPrint(x)
#endif
I’ve inspected the build log, and the cl command includes the directive “/DDBG=1”. Surely there’s something I’m missing?
If you’re target is running Vista or newer, then you’ll need to enable the output of default trace statements:
WINDBG:
ed nt!Kd_DEFAULT_Mask 0x0F
There’s a way to do it in the registry as well, but I don’t recall it exactly. There’s an article on www.osronline.com that tells you how to, and it’s also in the the windbg docs under ‘DbgPrint.’
If you’d like to make things complicated, you can also read about DbgPrintEx and do it that way as well.
Good luck,
mm
Thanks! Actually, I finally found the registry recipe by searching on “DbgPrint” instead of “DebugPrint”. It’s working now and I think I’m in pretty good shape.