I know I can use Debugger.IsAttached to detect whether a debugger is attached, but I want to be able to do something like
我知道我可以使用Debugger.IsAttached来检测是否附加了调试器，但我希望能够做类似的事情
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?
是否与上述相同;例如，将P / Invoke用于非托管调试API？
3 个解决方案
#1
2
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.
我会说你最好远离这个调试器并做好“printf调试”，当然还要查看生成每条消息的ThreadID。
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: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/07/17/automatically-freezing-threads-brrrrr.aspx
也就是说，如果您仍然希望为此使用调试器，那么仅查看一个线程（仅一个线程）而其他线程全部被阻塞可能很有用，并在系统进入损坏状态时监视其活动 - 这链接可能对此有所帮助：http：//www.wintellect.com/CS/blogs/jrobbins/archive/2009/07/17/automatically-freezing-threads-brrrrr.aspx
#2
2
Break points are a function of the IDE (Visual Studio) and the debugger, not of the .NET framework itself... As far as I know the closest you can get to what you need is to use Visual Studio "Breakpoint Condition" feature...
断点是IDE（Visual Studio）和调试器的功能，而不是.NET框架本身的功能......据我所知，最接近您需要的是使用Visual Studio“断点条件”功能...
#3
2
I am not aware of such a possibility, but what exactly is a breakpoint that has been hit? It is paused execution of at least the thread your breakpoint is hit in. Going on from this, you could maybe use Thread.ThreadState and check for the state Suspended. For this to work, you would need to have a reference to the thread that is of interest to you.
Disclaimer: I don't know, whether this will work or whether this has any side effects, so even if it works, use it only in debugging and make sure, it is not in your production code.
我不知道这种可能性，但究竟是什么断点已被击中？暂停执行至少你的断点所在的线程。继续执行此操作，你可以使用Thread.ThreadState并检查状态Suspended。为此，您需要引用您感兴趣的线程。免责声明：我不知道，这是否有效或是否有任何副作用，所以即使它有效，只在调试时使用它并确保它不在您的生产代码中。
#1
2
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.
我会说你最好远离这个调试器并做好“printf调试”，当然还要查看生成每条消息的ThreadID。
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: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/07/17/automatically-freezing-threads-brrrrr.aspx
也就是说，如果您仍然希望为此使用调试器，那么仅查看一个线程（仅一个线程）而其他线程全部被阻塞可能很有用，并在系统进入损坏状态时监视其活动 - 这链接可能对此有所帮助：http：//www.wintellect.com/CS/blogs/jrobbins/archive/2009/07/17/automatically-freezing-threads-brrrrr.aspx
#2
2
Break points are a function of the IDE (Visual Studio) and the debugger, not of the .NET framework itself... As far as I know the closest you can get to what you need is to use Visual Studio "Breakpoint Condition" feature...
断点是IDE（Visual Studio）和调试器的功能，而不是.NET框架本身的功能......据我所知，最接近您需要的是使用Visual Studio“断点条件”功能...
#3
2
I am not aware of such a possibility, but what exactly is a breakpoint that has been hit? It is paused execution of at least the thread your breakpoint is hit in. Going on from this, you could maybe use Thread.ThreadState and check for the state Suspended. For this to work, you would need to have a reference to the thread that is of interest to you.
Disclaimer: I don't know, whether this will work or whether this has any side effects, so even if it works, use it only in debugging and make sure, it is not in your production code.
我不知道这种可能性，但究竟是什么断点已被击中？暂停执行至少你的断点所在的线程。继续执行此操作，你可以使用Thread.ThreadState并检查状态Suspended。为此，您需要引用您感兴趣的线程。免责声明：我不知道，这是否有效或是否有任何副作用，所以即使它有效，只在调试时使用它并确保它不在您的生产代码中。