Unfortunately the dump file probably won't be of much use to me in narrowing down what is happening here. Have you noticed any pattern to the crash? Does it happen if you use NCrunch on another solution?
Something to try is to set the Use hosted task runner configuration setting to FALSE. This will force NCrunch to use only managed code inside the test process, allowing us to rule out whether the crash is being caused by NCrunch's code.
If you haven't already, I recommend trying the new NCrunch V2 beta. This release contains handling for stack overflows which are known to cause problems such as this when they are thrown by code under test. Stack overflows are the leading cause of crash faults in V1 because they result in the entire test process being torn down, making them painful to try and debug.
If you can isolate a test that is consistently causing this problem, I recommend trying to step into the test with a debugger to see if the explosion happens before your test starts executing, or during its execution.
I installed V2 Beta and the same crash happened on the first run of tests. I'm also suspecting Stack Overflow but looks like stack overflow detection is turned on.
For some reason, I can't find the "Use Hosted Task runner" option in configuration. I selected Configuration from the menu in Visual Studio. Then I'm looking under "General Settings". I don't see an option to select "All solutions" as the wiki suggests. Probably just need another cup of coffee.
> You can adjust the global configuration settings by selecting the All Solutions option under the configuration pane (accessible from the top NCrunch menu under Configuration).
Regarding the dump file, these can be opened in Visual studio and sometimes provide useful information as to the state of the app at time of crash.
The newest version of NCrunch V2, which was released a few hours after I responded to you above, actually has the hosted task runners removed because they were causing problems. If you're still seeing this crash, it's fairly certain that there is no relationship with unmanaged code being executed by NCrunch.
Have you had any luck in narrowing down which test is surfacing the issue? Is it possible for you to step into the test with a debugger?
I'm happy to have a look at the crash dump, but from experience with NCrunch I've found these dumps often show the corrupt state of a process long after the issue has actually appeared, and they do tend to be quite large. If you have a way of sharing it with me, I'm sure it wouldn't hurt to take a look.
That's the strange thing, the NCrunch output will show "Test Cancelled by user" after I hit the cancel button on the WER reporting to microsoft dialog. Then I'll try running the same test in debugger, and I have no issues.
It looks like the dump file is 18 Mb. Could I send a dropbox link on the contact us form?
That is very, very strange. The other thing I would suggest is trying to comment out or deduct parts of the code under test to see if you can narrow down what's causing it. Are you executing any unmanaged code with your test?
Unfortunately 18MB is a little too large for the contact form ... this form backs onto a mail server that seems to be struggling with large attachments at the moment. Do you have anywhere else you can store it? Dropbox perhaps?
Ahh sorry. I just re-read your post and realised I must have been cross-eyed (<facepalm>). A link should be no problem. Drop it through the form and I'll be happy to take a look.
Thanks Remco. I finally was able to reproduce a stack overflow (infinite loop) after getting some data from our QA environment.
I guess I can't be sure that the test was hitting this stack overflow error since it wasn't happening on every run. Also, you mentioned the Beta version has new Stack Overflow detection. But, NCrunch has been running smoothly for me today.
I think I will not bother you with the dump file for now.
Thanks for a great product. Really a joy to code with this running in the background.
Great to hear! Stack overflows can be a bit of a nightmare to track down in a test environment. I guess this was the perfect storm with an overflow appearing inconsistently. I'm glad you tracked it down.
Because it works using instrumentation, NCrunch's stack overflow detection is limited to only picking up overflows that occur within user code. This means that if the overflow is occurring within libraries you're calling into, NCrunch won't be able to detect it and stop it from ripping the test process apart.