I know I can use Debugger.IsAttached to detect whether a debugger is attached, but I want to be able to do something like
if (Debugger.IsAttached && Debugger.BreakpointIsSet && Debugger.BreakpointHitCount > 0)
timeout *= 100;
someEvent.WaitOne(timeout);
The reason is some of my testing scenarios involve activity on other threads. Viewing things under the debugger naturally disturbs this process. I'd like my main testing thread to block longer while I'm stepping after a breakpoint hit on some other thread, but not block as long if the debugger isn't attached, or it is but a breakpoint hasn't been hit yet.
Is something equivalent to the above possible; for example, using P/Invoke to an unmanaged debug API?
I'm not sure I fully understand what it is you plan to achieve here - but it sounds like whatever solution might be cooked up, it will only expound on the certainty and confusion of what is really happening when your threads signal each other, which is confusing enough as is, especially when attaching a debugger.
I'd say you're better off staying away from the debugger on this one and doing good ol' "printf debugging", and of course looking at the ThreadID from which each message was generated.
That said, if you still wish to use a debugger for this, it might be useful to look at only one thread (and one thread only) while the others are all blocked, and monitor its activity when the system enters a corrupt state - this link might be helpful for that: https://web.archive.org/web/20130119010803/http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/07/17/automatically-freezing-threads-brrrrr.aspx