Virtual CD Burner device driver, need answers from SCSI port GURU's

NTDEV
1

Hi All,

Don’t laugh and don’t ask why I need this as I am bound with NDA

I develop a virtual cd burner device driver basing on SCSI miniport. I used to develop a CD/DVD ROM virtual device driver and it works fine, but I have a really weird problem with the burning device driver.

Basically it works fine when writing disks from Nero, but fails when burning disks from iTunes. For some reasons MMC command “Write” never comes to my StartIO routine, though some monitoring tools show that this command is sent and completed with a error. So I guess that SCSI port fails this command but I do not know why this may happen, can SCSI port monitor MMC commands and process them itself without passing to miniport?

Again please note that basically burning disks from WMP and Nero works

Thank you in advance,
Roman

2

Roman Kudinov wrote:

Don’t laugh and don’t ask why I need this as I am bound
with NDA

Hmm…

Basically it works fine when writing disks from Nero, but fails when
burning disks from iTunes.

I don’t think anyone here is going to help you crack iTunes DRM.

3

I haven’t used the iTunes product, but what a lot of these CD burning
products do is hijack the normal I/O stack and pump data directly into the
PDO.

BAD driver writers! BAD!! NOOOOOO!

Anyway, what is probably happening is ITunes is calling IoCallDriver with
the PDO instead of the next lower DeviceObject (your driver’s DeviceObject)
when passing down the SCSI data and thus your driver gets bypassed entirely.
Kind of screws up the whole driver model nicely doesn’t it?

Bill M.

wrote in message news:xxxxx@ntdev…
> Hi All,
>
> Don’t laugh and don’t ask why I need this as I am bound with NDA
>
> I develop a virtual cd burner device driver basing on SCSI miniport. I
> used to develop a CD/DVD ROM virtual device driver and it works fine, but
> I have a really weird problem with the burning device driver.
>
> Basically it works fine when writing disks from Nero, but fails when
> burning disks from iTunes. For some reasons MMC command “Write” never
> comes to my StartIO routine, though some monitoring tools show that this
> command is sent and completed with a error. So I guess that SCSI port
> fails this command but I do not know why this may happen, can SCSI port
> monitor MMC commands and process them itself without passing to miniport?
>
> Again please note that basically burning disks from WMP and Nero works
>
>
> Thank you in advance,
> Roman
>

4

Bill,

Thank you for your answer, but how does bus hound work in this case? It intercepts WRITE command, so I believe I/O stack isn’t hijacked.

Thank you,
Roman

5

BusHound is hook-based driver. It layers just about SCSIPORT (or monolithic SCSI port) driver. That’s why
it does see everything.

Regards,
Anton Kolomyeytsev

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rbcmail.ru
Sent: Tuesday, April 22, 2008 1:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual CD Burner device driver, need answers from SCSI port GURU’s

Bill,

Thank you for your answer, but how does bus hound work in this case? It intercepts WRITE command, so I believe I/O stack isn’t hijacked.

Thank you,
Roman

NTDEV is sponsored by OSR

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

6

Anton,

Are you sure about BusHound? I checked how it is registered in the system, it is registered under group 4D36E97B-E325-11CE-BFC1-08002BE10318 (SCSI and RAID controllers) as a lower filter.

So now I think about an approach to develop a simple lower filter that would handle WRITE command sent to our device. Do you think it will work?

Thank you,
Roman

7

It doesn’t matter how they’re installed, once the driver is running they can
do whatever they want.

I don’t know anything about BusHound, but I wouldn’t be inclined to disagree
with Anton on this. If you want to verify for yourself just look at the
driver object for the adapter in the debugger.

Of course, this is wildly off topic from your initial problem report, which
was writes not being delivered to your miniport. I don’t think that anyone
is going to be able to answer this for you given the information supplied.
The best way to solve this problem is going to be to trace the flow of the
IRP/SRB through the port driver wrapper until you’ve located where it is
being rejected. Painful, but effective.

-scott

–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> Anton,
>
> Are you sure about BusHound? I checked how it is registered in the system,
> it is registered under group 4D36E97B-E325-11CE-BFC1-08002BE10318 (SCSI
> and RAID controllers) as a lower filter.
>
> So now I think about an approach to develop a simple lower filter that
> would handle WRITE command sent to our device. Do you think it will work?
>
> Thank you,
> Roman
>

8

Yes I am.

Probably. But not for the hook-based filters. So it will not see any SCSI traffic for quite a lot of the software.

Regards,
Anton A. Kolomyeytsev

CEO, Rocket Division Software

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@rbcmail.ru
Sent: Thursday, April 24, 2008 8:10 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Virtual CD Burner device driver, need answers from SCSI port GURU’s

Anton,

Are you sure about BusHound? I checked how it is registered in the system, it is registered under group 4D36E97B-E325-11CE-BFC1-08002BE10318 (SCSI and RAID controllers) as a lower filter.

So now I think about an approach to develop a simple lower filter that would handle WRITE command sent to our device. Do you think it will work?

Thank you,
Roman

NTDEV is sponsored by OSR

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

9

I’ve done further investigation on this problem and found that WRITE command is failed by SpSendPassThrough. Unfortunately this function is pretty big, so more detailed disassembly takes much time. Probably someone could give me some hints on how to perform the debugging of this function?

Thank you,
Roman

10

I found what is wrong, here is a snippet of assembly code from SpSendPassThrough

add eax,esi ;eax=0, esi=813af000 - address of the data buffer
and eax,0FFFh ;as a result eax=0
lea ecx,[eax+edi+0FFFh] ;0 + (edi=f810) + fff; edi - size of the data buffer
shr ecx,0Ch ;as a result ecx=10H, e.g. data buffer occupies 16 pages
mov eax,dword ptr [ebp+8] ;some pointer
cmp ecx,dword ptr [eax+230h] ;ecx=10, some value = 8, e.g. cmp 10H, 8
ja SCSIPORT!SpSendPassThrough+0x8b (f946dc53) ;goto error

as it comes from the debugging, SpSendPassThrough fails the command because data buffer occupies more than 8 pages. If I manually modify ecx to 8, then this check passes fine and my miniport receives the command.

Is there any place in miniport where I should specify the amount of pages? There is a code some lines below in SpSendPassThrough that checks the buffer size with 0x0000ffff, this check passes fine. I gues it checks with the MaximumTransferLength which I set in FindAdapter

if ((pPortConfigInfo->MaximumTransferLength+1) == 0)
pPortConfigInfo->MaximumTransferLength = 0xffff;

Is there a similar field for the amount of pages?

Thank you,
Roman

11

NumberOfPhysicalBreaks

xxxxx@rbcmail.ru
Sent by: xxxxx@lists.osr.com
05/08/2008 11:22 AM
Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
RE:[ntdev] Virtual CD Burner device driver, need answers from SCSI port
GURU’s

I found what is wrong, here is a snippet of assembly code from
SpSendPassThrough

add eax,esi ;eax=0, esi=813af000
- address of the data buffer
and eax,0FFFh ;as a
result eax=0
lea ecx,[eax+edi+0FFFh] ;0 + (edi=f810) +
fff; edi - size of the data buffer
shr ecx,0Ch ;as a
result ecx=10H, e.g. data buffer occupies 16 pages
mov eax,dword ptr [ebp+8] ;some pointer
cmp ecx,dword ptr [eax+230h] ;ecx=10, some value = 8, e.g. cmp
10H, 8
ja SCSIPORT!SpSendPassThrough+0x8b (f946dc53) ;goto
error

as it comes from the debugging, SpSendPassThrough fails the command
because data buffer occupies more than 8 pages. If I manually modify ecx
to 8, then this check passes fine and my miniport receives the command.

Is there any place in miniport where I should specify the amount of pages?
There is a code some lines below in SpSendPassThrough that checks the
buffer size with 0x0000ffff, this check passes fine. I gues it checks with
the MaximumTransferLength which I set in FindAdapter

if ((pPortConfigInfo->MaximumTransferLength+1) == 0)
pPortConfigInfo->MaximumTransferLength = 0xffff;

Is there a similar field for the amount of pages?

Thank you,
Roman

—
NTDEV is sponsored by OSR

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

12

Yes, I checked this field, NumberOfPhysicalBreaks is set to 17 by default by SCSI port.

Thank you,
Roman

13

I see a weird situation: as it comes from the description of SplitTransferRequest of class drivers: “…storage class drivers are responsible for splitting all transfer requests that exceed the HBA’s capability to transfer data. In other words, a class driver’s DispatchReadWrite routine must determine whether each IRP requests a transfer that is more than the HBA can handle in a single transfer operation”.

So I shouldn’t get in this situation because CDRom class driver had to split the 16-page request to two 8-page requests, shouldn’t it?

Another strange thing is that NumberOfPhysicalBreaks I return in FindAdapter does not affect the value I see in the debugger. Here is a little bit more detailed assembly code

cmp ecx,dword ptr [eax+230h] ;cmp 10H, 8H
ja SCSIPORT!SpSendPassThrough+0x8b (f946dc53)
cmp dword ptr [eax+22Ch],edi ;cmp FFFFH, F810H
jb SCSIPORT!SpSendPassThrough+0x8b (f945bc53)

The second “cmp” would pass fine and this FFFFH value is exactly the same I set in MaximumTransferLength, e.g. if I change MaximumTransferLength then this value is also changed. If you look at the addresses you will notice that FFFFH (actually 0000FFFFH) is stored in memory right before 8H (actually 00000008H), thus this 8H is definitely NumberOfPhysicalBreaks.

So the questions are:

  1. Why NumberOfPhysicalBreaks returned in FindAdapter may not affect the value I see in the debugger
  2. Why CDROM class driver may not check buffer size against this value and do not split the requests. Or probably it may have another value in its device extension?

Thanks,
Roman

14

The fix of my issue is described in the last post at
http://www.osronline.com/showThread.cfm?link=94869

15

Lovely! I am sure that is documented right…LOL.

Good find.

Bill M.

wrote in message news:xxxxx@ntdev…
> The fix of my issue is described in the last post at
> http://www.osronline.com/showThread.cfm?link=94869
>