Some things to add on to that:
- server needs to be the first parameter (before -g -G)
- If you go the ‘-d’ route to re-direct I/O instead of -server,
it is helpful for the umode symbols to be on the target machine. A
‘.breakin’ will get you from the ntsd prompt to the kd prompt. And a
‘g’ after that will get you back to the umode ntsd prompt. However with
‘-d’, you lose the source debugging integration.
Jason
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis
Sent: Monday, August 15, 2005 3:15 PM
To: Kernel Debugging Interest List
Subject: RE: SPAM-LOW: [windbg] User mode debugging using Windbg in
kernel mode.
Oh, I forgot to mention. Windbg / ntsd / cdb all support quite good
remote
debugging. You can set up your service to run under the debugger, then
connect to it remotely. For example, if the path to your service binary
were d:\foo\foosvc.exe, then use the “Image File Execution Options”
registry
key, and set the Debugger value to whatever you want. Typically, it
would
look something like this:
[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution
Options\foosvc.exe]
Debugger = "d:\dbg\cdb.exe -g -G -server tcp:port=4000 "
Mind you, it’s been a while since I did this on a regular basis, so I
may
have goofed something. But the idea is that, whenever CreateProcess
tries
to start foosvc.exe, it will search the Image File Execution Options key
for
hints about how to start that process; usually, of course, there is no
key,
so CreateProcess uses the default behavior.
However, if there is a Debugger REG_SZ value, then CreateProcess
combines it
with the provided path, and executes that instead. That allows you to
inject your debugger. -g prevents the debugger from halting at process
start, and -G prevents the debugger from halting at process exit.
-server
tcp:port=4000 instructs the debugger to immediately open port 4000 for
remote debugging.
After that, on your debug host / dev machine, start “windbg -remote
tcp:port=4000,server=”. This connects your debugger to
the
remote machine. All source-level debugging, symbols, etc. should work.
(You may need to use .lsrcpath as a hint to your local debugger to
search
locally before searching remotely for source.)
Anyway, this situation works quite well, and is the “normal” way to do
it.
Using KD (or Windbg in kernel mode) will usually be a waste of time, if
what
you want is to debug a user-mode process. Of course, nothing stops you
from
doing both at the same time. That’s typically done if you want to debug
the
app that is calling your driver.
The nice thing about this approach is that it is very easy to toggle the
behavior – just rename the Debugger key to Debugger.x to remove your
debugger from the service start-up sequence. In order to make sure that
you
have this set up correctly, you may need to configure your service to
run as
LocalService, single-process, and interactive. This will let you verify
that the debugger is starting correctly. Also, investigate the
command-line
options for CDB. -d will redirect all user-mode OutputDebugString calls
to
the kernel debugger. You can also use a command file to control what
the
debugger does on specific exceptions; see the sxn, sxd, etc. debugger
instructions, and use -c "$<cmds.txt to read those on debugger startup.>
Sorry for the duplicate / repeated posts, and I hope this helps. Ye
olde
Google will yield lots of information on Image File Execution Options,
and
Debugger.chm will eventually yield its secrets, if you squint at it just
right.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Joe Stivaletta
Sent: Monday, August 15, 2005 5:35 PM
To: Kernel Debugging Interest List
Subject: SPAM-LOW: [windbg] User mode debugging using Windbg in kernel
mode.
I am a kernel developer and I don’t debug user mode very often. The
other
day I was debugging a kernel driver using a debug version of a user mode
service application. That service hit an assert that threw up a dialog
box
which gave me the option to debug it. When I selected that option I
had
full source level debugging of that service application. I was able to
set
breakpoints, etc. It was just like debugging the driver.
Now I am in a situation where I want to set breakpoints in that service
to
debug it using the same kernel mode setup I use to debug the kernel
code. I
have even added a DebugBreak() into the code. When it hits the
breakpoint
the source window does not open. Symbols are loaded and I can set break
points but those breakpoints are not hit at all.
I am baffled. Since the debugger worked as expected in the previous
experience when it actually hit an assert, why am I having such a
problem to
regain that state? Should I replace the DebugBreak() and force a a
break
with an Assert? I feel as though there is some hidden flag that is in
the
debugger that is set by the assert code that was keeping the kernel
debugger
in a user debugger mode and inserting the breakpoints correctly. Anyone
have any ideas on this behavior? I am trying to avoid having to install
a
duplicate build on my target just to run the debugger with the user mode
service.
Also the code I want to look at in the service executes before I can
even
login to the session anyway. I have tried using the ntsd remote
debugging
procedure for services with little success. I have even used the !ubp
extensions in this ntsd remote debugging environment but I cannot get
the
breakpoints to stick.
Best Regards,
Joe
—
You are currently subscribed to windbg as: xxxxx@stonestreetone.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: xxxxx@winse.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</cmds.txt>