Remote Debugging, User and Kernel Mode

I'm setting up host and target machines for debugging both kernel mode code,
built with the DDK, and user mode code, built with Visual Studio. NET.

I'm planning to use the Visual Studio debugger for the User code. It appears
to support remote debugging, but I've never used it this way. My host-target
connection here will be via my ethernet LAN.

I plan to use Windbg for the driver code. I have a dedicated 1394 connection
for Windbg, which seem to work.

To you experienced developers, does this setup make sense?

Right now I'm concerned about making sure that the executables are always
up-to-date on the target, and that the symbols are always current.

Any tips for changing or using this setup would be appreciated.

I don't suppose I can use one debugger for both kernel and user mode, can I?

Thanks,
Dennis

Maxim
Tue Sep 21 19:10:02 CDT 2004

I know people who moved all user mode builds to BUILD/SOURCES too, so that
the whole product can be built by a single command.

Also WinDbg is by far better the VS's debugger even for user mode, though
it sometimes has problems finding sources and PDBs.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Dennis Burns" <dburns@rtessentials.com> wrote in message
news:OjxkPg9nEHA.1296@TK2MSFTNGP09.phx.gbl...
> I'm setting up host and target machines for debugging both kernel mode code,
> built with the DDK, and user mode code, built with Visual Studio. NET.
>
> I'm planning to use the Visual Studio debugger for the User code. It appears
> to support remote debugging, but I've never used it this way. My host-target
> connection here will be via my ethernet LAN.
>
> I plan to use Windbg for the driver code. I have a dedicated 1394 connection
> for Windbg, which seem to work.
>
> To you experienced developers, does this setup make sense?
>
> Right now I'm concerned about making sure that the executables are always
> up-to-date on the target, and that the symbols are always current.
>
> Any tips for changing or using this setup would be appreciated.
>
> I don't suppose I can use one debugger for both kernel and user mode, can I?
>
> Thanks,
> Dennis
>
>
>
>

Phil
Fri Sep 24 01:13:32 CDT 2004

"Dennis Burns" <dburns@rtessentials.com> wrote in message
news:OjxkPg9nEHA.1296@TK2MSFTNGP09.phx.gbl...
> I'm setting up host and target machines for debugging both kernel mode
code,
> built with the DDK, and user mode code, built with Visual Studio. NET.
>
> I'm planning to use the Visual Studio debugger for the User code. It
appears
> to support remote debugging, but I've never used it this way. My
host-target
> connection here will be via my ethernet LAN.

You can do this, but you will lose control if you break into the kernel for
any significant length of time. The VS remote debugger is easily broken
this way. You have to restart your VS IDE and remote process to get back to
where you were. Not highly productive when you are single-stepping through
your driver code.

> I plan to use Windbg for the driver code. I have a dedicated 1394
connection
> for Windbg, which seem to work.

You can use Windbg to debug your UM code in your kernel session. Gary
Little showed me that once, but I don't remember exactly where and when to
force the symbol reload that makes it work.

> To you experienced developers, does this setup make sense?

Not really.

> Right now I'm concerned about making sure that the executables are always
> up-to-date on the target, and that the symbols are always current.
>
> Any tips for changing or using this setup would be appreciated.

Use Windbg. Hope Gary or someone else chimes in with the proper procedure.

> I don't suppose I can use one debugger for both kernel and user mode, can
I?

Yes, see above.

Phil
--
Philip D. Barila Windows DDK MVP
Seagate Technology LLC
(720) 684-1842
As if I need to say it: Not speaking for Seagate.
E-mail address is pointed at a domain squatter. Use reply-to instead.

Mark
Thu Sep 30 06:38:51 CDT 2004

In article <OjxkPg9nEHA.1296@TK2MSFTNGP09.phx.gbl>, dburns@rtessentials.com
says...
> I'm setting up host and target machines for debugging both kernel mode code,
> built with the DDK, and user mode code, built with Visual Studio. NET.
>
> I'm planning to use the Visual Studio debugger for the User code. It appears
> to support remote debugging, but I've never used it this way. My host-target
> connection here will be via my ethernet LAN.
>
> I plan to use Windbg for the driver code. I have a dedicated 1394 connection
> for Windbg, which seem to work.
>
> To you experienced developers, does this setup make sense?
>

Sure. If you like using two debuggers. You have to understand that the UM
debugger will be non-functional while you are in a breakpoint in the KM
debugger, which seems obvious, but frequently isn't.

Remote debugging over enet works fine with the VS debugger. Plus if you are
using all of that .net stuff it is probably the only debugger that will be
fully useful.

> Right now I'm concerned about making sure that the executables are always
> up-to-date on the target, and that the symbols are always current.
>
> Any tips for changing or using this setup would be appreciated.
>
> I don't suppose I can use one debugger for both kernel and user mode, can I?
>
Well actually you can do that too, windbg also works fine for UM and doesn't
suffer from the disjoint 'in a kernel breakpoint oops I tried to do something
with the UM debugger and now its hung' problem. On the other hand windbg
doesn't know squat about c# and all that .net stuff.

Windbg's ability to locate symbols and sources is, in my opinion, far superior
to the VS stuff. That alone argues for one debugger to rule them all. On the
other hand I do the two debugger stuff all the time as the compile-test-fix
cycle is so easy inside VS.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
markr@hollistech.com