DeviceIoControl fails with Access Denied on certain computers

  • Thread starter Thread starter pveg
  • Start date Start date
P

pveg

Guest
We have a program that allows sending SCSI CDBs to attached hard disks. This is accomplished using SPTI, DeviceIoControl, and IOCTL_SCSI_PASS_THROUGH. On most computers (including all the ones I can test on) this works fine. However, some users report that an error code of 0x5 (Access Denied) is returned on any and all IOCTL_SCSI_PASS_THROUGH calls, despite the program being run as an Administrator. The machines in question are Windows 7 32-bit, both Professional and Ultimate. Finally, if the program is run instead on an (identical) XP machine, it succeeds as expected.

Some more information:

These hard disks have no class driver loaded - if Windows loads one up automatically, the user must go into Device Manager and uninstall the driver for it.

The code enumerates the computer's HBAs using SetupDi* calls, then finds all the attached devices and their information (such as LUN, etc). It also enforces that the "claimed" field is set to 0, ensuring the user doesn't have a class driver loaded for it.

A handle is opened as such (where "hba_path" is a TCHAR* of the full path to the HBA the hard disk is attached to, returned by the SetupDi* calls):

handle = CreateFile(
hba_path,
GENERIC_READ|GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
NULL);

That seems to always return a valid handle. Then, the CDB is attempted to be sent as such:

DeviceIoControl(
handle,
IOCTL_SCSI_PASS_THROUGH,
buf,
wlen,
buf,
rlen,
&br,
NULL);

This works fine on my machine (a Windows 7 32-bit Enterprise), as well as the users' XP machines and most others. However, on those couple previously-mentioned machines it fails, and GetLastError returns 0x5 (Access Denied). Again, this code is being run by right-clicking and selecting "Run as administrator".

From what I can tell, starting with Vista there were some changes to restrict access to disks. I've looked at CreateFile, and it specifies:
Must have administrator privileges
Must have OPEN_EXISTING
Must have FILE_SHARE_WRITE
As shown above, all three are true. I've also looked at this knowledge base article, and I don't think I'm running afoul of anything there either (though it's significantly more technical, so I'm not 100% sure). Either way, the disk in question has no file system mounted or anything, so I don't think it applies anyway.

Does anyone have any idea why it would fail on those machines and not others? I don't have direct access to those users' machines (since they're halfway around the world), but I have used VNC to confirm that the code is being run under the above-mentioned conditions. The only thing I've been able to find is that using XP solves the problem - and that's not going to be a permanent solution for some of the users, so I would like to figure out what's going on.

Continue reading...
 
Back
Top