debugging user mode code with windbg in kd session
ranin02
debug something in a DLL client of my kernel driver and would like to
do it within the same windbg session as I am using to debug the kernel
driver with kd. However, despite adding the source and symbols to the
workspace path it doesn't seem to properly set or stop at breakpoints
in the dll code. Is there some trick to it? Or do I have to debug the
DLL in a separate windbg session using the user mode debugger? Back
in the day, I recall doing this effortlessly with softice...
Thanks,
Sherri
Don Burn
routine, this will force a breakpoint into WinDbg at which point you can
then set other breakpoints and debug nomally. A little kludgy but it works.
--
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"ranin02" <ran...@yahoo.com> wrote in message
news:813bdb29-1605-4a71...@i28g2000prd.googlegroups.com...
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4039 (20090428) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4039 (20090428) __________
The message was checked by ESET NOD32 Antivirus.
ranin02
DebugBreak in the DLL code -- there is no way to do it without
actually editing the code?
Thanks,
Sherri
On Apr 28, 10:28 am, "Don Burn" <b...@stopspam.windrvr.com> wrote:
> You can do it, the simplest approach is to put a breakpoint in the DllMain
> routine, this will force a breakpoint into WinDbg at which point you can
> then set other breakpoints and debug nomally. A little kludgy but it works.
>
> --
> Don Burn (MVP, Windows DDK)
> Windows Filesystem and Driver Consulting
> Website:http://www.windrvr.com
> Blog:http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> "ranin02" <rani...@yahoo.com> wrote in message
>
> news:813bdb29-1605-4a71...@i28g2000prd.googlegroups.com...
>
>
>
>
>
> > Is it possible to debug user mode code in a kd session? I want to
> > debug something in a DLL client of my kernel driver and would like to
> > do it within the same windbg session as I am using to debug the kernel
> > driver with kd. However, despite adding the source and symbols to the
> > workspace path it doesn't seem to properly set or stop at breakpoints
> > in the dll code. Is there some trick to it? Or do I have to debug the
> > DLL in a separate windbg session using the user mode debugger? Back
> > in the day, I recall doing this effortlessly with softice...
>
> > Thanks,
> > Sherri
>
> > __________ Information from ESET NOD32 Antivirus, version of virus
> > signature database 4039 (20090428) __________
>
> > The message was checked by ESET NOD32 Antivirus.
>
> >http://www.eset.com
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4039 (20090428) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com- Hide quoted text -
>
> - Show quoted text -
Abhishek R [MSFT]
to the kernel debugger. You can also switch between user-mode debugging and
kernel-mode debugging within the debugger session.
http://msdn.microsoft.com/en-us/library/cc266367.aspx
With WinDBG, another thing you can do is use !bpid to have the kernel
debugger break into the context of the process you're interested in and then
you can set your breakpoints in the user-mode code (after running .reload to
reload your symbols). Please keep in mind that !bpid has to un-freeze the
target computer in order to break into the process you specify. Therefore
the state of the machine can change while !bpid is running. Therefore it may
not be useful in all situations.
http://msdn.microsoft.com/en-us/library/cc266996.aspx
"ranin02" <ran...@yahoo.com> wrote in message
news:2c958c5b-5bb2-4a58...@u39g2000pru.googlegroups.com...
Scott Noone
you're in the correct process context.
For example, setting a breakpoint in CreateFileW in a process:
0: kd> !process 0 0
**** NT ACTIVE PROCESS DUMP ****
...
PROCESS 861c9d90 SessionId: 1 Cid: 0f10 Peb: 7ffd3000 ParentCid: 0b48
DirBase: 0174e2a0 ObjectTable: 96f14eb0 HandleCount: 5.
Image: testapp.exe
1: kd> .process /r /p 861c9d90
Implicit process is now 861c9d90
.cache forcedecodeuser done
Loading User Symbols
....
1: kd> bp kernel32!createfilew
Breakpoint 0 hit
kernel32!CreateFileW:
001b:76fccc4e 8bff mov edi,edi
0: kd> kc
kernel32!CreateFileW
testapp!wmain
testapp!__wmainCRTStartup
kernel32!BaseThreadInitThunk
ntdll!__RtlUserThreadStart
ntdll!_RtlUserThreadStart
Once you're broken in and in the correct context you can set breakpoints
with the GUI. Trying to set the breakpoints with the GUI first is mostly a
fruitless exercise.
After all that, it's usually easier to just put the __debugbreak() in.
-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
"ranin02" <ran...@yahoo.com> wrote in message
news:2c958c5b-5bb2-4a58...@u39g2000pru.googlegroups.com...
Pavel Lebedinsky [MSFT]
> you're in the correct process context.
>
> For example, setting a breakpoint in CreateFileW in a process:
>
This only works if kernel32 happens to be mapped in the current context.
To reliably set user mode breakpoints from kd you should use .process /i
(instead of /p).
--
Pavel Lebedinsky/Windows Kernel Test
This posting is provided "AS IS" with no warranties, and confers no rights.
amor...@ieee.org
Do you have a pressing need to use kd on a user program ? I may be
wrong, but I find the Visual Studio debugger way more efficient for
user-side debugging. You can run the VS debugger on the target
machine, and let kd handle the kernel-side issues from the host
machine.
Until Microsoft gives us a higher level of integration between Windbg
and VS.NET, you can use the VS Tools menu to achieve a mild level of
integration. You can go Tools, External Tools, and you get a dialog
box to add an external tool. Click add, fill in the blanks with the
location of your Windbg executable, initial parameters, etc., and you
can run Windbg from inside VS.NET. In fact, you can add more than one
entry if you have more than one target machine: for example, I have
two target systems on my host, connected through two Firewire cables.
One of them runs Windbg on 1394 channel 44 and the other on 1394
channel 46, which allows me to have one or more VS.NET running while
one or two Windbg sessions are also open.
I use that setup to debug my test applications. One other advantage is
that I get very nice managed code debugging. Some of the test applets
I wrote are written in C# using Windows Forms and the visual editor,
and I'm not sure if I can do much IL level debugging with Windbg.
Hope this helps! If not, toss it.
Alberto.
ranin02
Sherri