Search the Knowledge Base:


RDX cartridge is unable to eject or Microsoft Eject Fails with "Volume Lock Access Denied"
(KB # 583B9FCA)

In some cases you may notice right-click or button eject continuously fail when using a Microsoft OS. The typical reason for this failure is due to a failure to obtain an exclusive lock through the operating system.

Scenarios we know can cause this problem:

1.) The RDX device drive letter or sub-folder is shared using Microsoft's sharing and one or more systems have accessed the share. In some cases the OS does not release handles after the share is disconnected on the client. To check whether this may be the case you should open computer management-> shared folders and look under "Sessions" for any open share sessions to either the RDX drive letter or a folder contained on the RDX drive. If possible un-map this drive from the sharing system. If necessary right-click and remove the share from the sessions view of the system with RDX device connected.

2.) (Server 2008) A windows explorer window is open and showing drive contents for at least one logged in user.

3.) Another software application (antivirus,backup) may be periodically accessing the RDX device letter.

4.) The OS may be keeping an open handle to the device in the system process. Some customers have reported this issue in specific environments (especially Small Business Server 2003 with Backup Exec and volume snapshot services.) We suspect an interaction with Backup Exec and potentially Windows Management Instrumentation (WMI.) We do not understand root cause and have not been able to reproduce in-house to pursue the issue with Microsoft. For more details about troubleshooting this problem please see instructions below.

How to know whether your system is exhibiting this issue:
Your system is exhibiting this issue if every right-click eject attempt from Windows Explorer results in an application error log entry from RDXMon "Volume lock failed. Best Effort Lock is NOT enabled. (Error code:5) Access is denied.."

Resolving the issue through brute-force:
For a brute-force method to resolve these issues, please see the article "Best Effort Eject."

Troubleshooting the issue:
If you'd like to troubleshoot the issue further instead of using the best effort eject workaround, and are an administrator user comfortable with using OS level debugging tools, please read this section.

SysInternals Handle.exe is useful for determining who holds a currently open handle and is preventing eject. Run this program from the command line using the following syntax: "handle -a \Device\HardDisk" This will list open device handles on the system. Typically one of the disks listed will be the RDX drive. In some cases the handle may be based on the drive letter instead, to search for this use "handle -a E:" To map HardDiskXX to the RDX drive in cases where it is not obvious, open a command line prompt and browse to the RDX drive letter. Run handle.exe and look for the \Device\HardDiskXX handle open by the cmd.exe process. This will tell you which hard disk number corresponds to the RDX drive in question.

If you see no open handle with handle.exe you may want to run several times. It may be that a process is opening the device periodically. For further troubleshooting of this scenario see "Process Monitor" below.

In some cases the output of handle.exe will give you a pid and process name that can easily identified as the culprit holding the open handle (for instance a backup application name.) In other cases it may just show "System" and pid 4.

On "pid 4" cases where the system process holds the open handle, you first check for an access through remote shares (scenario 1 described above.) If this is not the case you most likely are experiencing scenario 4 described above. See instructions below for using ProcessMonitor to debug further

Process Monitor
Process monitor is useful for transient handle debugging - to show who is opening handles to the RDX drive, when and potentially why.

Open process monitor and in the filter dialog select "Path includes" for "/Device/HardDisk" or "E:" where "E:" is the drive letter of the RDX drive. You can further limit prints by finding the exact hard disk number using the method described in the handle.exe usage instructions above. You should see handle opens/closes scroll by in the window as the disk is accessed.

If the handle is present immediately after the system is booted you can configure process monitor to capture a boot trace (see options->enable boot logging.)

If you can capture a CreateFile on the device handle during boot and can see it is not followed by a CloseFile, the "Stack" tab under event properties will show you the driver that initiated the open. This may be a clue to help determine which process is opening the device handle and why.

Rate this

Send Feedback

Send Us Feedback

Questions, comments, suggestions? Use our
feedback form and let us know what you think.

Feedback Form