1

I've got virtual machine with VirtualKD drivers installed and attached to windbg running on the host machine.

So far I've managed to set breakpoints on user-space processes by switching to the desired process context in the following manner : 

# get procID      
!process 0 0 myproc.exe    

# use procID to switch context
.process /i <procID>

# continue till scheduler context switch to the desired process
g

# set break point on process' context (symbols should be visible)
...

the problem here is that the process must already be available (otherwise we won't be able to get its context).

Perhaps there's an easier way to state the process name in the breakpoint command with the ability to wait for the process to come up ?

EDIT :

Found out that with sxe ld myproc.exe I can get my breakpoint on process load .. However, in this stage, not all its libraries are loaded so I cannot set breakpoint on their method. Perhaps there's a way to get better notice when a library x.dll is being loaded in process myproc.exe ?

Zohar81
  • 4,554
  • 5
  • 29
  • 82
  • Why do you want to do this in kernel mode? – Thomas Weller Mar 13 '19 at 21:33
  • You could [`bu`](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/unresolved-breakpoints---bu-breakpoints-) if you have symbols. – Neitsa Mar 14 '19 at 07:29
  • @Neitsa, perhaps you can give me a usage example using `bu` to trigger breakpoint when process name `x.exe` attempt to load library `y.dll` whereas process `x.exe` still not exists. thanks ! – Zohar81 Mar 14 '19 at 09:14

1 Answers1

0

Put __debugbreak() into your code. Compile. Copy into VM. Run the exe with debugger attached. Once your code hit __debugbreak, it'll break you in windbg.

gehbiszumeis
  • 3,525
  • 4
  • 24
  • 41
Eiq
  • 45
  • 1
  • 7
  • This is a good method if you're debugging your own binary, but what happens if you want to debug `winword.exe` ? – shluvme Sep 01 '21 at 12:58