Test fails without error message

I have a test that fails without producing an error message.
The execution time always is exactly one second.
Doing a complete rebuild in VS showed that some files were in use. However NCrunch didn't report any build error.

This usually means the test runner has had an internal failure. Check the processing queue for the test task that failed - do you see an error message in the bottom pane?

No, unfortunately, there was no error message. I checked.

Is it the same test that is failing consistently? Does it also fail if you run it directly via the UI (via clicking the 'run' option on the tests window)? Is there anything you would consider to be unique about the structure of this test?

Yes, it was always the same test. Manually running it in the tests window didn't help.
Nothing about this test is unique, it is very ordinary and similar tests worked without problems.

The test now started working again - I think after I unlocked the files and did a rebuild all in VS and a reset in NCrunch.

Is the 'include static references in workspace' configuration setting disabled? Other than absolute file path references, this is the only way that it can be possible to have locking problems between VS and NCrunch. If you have this setting disabled for any of your projects, try turning it on - this may solve the problem.

"Include static references in workspace" is True for all projects.
Absolute file references are not used.
I sent you a report, maybe it helps.

Is this the same solution that you've been experiencing intermittent xunit.dll build issues with?

The bug report shows NCrunch is failing to map the coverage data derived from the workspace, which suggests this may be a symptom of the same problem causing the xunit.dll build issue.

It is the same solution, but the test is in a different project file.
I don't think it has anything to do with the xunit.dll issue. xunit.dll occurred very often, this problem occurred only as long as those files were locked. It didn't happen since.

Which files were they that you had locked and how were they locked?

Project output files (DLL). They were locked because the program was still running.

There's a lot going on in this solution. I'm wondering if the fix you found in the other thread related to DLLs being referenced in the Bin\Debug directories may have also had an impact on this. Can you let me know if it happens again now that you've solved the other issue? I'm hoping that this problem is related and that we've seen the last of it - Mapping exceptions are almost impossible to analyse and inspect without clear steps to reproduce.

I couldn't reproduce it either. Maybe it was part of the problem with the references.