In Windows, there is no native supported way to block certain processes from accessing certain drives, that goes "against the current nature" how the operating system handles drive access.
The right for access is determined by the logged on user's rights who starts the application. So if the software developer decided his software should search all accessible drives and does not give you the option to turn that off... well, that's bad programming which does not consider your particular use case. But there are a few workarounds.
The only "sure" solution is 2, since the hardware virtualization layer (from the virtual machine) can block any applications to attempt to access the "real hardware" completely. Although I haven't had the case where solution 1 doesn't work, but theoretically I think it could be bypassed.
Option "1" - Disabling the drives at a "low level" - No additional software needed
It's possible to disable the volumes on a lower layer by disabling the drives altogether, but this will disable all volumes on the drive. Manually, you can do it by starting
diskmgmt.msc, then right click on the drive and mark it "offline".
If needed, you should be able to do that using a command line script as well. It would be applied a similar way as Option 3a/b. You can do that, for example, via cmd as described here or via PowerShell, as it is described here.
You can deactivate the drive's driver altogether. To do in manually: start
diskmgmt.msc, then right click, choose "options". Then go to the "Driver"-Tab and select "Deactivate". The drive will "disappear" in the disk manager and won't be accessible through the operating system anymore. Unless the software doesn't execute machine code commands to communicate directly with the hardware, there should be no way for the application to access the drives. At least as far as my knowledge of the ins and outs for operating systems goes.
If needed, you should be able to do that using a command line script as well. It would be applied a similar way as Option 3a/b using, for example,
Devcon.exe. You can find a detailed description here.
Option 2 - Using a virtual environment (mostly with 3rd party software)
If running the application within a virtual environment is an option at all, there are plenty of solutions out there:
depending on your Windows version (Win7 and up required) and license ("Professional" required, "Home" won't do), you can just use Hyper-V to set up a virtual environment without any third party software.
you can use a third party software to set up a virtual system like VMplayer, Virtual Box, etc. There are many freeware and payware alternatives. By using this solution, you will need a second licence for Windows (or you leave it unlicensed, but then you will get an overlay in the lower right corner of the screen that will tell you to register Windows). This will definitely prevent the software from accessing the drive.
you could use a "sandbox"-application. But it will depend on the level of virualization the sandbox-application offers. In some cases, it can solve the problem; in other cases, it doesn't. Sandboxie, for example (the one harrymc describes in his answer), doesn't solve the problem with the configuration harrymc described in his (original) answer. Although the software might block the access, the drive will still spine up. An alternative would be to use a different sandbox application like Cameyo, etc.
By the way, here's a good article for the main difference between the different virtualization software, especially the difference between a "whole" virtual machine (like Virtual Box) or "semi virtual" applications (like Sandboxie).
Option 3 - Unmounting just volumes (leaving the drive "intact") - No additional software needed, BUT it might not work in your case
Instead of starting the application via its regular shortcut, you could write a batch file using the command
mountvol that first unmounts the unused volume, then starts the application, and then remounts the volume once the application doesn't access the drive anymore. The mounting/unmounting process via command line is described here and here. You can also use
diskpart as described here and here.
Alternatively, you could just leave the drive unmounted in general and mount it via a batch file that mounts the drive which you start manually when needed. After you're done using it, you can manually unmount it using a second batch file. You could automatize that by monitoring file system access requests and mount/unmount the drive as required following certain rules e.g. that certain applications won't have access. But I'm not sure automation is worth the extra effort involved.
Option 4 - Restricting access to a drive-letter (volume). Simple to do, but two small tools from Microsoft needed - BUT it might not work in your case
If you want to do it without 3rd party software but don't mind to use two small tools from Microsoft (if you don't use it already). I prefer this solution because it gets the problem "by the root" (differentiation between the user's and the application's rights) and it's fairly simple and no "big" third party software is needed.
Basically, you add a user with no access to the drive and then you start the program with those limited rights (you will still log on as your regular user, you won't use the restricted account to log on).
Add a user account.
Restrict the new user account's access to the drive by using Windows Access Control for the file system. Here's a good How-To including screenshots.
Then, start the software with those rights. You can, for example, use PsExec.exe to do that or Process Explorer, here's how. One of those two you will have to download from the Microsoft website, if you don't have them already.