Deny application access to hard drive or volume in Windows 7+

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

Option 1a

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.

Option 1b

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

Option 3a

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.

Option 3b

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.

I propose a solution that uses Sandboxie. I don't have your environment, so I have tested running Acrobat.exe in a sandbox where its access to D: was blocked. When opening in Acrobat the menu File > Open, I get this :

Notice that Acrobat can't even find the label of disk D:, so is forced to display it in a lame way, and how it is blocked when I click on "Local Disk (D:)".

The steps I used were :

• Installed Sandboxie
• In Sandboxie Control, right-click the default sandbox and choose Sandbox Settings
• Open the branch of Resource Access > File Access, and click on Blocked Access
• Click Add Program and add Acrobat (mine was C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat\Acrobat.exe)
• Click Add and add disk D:
• Click OK
• In Sandboxie Control, open the branch of Program Start > Forced Folders
• Click Add Folder
• Add the folder where resides Acrobat (mine was C:\Program Files (x86)\Adobe\Acrobat DC\Acrobat)
• Click OK

From now on, all programs launching from the Acrobat folder are forced to execute sandboxed, and specifically Acrobat.exe is blocked from accessing the disk D:. You might need to open up some other sandbox restrictions if Acrobat will have some difficulties executing inside the sandbox.

I don't know if this will also block the specific Windows API call that Acrobat uses to cause the wakeup of the disk, but might be worth trying.

Sandboxie is a great and versatile product that I recommend, free for one default sandbox. For multiple sandboxes it's payware, but life-time license price is very reasonable (I paid). For example, I install products I test in a sandbox and can then wipe them out with one click, and no need for an uninstaller.

Another isolation solution is by using Adobe Reader inside a Docker container. Docker containers are small and work like a virtual machines, but without needing to create the machine, since ready-made containers are downloaded from the Docker gallery.

You may use Chocolatey as package manager.

Chocolatey has many available pre-built packages with Adobe Reader at Adobe Acrobat Reader DC 2018.011.20063.

With Docker, absolute isolation is possible as regarding resources, and on the other hand one is able to share resources such as folders in a completely native way.