When NCrunch first builds a project, it creates a shadowed version of this project inside a separate area of the hard drive called a workspace. In order for the code within the workspaced project to build and execute in full isolation, it must contain no references to files that exist outside its workspace.
If NCrunch attempts to process a project containing an absolute file path, there is the risk that this processing could introduce changes outside the project workspace, thus interfering with other operations on the computer. If code within a project manipulates a file that is part of the foreground solution open in Visual Studio, this can create a 'build loop' problem where NCrunch continuously detects new changes in the open solution and rebuilds projects in their workspaces to synchronise them with the new changes.
Absolute file paths can also result in files outside the workspace being open and read by NCrunch at any time. This can cause frustrations such as file locks and erroneous test behaviour.
Best practice is to avoid absolute file path references in your code in all situations. Where this is impossible, you may be able to introduce conditional NCrunch behaviour to prevent file references from causing problems when testing continuously.
Discovery of absolute file path references can be very easy where these references are pointing to files within the foreground solution. Simply rename the directory containing your solution to something different, then try building and running all tests within the solution. Any code making use of the absolute file path will almost certainly fail as a result of this, giving valuable clues as to where to find the reference.
Other ways of searching for referenced files include close inspection of the files used by testing processes with Task Manager (or Process Explorer), or performing text searches on your entire codebase to find strings that reference specific drives/directories.