'No disk in the Drive' error when debugging in Visual Studio

Question

Whenever I debug my program, I sometimes get several errors asking me to insert a disk into Drive E and Drive F. This seems to be something to do with VS looking for the source of Third Party components which were originally developed on these drives, for example

If I keep pressing cancel, then my debugging session continues, but it is rather annoying. How do I stop this happening?

Note, I am not trying to debug these libraries, and I have 'Enable Just my Code' ticked under Options/Debugging.

Answer 1

These DLLs were built on a Microsoft build server in Redmond, Washington State. Microsoft normally configures these build servers to find their source code on the F: drive. The .NET Framework assemblies for example were built from f:\dd, "dd" is DevDiv, the group at Microsoft that is responsible for developer tools. Inside the DLL, there can be a section that contains the location of the PDB file for the DLL at the time the DLL was built.

Unity is produced by another group at Microsoft, called "Patterns and Practices". Notable for using fairly poor practices. That section in the DLL that contains the PDB location should be stripped, as it is for normal .NET Framework assemblies. You can tell from the message that they don't use the normal build servers that DevDiv uses.

So you are seeing the content of that section, e:\Builds was where the source code for Unity was originally located. So that's where the debugger will look first to find the PDB again. Of course it isn't going to find it, you are not debugging your code on that build server :) That normally doesn't cause any trouble, the debugger quickly finds out that the PDB isn't there and continues searching. First looking in the symbol cache, downloading the PDB from the symbol server next.

Unfortunately on your machine, the E: drive in fact exists. But it is in limbo, the drive letter exists but it isn't actually mapped to a functional drive. The most common cause is you previously having mapped that drive to a network share but the network connection no longer being functional. Or a flash drive that wasn't properly dismounted. So Windows steps in when it sees a program trying to access the drive and generates a low-level prompt to give you an opportunity to re-establish the drive connection. It is the GUI version of the notorious MS-Dos "Abort, Retry, Fail?" prompt.

You don't want this of course. So just disable the drive so Windows leaves you in peace. Click the "Computer" shortcut on your desktop, right-click the E: drive and select (I forget the exact command) Disconnect or Disable so the drive disappears.

In case this was originally a mapped network drive, the best practice is to follow the Windows recommendation, it maps drives from the bottom up, starting at the Z: drive. If the drive letter had another source (I think some machines map the card readers to that drive letter) then follow up at superuser.com to find out how to get rid of these non-functional drive mappings. They can probably also tell you if there's a way to get rid of this prompt completely, there ought to be one.

Answer 2

I have found that closing the solution and deleting the .suo files works when this happens to me. Though I usually don't get the comment about a specific DLL, just the drive so this may not be the exact same problem.