Hi, thanks for posting!

NCrunch's behaviour around background exception handling is specific to the test framework you're using. The framework itself decides what to do with the exception - in most cases reporting it in such a way that NCrunch will fail the test.

My understanding of the TPL is that exceptions can be pushed up to be handled by threads interacting with the Task objects. It may well be that they are being thrown in such a way that the component you are using doesn't know what to do with them.

I'm afraid that this is unlikely to be a problem that can be solved in the test runner itself. You'll need to take a look at the abstractions you're using to see if you can find a way to change the way your code is reporting exceptions on the background thread. You might find it useful to inject an exception handler in your test code that is intended to silently swallow any background exceptions that are thrown. This could be switched out in your production code to instead find a constructive way to log the exception or inform the user of it.

Background exceptions can actually be a huge risk to a runtime application in production, as the default behaviour from .NET 2.0 upwards is for the process to be torn down if an unhandled exception bubbles up on any thread. Although suddenly closing a server-side socket may not be typical for your application at production run-time, I think you'll find there are many advantages to adding extra hooks in this area to preserve the running state of your application.