2

I'm having trouble getting user mode breakpoints to hit in windbg when I am kernel debugging. I know that I have to be in the target process's context to set a user mode breakpoint, but that still doesn't seem to work reliably. Sometimes it works, but I can't wrap my head around what the variable is that is making it work sometimes but not others. Here is what I am doing.

1) !process <process> 0x17, then find a thread that I am curious 
   about.  See that the thread is in mixed user/kernel callstack, 
   identify return address I want to break on.

2) .process /r /p <process>, to change to the target process context

3) .thread <thread>, to change to the thread identified in step (1)

4) bp <addr>, to break on that particular address I care about

5) g

Sometimes the breakpoint hits. Sometimes it doesn't (except I have evidence that the thread has returned). This makes debugging really frustrating since I never know if things will work. Thanks for your help.

EDIT: this is not about thread-specific breakpoints, in my example I only change thread to take a callstack, because the callstack shows me the address I need to break on. In reality I want to break whenever that address is hit.

R. Alabaster
  • 53
  • 3

1 Answers1

0

being in process context helps decipher virtual address.

I don't recall being in context guarentees process or thread specific breaks.

use bp /p eprocess address syntax to set process specific breakpoints

although i havent used i recall there are thread specific bps witj bp /t ethread address refer the docs

blabb
  • 7,524
  • 1
  • 14
  • 23