How do Managed Breakpoints work?

re: How do Managed Breakpoints work?

Pavel Lebedinsky — Wed, 29 Dec 2004 09:29:00 GMT

Why is the auxillary buffer necessary? Couldn't the helper thread keep all the other threads suspended until the current thread has executed the initial single-step after the breakpoint?

re: How do Managed Breakpoints work?

jwf — Wed, 29 Dec 2004 18:15:00 GMT

So why does Visual Studio 2003 hang occasionally when "stepping" through a mixed managed/unmanaged debugging session?

This is the single most frustrating aspect of trying to develop new parts of our smart client applications in managed code while integrating with a huge unmanaged code base that has a ton of UI.

re: How do Managed Breakpoints work?

Mike Stall — Wed, 29 Dec 2004 20:16:00 GMT

Pavel - interesting idea, but there's a problem. Somehow you need to execute the opcode underneath the breakpoint opcode (int3). You can either:
1) temporarily remove the breakpoint and restore the original opcode. Single step to execute the opcode and then put the breakpoint back in.
2) use an auxillary buffer (as described above).

The problem with #1 is from multi-threaded scenarios. If the other threads are not suspended, then they may race through the breakpoint while we have it removed.
If they are suspended, then we may deadlock if that single opcode we're stepping over blocks on another thread for some reasons (perhaps it's a system call).

re: How do Managed Breakpoints work?

Mike Stall — Wed, 29 Dec 2004 20:21:00 GMT

jwf - that's because interop-debugging in v1.1 / VS 2003 is just really unstable in general.
In some hangs I've diagnosed, I've counted at least 7 different races that could cause it. There could be 100 reasons why your scenario is hanging.

FWIW, There was large debate over whether to cut it completely or ship a half working feature that may still provide some value in some cases.

On the good side, we've spent a lot of resources in v2.0 trying to stabalize interop-debugging and we believe it's a lot better. Check out VS2005 beta 1 and let us know if you still see such hangs (at least use Watson to report them).

re: How do Managed Breakpoints work?

Nicholas Allen — Thu, 30 Dec 2004 05:52:00 GMT

I'm having a little trouble figuring out the mechanics of step 10. If the SEH is injected before running managed code, isn't it possible for someone to add another SEH and be farther up the stack, possibly grabbing the breakpoint exception before Left-Side can see it? And couldn't a vectored exception handler steal the exception as well before you get it?

Or am I misinterpreting this and the hardware exception has already been converted to a managed exception? In which case, why aren't other managed handlers exposed to this exception before it hits your filter?

I would have thought this would be handled by Right-Side where the debugger can handle the exception before the debuggee even gets to see it. And then communicate to Left-Side that a breakpoint has been hit to stop threads. But I'm guessing there's a reason this is all done in Left-Side.

re: How do Managed Breakpoints work?

Mike Stall — Thu, 30 Dec 2004 08:02:00 GMT

Nicholas - sorry, #10 is poorly worded. You bring up great points:

Your interpretation is correct. So:
1) The SEH filter is already injected before the managed code is ever run by the CLR's EH subsystem.
2) The CLR's EH subsystem also owns the vectored exception handler. If you override it, you'll break things.

3) While in managed code, only the CLR's EH subsystem can add SEH filters, so it's not possible for someone to add another SEH to intercept us.

4) The CLR's EH subsystem then cooperates heavily with the CLR's debugging subsystem. It gives the debugging system first shot at all SEH exceptions with code=0x80000003 (breakpoint) or 0x80000004 (single-step)

Your last sentence is a great observation.
This is all done in the Left-side (the portion in-process w/ the debuggee) because managed-only debugging is actually not OS-debugging, and so the RS won't even get notified of the exceptions.
When interop-debugging (both managed & native debugging simultaneously), the RS is also an OS-debugger and so it will then get notified of the exception's via native debug events. In these cases, it detects the exceptions are meant for the CLR and then resumes the process to let the in-process filters handle them. This is done so that interop and managed-only share a lot of the same logic.

re: How do Managed Breakpoints work?

Nicholas Allen — Thu, 30 Dec 2004 21:15:00 GMT

Thank you. I think I understand it now.

The CLR requires that it controls the OS exception handlers (structured and vectored) for things to work. When the exception is hit, Right-Side ignores it (or never sees it depending on whether you're doing managed or interop) and lets Left-Side pick it up. Left-Side will always have the first chance because it is the handler of choice for the OS. Left-Side first gives it to the debugging exception filter (which acts like a vectored handler). If it is a debugging related exception, we continue with the algorithm above. Otherwise the debugging filter declines the exception and Left-Side then gives it to the managed structured handler to try.

One consequence of handling all exceptions in-process is that we have extra transitions between Left-Side and Right-Side when doing interop debugging.

RS (hit exception, decline) -> LS (hit exception, accept) -> RS (notify of exception) -> LS (suspend debuggee) -> RS (run debugger)

If we took the native exception it would look like

RS (hit exception, accept) -> LS (suspend debuggee) -> RS (run debugger)

Manged debugging always goes

LS (hit exception, accept) -> RS (notify of exception) -> LS (suspend debuggee) -> RS (run debugger)

re: How do Managed Breakpoints work?

Mike Stall — Thu, 30 Dec 2004 22:43:00 GMT

That's 99% correct.

Your last sentence is technically wrong. For managed debugging, the RS never sees the raw exception (0x80000003), it only sees the higher level managed debug events (like "Breakpoint"). So your last sentence should be:
Managed debugging always goes:
LS (hit exception, accept) -> RS (queue managed debug event) -> LS (suspend debuggee) -> RS (dispatch debug events) --> User responds --> RS(run debuggee)

Blog link of the week 53

Daniel Moth — Mon, 03 Jan 2005 02:59:00 GMT

Blog link of the week 53

Geek Notes 2005-01-24

Geek Noise — Mon, 24 Jan 2005 19:48:00 GMT

.NET Nightly 169

.Avery Blog — Tue, 25 Jan 2005 03:38:00 GMT

.NET Nightly 169

.Avery Blog — Tue, 25 Jan 2005 21:32:00 GMT

Interop-stepping is 400 times faster in Whidbey over Everett

Mike Stall's .NET Debugging Blog — Tue, 21 Jun 2005 07:23:32 GMT

We’ve made Interop-debugging (aka “mixed-mode debugging”) much faster and more stable in Whidbey (VS8)...

O que acontece quando voc? aperta F9?

How Things (Should) Work — Tue, 28 Jun 2005 22:54:49 GMT

Being a CLR dev does not mean you know everything about the CLR

Mike Stall's .NET Debugging Blog — Mon, 13 Mar 2006 07:50:09 GMT

I find people often assume that just being a developer on the CLR means you somehow know everything about...

.NET Internals Tid-Bit #1: Managed Breakpoints

Eldar (NasdaqNM: ERJR) — Tue, 14 Mar 2006 15:56:19 GMT

.NET Internals Tid-Bit #1: Managed Breakpoints

Eldar (NasdaqNM: ERJR) — Tue, 14 Mar 2006 18:06:32 GMT

.NET internals tid-bit #1: Managed breakpoints

Eldar — Sun, 08 Jul 2007 06:20:34 GMT

From Tuesday, March 14th, 2006: A friend of mine asked me recently if I had any good books on .NET internals...

Employment Wages » Mike Stall’s .NET Debugging Blog : How do Managed Breakpoints work?

Fri, 28 Mar 2008 12:54:18 GMT

PingBack from http://employmentwagesblog.info/mike-stalls-net-debugging-blog-how-do-managed-breakpoints-work/