Mounting CD image using virtual storport miniport

NTDEV
1

Hi,

I am trying to mount a CD image using a virtual storport miniport driver.
The first few CDB op-codes i receive are
SCSIOP_READ_CAPACITY,SCSIOP_MODE_SENSE,SCSIOP_READ_CAPACITY,SCSIOP_READ
(first block- 2048 bytes),SCSIOP_READ_CAPACITY and “SCSIOP_READ_TOC”.

I believe that all the commands are executed correctly (as it correctly
mount HDDs) except SCSIOP_READ_TOC. in READ_TOC initially i get the “Format
field” set to 1 (READ_TOC_FORMAT_SESSION). I have checked the SCSI-MMC6
(T10/1836-D rev 2g) documentation, and found the response data format to
be used in table 481.

In this many of the fields are unknown to me from the CD image(like last
complete session number, addr, control, start address of the first track in
last session). How is it to be handled in virtual miniport?

Thanks a lot,
Lloyd

2

I wrote the virtual SCSI port/miniport stuff of my own as old as in 2003, it included the TDI client miniport which was a client of some “trivial iSCSI” (like TFTP is to FTP) protocol of my own (essentially sending CDBs, sense infos and data buffers via the single TCP connection in the simplest possible way).

The user-mode server service was on another end.

Yes, I remember that, on the OSes of that age, READ TOC was really a must for virtual CD to work (besides the other trivial mandatory stuff like INQUIRY and READ CAPACITY).

Also I remember that I’ve just emulated the simplest possible TOC with 1 track of “data” type. My goal was to mount ISO files with data remotely, and never to mount virtual audio CDs or some multi-track images (which require more sophisticated container file format then ISO).

So, with 2000, XP and 2003, the simplest possible TOC worked fine.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

“Lloyd” wrote in message news:xxxxx@ntdev…
Hi,

I am trying to mount a CD image using a virtual storport miniport driver. The first few CDB op-codes i receive are SCSIOP_READ_CAPACITY,SCSIOP_MODE_SENSE,SCSIOP_READ_CAPACITY,SCSIOP_READ (first block- 2048 bytes),SCSIOP_READ_CAPACITY and “SCSIOP_READ_TOC”.

I believe that all the commands are executed correctly (as it correctly mount HDDs) except SCSIOP_READ_TOC. in READ_TOC initially i get the “Format field” set to 1 (READ_TOC_FORMAT_SESSION). I have checked the SCSI-MMC6 (T10/1836-D rev 2g) documentation, and found the response data format to be used in table 481.

In this many of the fields are unknown to me from the CD image(like last complete session number, addr, control, start address of the first track in last session). How is it to be handled in virtual miniport?

Thanks a lot,

Lloyd

3

I have been trying to solve my CD mounting issue in Virtual Storport
Miniport for some time, and still couldn’t locate the issue. Please let me
explain my problem bit more clear. The first set of SCSI commands I receive
when mounting the CD are -

SCSIOP_GET_EVENT_STATUS
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION

Right now I have not implemented these commands and it sets Srb->SrbStatus
= SRB_STATUS_ERROR. In SCSI MMC spec. I find these commands are mandatory,
and I implemented them. The only difference it made to the sequence of
commands i receive are “SCSIOP_GET_CONFIGURATION” called only once. I have
checked the source code of other implementations like (“Arsenal Image
Mounter” and “bazislib” based “WinCDEmu”), but couldn’t find them
implementing these commands!

The next set of commands I receive are

SCSIOP_READ_CAPACITY
SCSIOP_MODE_SENSE
SCSIOP_READ_CAPACITY
SCSIOP_READ_CAPACITY
SCSIOP_READ (Start->0, Len->2048)
SCSIOP_READ_CAPACITY
SCSIOP_READ_CAPACITY
SCSIOP_READ_TOC
SCSIOP_XPWRITE
SCSIOP_READ (Start->32768, Len->2048)
SCSIOP_READ (Start->34816, Len->2048)
SCSIOP_READ (Start->36864, Len->2048)
SCSIOP_READ (Start->38912, Len->2048)

I am properly handling read capacity,mode sense and read (it works well for
HDDs and USBs). For xpwrite commad simply sends an SRB_STATUS_SUCCESS.
After these set of commands are executed, I can see this commands pattern
repeating without the MODE_SENSE command.

As you can see the first READ command requests the first sector or block
and it contains only zeros.
The second read command requests the block no 16, this location contains
0x 0143 4430 3031 (“.CD001…”).
The remaining three commands requests block no 17,18 and 19 respectively.

The 17th block starts with 0x 0243 4430 3031 (.CD001…). I notice the 0x02
here.
The 18th block starts with 0x FF43 4430 3031 (.CD001…). I notice the 0xFF
here.
The 19th block starts with 0x 2200 1300 0000 ("…).

This is all i could understand from this. The CD image is not corrupted, it
works with other tools. So far I have been guessing that storport is not
getting what it expects from the READ command. I have also implemented a
simple READ_TOC command handler.

If you were in my position, which method would you try to solve this issue?
I read the article about “BusTrace” in recent “NT Insider”, and I wished if
i had access to this tool, I could have verified the working of other tools
like WinCDEmu. Is there any free (sorry for asking) alternative to Bus
Trace?

Thanks a lot,
Lloyd

On Fri, Dec 5, 2014 at 6:44 PM, Maxim S. Shatskih
wrote:

> I wrote the virtual SCSI port/miniport stuff of my own as old as in
> 2003, it included the TDI client miniport which was a client of some
> “trivial iSCSI” (like TFTP is to FTP) protocol of my own (essentially
> sending CDBs, sense infos and data buffers via the single TCP connection in
> the simplest possible way).
>
> The user-mode server service was on another end.
>
> Yes, I remember that, on the OSes of that age, READ TOC was really a
> must for virtual CD to work (besides the other trivial mandatory stuff like
> INQUIRY and READ CAPACITY).
>
> Also I remember that I’ve just emulated the simplest possible TOC with
> 1 track of “data” type. My goal was to mount ISO files with data remotely,
> and never to mount virtual audio CDs or some multi-track images (which
> require more sophisticated container file format then ISO).
>
> So, with 2000, XP and 2003, the simplest possible TOC worked fine.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> “Lloyd” wrote in message news:xxxxx@ntdev…
> Hi,
>
> I am trying to mount a CD image using a virtual storport miniport driver.
> The first few CDB op-codes i receive are
> SCSIOP_READ_CAPACITY,SCSIOP_MODE_SENSE,SCSIOP_READ_CAPACITY,SCSIOP_READ
> (first block- 2048 bytes),SCSIOP_READ_CAPACITY and “SCSIOP_READ_TOC”.
>
> I believe that all the commands are executed correctly (as it correctly
> mount HDDs) except SCSIOP_READ_TOC. in READ_TOC initially i get the “Format
> field” set to 1 (READ_TOC_FORMAT_SESSION). I have checked the SCSI-MMC6
> (T10/1836-D rev 2g) documentation, and found the response data format to
> be used in table 481.
>
> In this many of the fields are unknown to me from the CD image(like last
> complete session number, addr, control, start address of the first track in
> last session). How is it to be handled in virtual miniport?
>
> Thanks a lot,
> Lloyd
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

Find the first difference in the command flow between your stuff and the others (MS’s or open source) stuff.

BTW - can Linux’s (or maybe even MS’s) iSCSI target log all commands and their results to the file? If yes - then use this target, set it up properly, and use MS’s embedded iSCSI initiator in Windows for testing. Then you will have a log of commands without Windows kmode debugging.

Also: is your CD image something complex with tracks, sessions, audio etc?

Try with the dumb ISO file first.

In XP/2003 era, when I was deep in this, IIRC only READ TOC was mandatory (except the very base commands like READ CAPACITY, which is a must for the HDD too).

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

“Lloyd” wrote in message news:xxxxx@ntdev…
I have been trying to solve my CD mounting issue in Virtual Storport Miniport for some time, and still couldn’t locate the issue. Please let me explain my problem bit more clear. The first set of SCSI commands I receive when mounting the CD are -

SCSIOP_GET_EVENT_STATUS
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION
SCSIOP_GET_CONFIGURATION

Right now I have not implemented these commands and it sets Srb->SrbStatus = SRB_STATUS_ERROR. In SCSI MMC spec. I find these commands are mandatory, and I implemented them. The only difference it made to the sequence of commands i receive are “SCSIOP_GET_CONFIGURATION” called only once. I have checked the source code of other implementations like (“Arsenal Image Mounter” and “bazislib” based “WinCDEmu”), but couldn’t find them implementing these commands!

The next set of commands I receive are

SCSIOP_READ_CAPACITY
SCSIOP_MODE_SENSE
SCSIOP_READ_CAPACITY
SCSIOP_READ_CAPACITY
SCSIOP_READ (Start->0, Len->2048)
SCSIOP_READ_CAPACITY
SCSIOP_READ_CAPACITY
SCSIOP_READ_TOC
SCSIOP_XPWRITE
SCSIOP_READ (Start->32768, Len->2048)
SCSIOP_READ (Start->34816, Len->2048)
SCSIOP_READ (Start->36864, Len->2048)
SCSIOP_READ (Start->38912, Len->2048)

I am properly handling read capacity,mode sense and read (it works well for HDDs and USBs). For xpwrite commad simply sends an SRB_STATUS_SUCCESS. After these set of commands are executed, I can see this commands pattern repeating without the MODE_SENSE command.

As you can see the first READ command requests the first sector or block and it contains only zeros.
The second read command requests the block no 16, this location contains 0x 0143 4430 3031 (“.CD001…”).
The remaining three commands requests block no 17,18 and 19 respectively.

The 17th block starts with 0x 0243 4430 3031 (.CD001…). I notice the 0x02 here.
The 18th block starts with 0x FF43 4430 3031 (.CD001…). I notice the 0xFF here.

The 19th block starts with 0x 2200 1300 0000 ("…).

This is all i could understand from this. The CD image is not corrupted, it works with other tools. So far I have been guessing that storport is not getting what it expects from the READ command. I have also implemented a simple READ_TOC command handler.

If you were in my position, which method would you try to solve this issue? I read the article about “BusTrace” in recent “NT Insider”, and I wished if i had access to this tool, I could have verified the working of other tools like WinCDEmu. Is there any free (sorry for asking) alternative to Bus Trace?

Thanks a lot,
Lloyd

On Fri, Dec 5, 2014 at 6:44 PM, Maxim S. Shatskih wrote:

I wrote the virtual SCSI port/miniport stuff of my own as old as in 2003, it included the TDI client miniport which was a client of some “trivial iSCSI” (like TFTP is to FTP) protocol of my own (essentially sending CDBs, sense infos and data buffers via the single TCP connection in the simplest possible way).

The user-mode server service was on another end.

Yes, I remember that, on the OSes of that age, READ TOC was really a must for virtual CD to work (besides the other trivial mandatory stuff like INQUIRY and READ CAPACITY).

Also I remember that I’ve just emulated the simplest possible TOC with 1 track of “data” type. My goal was to mount ISO files with data remotely, and never to mount virtual audio CDs or some multi-track images (which require more sophisticated container file format then ISO).

So, with 2000, XP and 2003, the simplest possible TOC worked fine.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

“Lloyd” wrote in message news:xxxxx@ntdev…
Hi,

I am trying to mount a CD image using a virtual storport miniport driver. The first few CDB op-codes i receive are SCSIOP_READ_CAPACITY,SCSIOP_MODE_SENSE,SCSIOP_READ_CAPACITY,SCSIOP_READ (first block- 2048 bytes),SCSIOP_READ_CAPACITY and “SCSIOP_READ_TOC”.

I believe that all the commands are executed correctly (as it correctly mount HDDs) except SCSIOP_READ_TOC. in READ_TOC initially i get the “Format field” set to 1 (READ_TOC_FORMAT_SESSION). I have checked the SCSI-MMC6 (T10/1836-D rev 2g) documentation, and found the response data format to be used in table 481.

In this many of the fields are unknown to me from the CD image(like last complete session number, addr, control, start address of the first track in last session). How is it to be handled in virtual miniport?

Thanks a lot,

Lloyd

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer