Hi Bob,

When upgrading to VS2013, did you also upgrade to a new version of NCrunch? (i.e. from 1.48 to 2.7?) Or was it just to a different build of NCrunch under the same version (i.e. v2.7 VS2012 to v2.7 VS2013)?

A useful thing I think we should check is whether or not the engine is actually detecting the ExclusivelyUses attribute. In the Tests Window, right click the columns and choose to show the 'Exclusively used resources' column. When all your tests are showing in the window, does this column show their usage of the resource?

Also, are you using distributed processing?

Ok - that narrows things down a bit. The next thing we should check is the behaviour of the tests in the processing queue. If you set the filters on the queue to show only executing tests, and turn on the 'Exclusively Used Resources' column, do you see any evidence of the engine running tests concurrently that make use of the same resource?

The area of the engine that handles resource locking is very mature and hasn't seen any work for a long time, so I think there may be more going on here. Something that hits my mind is the nature of database connectivity. If you have a test that holds an open database connection (perhaps including locks on database tables or resources) after its execution has completed, this can create a concurrency problem for NCrunch ... as NCrunch will not be aware of the locked resource and will simply execute the next test, possibly inside a different test process.

ADO.NET often tends to pool database connections, which means that it could still be possible that the test process is holding open connections to the database after its tests have finished executing. Off the top of my head I'm not aware of any situations where a SQL server database would retain locks using a connection stored in the pool, but there's quite a bit that can go on here and I'm not sure what kind of database you're working with.

Something that may help with such an issue is to try setting the Test process memory limit to '1'. This will cause NCrunch to terminate each test process after it's finished an execution run, which may help break up resource locking. Because this will stop NCrunch from re-using test runner processes, it will also reduce the engine to a crawl - so it's probably only useful in helping to further narrow down the problem.

The processing queue window has a number of filters on the toolbar to control which tasks are shown in the view. I recommend turning on the 'Stopwatch' option and leaving the rest turned off, as this will make it possible to see which tasks are running at any one time. If you have the 'Exclusively Used Resources' column showing in the window, you won't need to see the test names inside each task in order to know that they're using the same resource (as it'll be shown next to the task). If you don't see the toolbar options for filtering on this window, try updating to a later version of NCrunch. The filters were introduced in V2 and won't be available under V1.

I definitely don't recommend actively working with the test process memory limit set to 1, but I do suggest trying this for a few engine cycles as it will help us to further narrow down the problem.

Ok - this suggests the engine is behaving correctly by not running tests concurrently when they use the same resource.

The test tasks themselves are batches, so all tests within each batch are run synchronously within the same process.

How did you get on with the test process memory limit? Did this make any difference? I strongly suspect that the resource problem you're experiencing is due to resource cleanup after tests complete their execution.