NCrunch was unable to retrieve a meaningful result from this test due to an unexpected error

Came across this error today (in case anyone else finds this useful).

In addition to the help docs, it's advisable to check the Application Event Log (steps 1 and 2) in Windows. Look for any ".NET Runtime" records and they should show you a stack trace of where the process crashed.

In our case, we'd left a Debug.Assert in there which was causing the process to crash (instead of pop up a message) when running under NCrunch

Thanks for sharing this. It's good advice, and I'm updating the error message to include it.

Because I often have unmanaged C/C++ (under development) at the bottom of my call-stack, I get to see quite a lot of these, and I am always a bit sad that the message is little more than, "There was an error."

Is there any chance that your test-runner has any diagnostics at all when it crashes which could be put into the test results window?

(As a somewhat related issue, I always have to use the Jetbrains test runner/debugger to investigate these, because I haven't been able to work out how to get NC to launch the debugger in mixed-mode)

When I'm developing on NCrunch and something isn't right in the test process, I see a lot of these errors too. I would say it's probably the most frustrating problem under NCrunch ... just a 'something went wrong'.

The root problem comes down to how the platform works. If a process raises an exception in a way that cannot be caught (i.e. unmanaged code, memory error, platform stability problem), the O/S just deletes the process and we have no way to get error information.

Running the test with the debugger attached can sometimes allow the debugger to intercept the exception before the process is deleted. The debugger has more options available to it than NCrunch's runtime code does in this situation.

When running the debugger with NCrunch, it uses the VS debugging API to attach the debugger to a running process. I think it will use the default 'auto detect' option with this, which may not be particularly reliable. This is walled away from NCrunch.

Thanks for this - it makes sense. I have no idea if you might be able to borrow their technique, but somehow Resharper is actually able to cope with this - I have deliberately caused a ref-0 exception in some C++ code, and in NC I get the message we're discussing here, but in R# I get the following:

Exit code is -1073741819 (Fatal error. 0xC0000005
at <Module>.GlobalState.Initialise(GlobalState*)
at Mk4RxApplication.RxApplication.Start(System.Threading.ManualResetEvent)
at RxEmulationControl.Mk4HardwareEmulation.StartApp()
at RxEmulationControl.HardwareEmulationBase.SynchronousStart()
etc, etc, stack trace right through nUnit.

This is using their normal "run test", not a debugger.

Looking at their runner process, the dotnet.exe command line ends with "connect --port 40521", which I guess is this stuff: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/diagnostic-port

I imagine this is all very complicated to use even without the existing complications of nCrunch - and I'm aware that JetBrains can probably bring enormous resources to bear on this stuff if they want to.

I don't know how they get the mixed-mode debugger launch right, but I do know they have occasionally broken it in the past - I think it uses something to do with the debugger type specified in the startup project (irrespective of whether that has anything to do with the unit test projects).