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