Old nugget of information here, but useful to remember when the situation arises…
When debugging in kd, a reboot will wipe out your breakpoints. The break-in instruction gets replaced on OS reboot because everything is initializing from scratch, and the external debugger is not designed to be in the OS startup path. I sometimes forget this, and wonder why my breakpoints are not getting hit.
To solve this, I get in the habit of setting the debugger to break on the next boot. In windbg, this can be accomplished with the control+alt+k keystroke. Upon break in due to this debugger directive, you can then set your breakpoints again.
It is similar with user mode breakpoints when viewed from kd. When the process goes down, any user mode breakpoints that you have set go away as the memory that backed them is released back to the OS. When a new instance of the process comes up, you have to jump into the new process and set up the user mode breakpoints again. However, there is no control+alt+k in this case. You have to break in at process creation time and filter by process name. Unfortunately, the symbol that identifies the process name is a private symbol and is not exposed to devs outside of Microsoft. There is no simple solution for folks outside of Microsoft.
Solving problems from a kernel mode perspective is different as compared to the traditional user mode approach.