How to Debug userMode App and Driver using a same Windbg instance

Hi

I have a DLL as well as a kernel mode driver running on the target system.
Please tell me how to debug both of them using the same windbg (running on the host system)

Currently I’m debugging by running two windbgs.

  1. One is running on the target system to debug the DLL (by selecting open executeable) the only problem is I have to copy all the sources and PDB files into the target system.

  2. And another is running on the Host system like a regualr driver windbg. conntection is thru 1394.

I tried this, running NTSD -d appname on the target side, but look like it required the symbol and src files on the target system. I would like to keep my src and symbol files on the host system.

This is not one of WinDbg’s finer qualities - debugging user and kernel modes at the same time. In my opinion, were it not for the
fact that there really isn’t any other choice now, with the demise of SoftICE (which was excellent at this, but had it’s own large
set of problems), I would call it painful. If that’s what you need, you might wish to check out this:

http://msdn.microsoft.com/en-us/library/cc266367.aspx

That being said, it sounds like you are primarily interested in just consolidating on to the host, but would be OK with running two
instances of WinDbg on the host. I can’t say that I’ve ever tried this, but I would imagine that it at least wouldn’t be any worse
than dealing with ‘.breakin’ and the other user mode from kernel mode features of WinDbg, assuming that the user mode instance of
WinDbg doesn’t timeout or whatnot when the machine is halted when the kernel debugger breaks in; I haven’t any idea of whether this
will be a problem or not. So, if this all works, I think all you would need to do is use WinDbg remotely in user mode:

http://msdn.microsoft.com/en-us/library/cc266427.aspx

Under this scenario, the symbols may be on the host.

Although learning WinDbg was a truly miserable process, made so very much more the miserable by the abjectly horrendous
documentation, overall, I am a much, much happier boy since switching to WinDbg from SoftICE about four years ago. SoftICE did
however have it’s good points, and I do miss it for attacking three specific problems (this one, and the other two are remote kernel
debugging over Ethernet and problems involving some types of anti-debugging technologies like recurring int 1 (think Symantec)),
with debugging user and kernel modes simultaneously - especially the transition between rings - being the major gap in WinDbg’s
otherwise very superior abilities, the documentation very much withstanding.

Good luck,

mm

xxxxx@yahoo.com wrote:

Hi

I have a DLL as well as a kernel mode driver running on the target system.
Please tell me how to debug both of them using the same windbg (running on the host system)

Currently I’m debugging by running two windbgs.

  1. One is running on the target system to debug the DLL (by selecting open executeable) the only problem is I have to copy all the sources and PDB files into the target system.

  2. And another is running on the Host system like a regualr driver windbg. conntection is thru 1394.

I tried this, running NTSD -d appname on the target side, but look like it required the symbol and src files on the target system. I would like to keep my src and symbol files on the host system.

Thanks MM. Already I went through those steps. It requires symbols to be in the target system.

I generally do this with two remote debuggers - one windbg kernel session
and typically a remote vs debug session. The arrangement works pretty well.
I have rarely gotten windbg to even produce a complete stack trace from
kernel to user mode, and I don’t think you can set user mode breakpoints
from kernel mode at all.

On Wed, May 7, 2008 at 11:04 PM, wrote:

> Hi
>
> I have a DLL as well as a kernel mode driver running on the target system.
> Please tell me how to debug both of them using the same windbg (running on
> the host system)
>
> Currently I’m debugging by running two windbgs.
> 1. One is running on the target system to debug the DLL (by selecting open
> executeable) the only problem is I have to copy all the sources and PDB
> files into the target system.
>
> 2. And another is running on the Host system like a regualr driver windbg.
> conntection is thru 1394.
>
> I tried this, running NTSD -d appname on the target side, but look like it
> required the symbol and src files on the target system. I would like to keep
> my src and symbol files on the host system.
>
>
>
>
> —
> NTDEV 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
>


Mark Roddy

> kernel to user mode, and I don’t think you can set user mode breakpoints

from kernel mode at all.

Can !ubp help?


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

> I don’t think you can set user mode breakpoints

from kernel mode at all.
You certainly can.

I usually go up the stack in some CREATE, for example, and set a
bp in a UM caller, no problems.

This means that windbg takes care of a um/km thread context switch.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-323878-
xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Saturday, May 10, 2008 7:06 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to Debug userMode App and Driver using a same
Windbg instance

> kernel to user mode, and I don’t think you can set user mode
breakpoints
> from kernel mode at all.

Can !ubp help?


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


NTDEV 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

Well I certainly admit to having not tried this in years, but the last time
I tried (years ago) it simply did not work. I’ll take your word for it.

On Sat, May 10, 2008 at 8:03 AM, Alex Shvedov wrote:

> > I don’t think you can set user mode breakpoints
> > from kernel mode at all.
> You certainly can.
>
> I usually go up the stack in some CREATE, for example, and set a
> bp in a UM caller, no problems.
>
> This means that windbg takes care of a um/km thread context switch.
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:bounce-323878-
> > xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> > Sent: Saturday, May 10, 2008 7:06 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] How to Debug userMode App and Driver using a same
> > Windbg instance
> >
> > > kernel to user mode, and I don’t think you can set user mode
> > breakpoints
> > > from kernel mode at all.
> >
> > Can !ubp help?
> >
> > –
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > NTDEV 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
>
>
> —
> NTDEV 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
>


Mark Roddy

I’ve used WinDbg for this type of dual mode setup, and strictly speaking it did work, but the whole thing still sucked a whole
bunch, at least for (at the time) a new WinDbg user coming from SoftICE which had very natural support for this, as well its own set
of problems and what I would come to see as a crippled feature set, but that would take a while. This was actually either the first
or very close to the first thing I set out to do with WinDbg, beyond getting it connected, supporting symbols and so forth, which in
retrospect was a terrible decision, though still quite a bit better than choosing the floppy drive as the device for my first driver
for an actual device. While the reasons for choosing the later still make sense to me (documented/understood hardware; source code
to look at if necessary; non-critical device; could be reloaded without rebooting), when I think about the suffering involved in
getting things like the timing to work, I quickly become convinced that there just had to be a better choice, or at least I hope so,
but this was in the waning days of NT4, just before 2000 was released.

Speaking of NT4, Mark, is that the last time you tried the user breakpoint thing? I noticed this in the documentation not all that
long ago, and I don’t remember it being there maybe two three releases ago, but I may by totally wrong about that.

‘Note A kernel debugger cannot set breakpoints in user space if the target computer is running Microsoft Windows NT 4.0.’

It took me a while, but I eventually ended up doing the same thing that it sounds like Alex does, which I think is less irritating
than an issuing ‘.process /i;g’ but it’s still inconvenient. Whenever I used to do this, I would find myself briefly missing. It’s
no longer an issue, because these days I handle the situation by responding to inquiries for work that will involve using WinDbg
like this by answering all questions asked by speaking of complicated yet stubbornly subtle issues that don’t lend themselves to
easy description to the layman, and in very short order, the requesters go away. Actually, I do this for most anything that comes
before me involving user mode, and I find it works quite well, and since it seems like most of the time when I tell people that
something will take longer than they want it to take, they tell me I’m being difficult and making things to complicated, so I figure
I might as well situationally capitalize on my flaws, especially if I am going to accrue the damage either way.

Cheers,

mm

Mark Roddy wrote:

Well I certainly admit to having not tried this in years, but the last
time I tried (years ago) it simply did not work. I’ll take your word for it.

On Sat, May 10, 2008 at 8:03 AM, Alex Shvedov > mailto:xxxxx> wrote:
>
> > I don’t think you can set user mode breakpoints
> > from kernel mode at all.
> You certainly can.
>
> I usually go up the stack in some CREATE, for example, and set a
> bp in a UM caller, no problems.
>
> This means that windbg takes care of a um/km thread context switch.
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> mailto:xxxxx [mailto:bounce-323878-
> mailto:bounce-323878-
> > xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of
> Maxim S. Shatskih
> > Sent: Saturday, May 10, 2008 7:06 AM
> > To: Windows System Software Devs Interest List
> > Subject: Re:[ntdev] How to Debug userMode App and Driver using a same
> > Windbg instance
> >
> > > kernel to user mode, and I don’t think you can set user mode
> > breakpoints
> > > from kernel mode at all.
> >
> > Can !ubp help?
> >
> > –
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com mailto:xxxxx
> > http://www.storagecraft.com http:</http:>
> >
> >
> > —
> > NTDEV 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
>
>
> —
> NTDEV 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
>
>
>
>
> –
> Mark Roddy</mailto:xxxxx></mailto:xxxxx></mailto:bounce-323878-></mailto:xxxxx></mailto:xxxxx>

> I eventually ended up doing the same thing that it sounds like

Alex does, which I think is less irritating than an issuing
‘.process /i;g’ but it’s still inconvenient.
Note that I did not say that it is the convenient way to debug
in UM…

However sometimes it is very handy: you have mydrv.sys and
test_mydrv.exe, the latter sends a whole bunch of various
ioctls, you hit a bp in the sys and would like to know what
the hell test_mydrv wants to do this time.

Goes w/o saying, symbol and target paths must be set to
both bins.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-323901-
xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Saturday, May 10, 2008 3:01 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to Debug userMode App and Driver using a same
Windbg instance

I’ve used WinDbg for this type of dual mode setup, and strictly
speaking it did work, but the whole thing still sucked a whole
bunch, at least for (at the time) a new WinDbg user coming from SoftICE
which had very natural support for this, as well its own set
of problems and what I would come to see as a crippled feature set, but
that would take a while. This was actually either the first
or very close to the first thing I set out to do with WinDbg, beyond
getting it connected, supporting symbols and so forth, which in
retrospect was a terrible decision, though still quite a bit better
than choosing the floppy drive as the device for my first driver
for an actual device. While the reasons for choosing the later still
make sense to me (documented/understood hardware; source code
to look at if necessary; non-critical device; could be reloaded without
rebooting), when I think about the suffering involved in
getting things like the timing to work, I quickly become convinced that
there just had to be a better choice, or at least I hope so,
but this was in the waning days of NT4, just before 2000 was released.

Speaking of NT4, Mark, is that the last time you tried the user
breakpoint thing? I noticed this in the documentation not all that
long ago, and I don’t remember it being there maybe two three releases
ago, but I may by totally wrong about that.

‘Note A kernel debugger cannot set breakpoints in user space if the
target computer is running Microsoft Windows NT 4.0.’

It took me a while, but I eventually ended up doing the same thing that
it sounds like Alex does, which I think is less irritating
than an issuing ‘.process /i;g’ but it’s still inconvenient. Whenever
I used to do this, I would find myself briefly missing. It’s
no longer an issue, because these days I handle the situation by
responding to inquiries for work that will involve using WinDbg
like this by answering all questions asked by speaking of complicated
yet stubbornly subtle issues that don’t lend themselves to
easy description to the layman, and in very short order, the requesters
go away. Actually, I do this for most anything that comes
before me involving user mode, and I find it works quite well, and
since it seems like most of the time when I tell people that
something will take longer than they want it to take, they tell me I’m
being difficult and making things to complicated, so I figure
I might as well situationally capitalize on my flaws, especially if I
am going to accrue the damage either way.

Cheers,

mm

Mark Roddy wrote:
> Well I certainly admit to having not tried this in years, but the
last
> time I tried (years ago) it simply did not work. I’ll take your word
for it.
>
> On Sat, May 10, 2008 at 8:03 AM, Alex Shvedov > > mailto:xxxxx> wrote:
> >
> > > I don’t think you can set user mode breakpoints
> > > from kernel mode at all.
> > You certainly can.
> >
> > I usually go up the stack in some CREATE, for example, and set a
> > bp in a UM caller, no problems.
> >
> > This means that windbg takes care of a um/km thread context
> switch.
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@lists.osr.com
> > mailto:xxxxx [mailto:bounce-323878-
> > mailto:bounce-323878-
> > > xxxxx@lists.osr.com mailto:xxxxx] On Behalf Of
> > Maxim S. Shatskih
> > > Sent: Saturday, May 10, 2008 7:06 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: Re:[ntdev] How to Debug userMode App and Driver using
> a same
> > > Windbg instance
> > >
> > > > kernel to user mode, and I don’t think you can set user mode
> > > breakpoints
> > > > from kernel mode at all.
> > >
> > > Can !ubp help?
> > >
> > > –
> > > Maxim Shatskih, Windows DDK MVP
> > > StorageCraft Corporation
> > > xxxxx@storagecraft.com mailto:xxxxx
> > > http://www.storagecraft.com http:</http:>
> > >
> > >
> > > —
> > > NTDEV 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
> >
> >
> > —
> > NTDEV 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
> >
> >
> >
> >
> > –
> > Mark Roddy
>
> —
> NTDEV 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</mailto:xxxxx></mailto:xxxxx></mailto:bounce-323878-></mailto:xxxxx></mailto:xxxxx>

It works fine, I just need to put a break point in driver first and once hit the break point I went to the call stack. There I saw my application function entries, then I double clicked the entry and put a break point. It works just fine. No special break points required. The Windbg switches the usermode to kernel mode with no problem. The only thing is you have to put a break first in driver and then come to application.

Now I can debug driver as well as app in the same windbg. I’m so happy you guys helped me on this. Thank you very much.

I participated, I don’t know if I helped, but either way, I’m glad it worked out for you.

Cheers,

mm

xxxxx@yahoo.com wrote:

It works fine, I just need to put a break point in driver first and once hit the break point I went to the call stack. There I saw my application function entries, then I double clicked the entry and put a break point. It works just fine. No special break points required. The Windbg switches the usermode to kernel mode with no problem. The only thing is you have to put a break first in driver and then come to application.

Now I can debug driver as well as app in the same windbg. I’m so happy you guys helped me on this. Thank you very much.