Hi Daniel,

Thanks for sharing this issue.

This is most likely occurring because NCrunch enforces a default test timeout of 60 seconds whenever no existing timeout has been specified. This is because timeouts are very important when running tests continuously, as otherwise the engine can hang. See http://www.ncrunch.net/documentation/concepts_test-timeouts for more details on how NCrunch uses timeouts.

As the test likely is running longer than 60 seconds, I'd recommend labeling it with a sensible Timeout with a much higher value .. something that will always be more than it needs to finish a normal run.

No - you're absolutely right. It shouldn't. Sorry, I misunderstood.

This isn't a known problem, so I might need some more information to try and figure out what is happening. NCrunch should only execute ThreadAbortExceptions inside try/catch blocks.

Which test framework are you using? Is there any chance you can get me a code sample that reproduces the issue?

Hi Daniel -

Thanks for the sample solution. The first time I opened it, the task runner immediately crashed. After some tinkering, it stopped crashing and NCrunch/NUnit started handling the thread abort normally, reporting a sensible error. I since haven't been able to get the problem to occur again, but placing this observation together with the information you've given me, I think I can draw a conclusion about why it is happening.

ThreadAbortException is not known for its reliability. Generally, it is considered 'evil' to make use of it, as there is no telling what kind of code is being executed at the point of the abort. This could be code that is managed or unmanaged, critical or otherwise. In the vast majority of cases, using this exception will result in the correct handling where either NCrunch or NUnit can step in to prevent the task runner from being torn down. In this specific case, it looks as though the code being executed (Wpf Window Show) sometimes steps into situations where the abort cannot be properly handled and the process is immediately torn down with an irritating error box.

The only alternative approach I can think of to stop a test from executing is to arbitrarily terminate the task runner during execution. This will prevent the error from showing, but it is a major step backward in that it is impossible to retrieve data from a terminated process, and any user error handling within the test code will not have a chance to fire. There have been some remote plans to introduce this approach to control overrunning tests, but only when the existing Thread.Abort method fails and the process refuses to return to a useful state. In your error situation, there is no way to detect the unclean failure of Thread.Abort before the crash error box is shown.

So I'm sorry, but I'm afraid this doesn't look like a problem I can fix. We are limited here by the constraints of the operating system and the unknowns in the code being executed. All I can suggest is to try and make sure your timeouts are set to sensible values so that the tests can execute normally.