I'm not sure this is "by design", but the behavior surprised me. When you have a Debugger.Break() somewhere in your test code (not common, I know), then the NCrunch testrunner process will crash. It does, however, run the whole test if you dismiss the crash dialog box popup, which is rather odd.
This is handled by the O/S itself. I guess it's possible for NCrunch to rip these calls out during instrumentation, but sometimes they can be useful if you want to hook a debugger onto a running session (which I believe is often the intention).
I think it would be rather messy or even detrimental for NCrunch to try and avoid showing this dialog.
Avoiding it is probably a bad idea, after all the Break() instruction is encountered. And thinking about it now it makes sense. However, a better dialog text would be welcome, but I guess I should consult Microsoft on that. Unless you want to hook Break() (which is not that hard, you don't need to remove it with instrumention, just attach a dummy debugger, which will then automatically be called, which then shows an NCrunch-style dialog). But I can imagine you have bigger fish to fry ;)
EDIT: a good workaround (in case a break is needed) would be to use Debugger.Launch(), which launches the dialog box with available debuggers, which is much clearer.