|
|
 |
|
 |
|
On Tue, 28 Apr 2009 10:28:53 -0400, "Don Burn" <...@stopspam.windrvr.com
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" <...@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
|
|
 |
|
 |
|
|
|
|
On Tue, 28 Apr 2009 11:56:47 -0700 (PDT), ranin02 <...@yahoo.com
Thanks for the reply. So you are saying I need to hardcode a
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" <...@stopspam.windrvr.com
|
|
|
|
|
|
|
|
|
On Tue, 28 Apr 2009 12:27:35 -0700, "Abhishek R [MSFT]" <...@online.microsoft.com
If you use ntsd or cdb, you can have it pipe the user-mode debugger output
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" <...@u39g2000pru.googlegroups.com...
>
|
|
|
|
|
|
|
|
|
On Tue, 28 Apr 2009 15:36:14 -0400, "Scott Noone" <...@osr.com
You can do it without a hardcoded breakpoint, you just need to make sure
you're in the correct process context.
For example, setting a breakpoint in CreateFileW in a process:
0: kd**** NT ACTIVE PROCESS DUMP ****
...
PROCESS 861c9d90 SessionId: 1 Cid: 0f10 Peb: 7ffd3000 ParentCid: 0b48
DirBase: 0174e2a0 ObjectTable: 96f14eb0 HandleCount: 5.
Image: testapp.exe
1: kdImplicit process is now 861c9d90
.cache forcedecodeuser done
Loading User Symbols
....
1: kdBreakpoint 0 hit
kernel32!CreateFileW:
001b:76fccc4e 8bff mov edi,edi
0: kd
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" <...@u39g2000pru.googlegroups.com...
Thanks for the reply. So you are saying I need to hardcode a
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" <...@stopspam.windrvr.com
|
|
|
|
|
|
|
|
|
On Tue, 28 Apr 2009 23:45:57 -0700, "Pavel Lebedinsky [MSFT]" <...@online.microsoft.com
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.
|
|
|
|
|
|
|