Communicating with CD DVD devices - port driver ? class driver ?
in [Device Drivers]
|
Prev: ndislwf monitoring filter preventing network connectivity
Next: Phantom messages being sent to Interrupt OUT on a specific USB HID
From: bilm on 6 Jan 2010 18:34 I have an application that reads & writes to CD & DVD devices. I've not written my own device driver and have no ambitions to do so but I thought I'd ask a question here about something that still confuses me. The MS documentation for how to communicate with CD & DVD devices says the CD/DVD class driver is cdrom.sys which handles all the CDROM ioctls. Unfortunately these ioctls are inadequate for taking full advantage of CD and especially DVD capabilities. Plus many of them work on some versions of Windows and not on others because they have been replaced by new ones; a programmer's nightmare. Except for a few, I avoid them at all cost. I use the T10/SCSI/MMC low level commands and send them via the SPTI. But IOCTL_SCSI_PASS_THROUGH & IOCTL_SCSI_PASS_THROUGH_DIRECT are not handled by the class driver. These are port driver ioctls and MS documentation says I cannot send them to the port driver if the device is claimed by a class driver. As far as I know all CD/DVD devices are claimed by cdrom.sys on bootup ... ? Also to send MMC low level commands via SPTI, I must get the handles for these devices (during SetupDI enumeration) using the Device Interface Class i.e. GUID_DEVINTERFACE_CDROM and not GUID_DEVCLASS_CDROM. I'm not sure where these classes fits in with the port & class drivers. Can someone tell me definitively which handle for these devices will allow me to send the commands via SPTI using the shortest route to the device ? Is there is another, better way than using the SPTI ? I'm talking about in user mode ... unless there is a way for me to use kernel mode ? bilm
From: Maxim S. Shatskih on 7 Jan 2010 09:58 > I use the T10/SCSI/MMC low level commands and send them via the SPTI. Yes, this is how must burning software (including Nero and Vista+ IMAPI) works. > But IOCTL_SCSI_PASS_THROUGH & IOCTL_SCSI_PASS_THROUGH_DIRECT > are not handled by the class driver. Correct, the class driver is just plain stupid pass-through in this picture. There is no agent to handle these SCSI commands from the app till the drive's firmware. CdRom.sys is a passthru for them, and the storage port just delivers the commands to the drive. > Also to send MMC low level commands via SPTI, I must get the handles for > these devices (during SetupDI enumeration) using the Device Interface Class > i.e. GUID_DEVINTERFACE_CDROM Oh yes. More so, on Vista+ you should use "exclusive mode" IOCTL, which is the only mean to prevent the race between AutoRun and your MMC commands for just-inserted disc. And, this IOCTL _mandates_ you to open the device by means of PnP - GUID_DEVINTERFACE_CDROM, not as \\.\e: or such. The thing is that using the PnP name bypassed CDFS at all, while using \\.\e: will route your requests to CDFS, and "exclusive mode" IOCTL is failed at CDFS level. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: bilm on 7 Jan 2010 12:54 Thanks Maxim, > There is no agent to handle these SCSI commands from the app till the > drive's firmware. CdRom.sys is a passthru for them, and the storage port > just delivers the commands to the drive. It is good news for me to hear I am sending the commands via the shortest route to the drive's firmware. > Oh yes. More so, on Vista+ you should use "exclusive mode" IOCTL, > which is the only mean to prevent the race between AutoRun and your MMC > commands for just-inserted disc. I'm not familiar with the term "exclusive mode" IOCTL. What is it ? Do you mean the SPTI IOCTLs used when opening CD/DVD devices with GUID_DEVINTERFACE_CDROM ? Or something else ? bilm "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message news:uCyKSn6jKHA.5520(a)TK2MSFTNGP06.phx.gbl... > I use the T10/SCSI/MMC low level commands and send them via the SPTI. Yes, this is how must burning software (including Nero and Vista+ IMAPI) works. > But IOCTL_SCSI_PASS_THROUGH & IOCTL_SCSI_PASS_THROUGH_DIRECT > are not handled by the class driver. Correct, the class driver is just plain stupid pass-through in this picture. There is no agent to handle these SCSI commands from the app till the drive's firmware. CdRom.sys is a passthru for them, and the storage port just delivers the commands to the drive. > Also to send MMC low level commands via SPTI, I must get the handles for > these devices (during SetupDI enumeration) using the Device Interface > Class > i.e. GUID_DEVINTERFACE_CDROM Oh yes. More so, on Vista+ you should use "exclusive mode" IOCTL, which is the only mean to prevent the race between AutoRun and your MMC commands for just-inserted disc. And, this IOCTL _mandates_ you to open the device by means of PnP - GUID_DEVINTERFACE_CDROM, not as \\.\e: or such. The thing is that using the PnP name bypassed CDFS at all, while using \\.\e: will route your requests to CDFS, and "exclusive mode" IOCTL is failed at CDFS level. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Maxim S. Shatskih on 7 Jan 2010 14:09 > I'm not familiar with the term "exclusive mode" IOCTL. What is it ? Grep the WDK headers for IOCTL_CDROM_ Sorry, forgot the exact name. IOCTL_CDROM_EXCLUSIVE_MODE or such. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com
From: Don Burn on 7 Jan 2010 14:20
It is IOCTL_CDROM_EXCLUSIVE_ACCESS. -- Don Burn (MVP, Windows DKD) Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr Remove StopSpam to reply "Maxim S. Shatskih" <maxim(a)storagecraft.com.no.spam> wrote in message news:ehc$B08jKHA.2184(a)TK2MSFTNGP04.phx.gbl... > I'm not familiar with the term "exclusive mode" IOCTL. What is it ? Grep the WDK headers for IOCTL_CDROM_ Sorry, forgot the exact name. IOCTL_CDROM_EXCLUSIVE_MODE or such. -- Maxim S. Shatskih Windows DDK MVP maxim(a)storagecraft.com http://www.storagecraft.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4751 (20100107) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 4751 (20100107) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |