SRB_FUNCTION_CLAIM_DEVICE IoCallDriver problems with StorPort

device driver

    Sponsored Links

    Next

  • 1. USB driver development
    Hi All I'm trying to generate custom drivers for one of our usb devices. I have windows DDK and Visual Studio Installed. Has anyone got a link that demonstrates how to proceed in generating custom drivers. I'm a beginner at this and kinda lost. Pls advice Regards
  • 2. IoGetDmaAdapter NumberOfMapRegisters minus 1?
    On Wed, 26 Apr 2006 17:08:35 -0700, "Eliyas Yakub [MSFT]" < XXXX@XXXXX.COM > wrote: >In all the drivers I have written, I basically compute MaxTransferLength >based on the MapRegisters I need ( MaxTransferLength = >(maxMapRegistersRequired-1) << PAGE_SHIFT) and pass it to IoGetDmaAdpater. I saw this in an old thread. My only question is why this calculation would use (maxMapRegistersRequired-1) instead of simply maxMapRegistersRequired.
  • 3. MiniportHandleInterrupt call multiple times???
    Hi I am writing NIC driver on windows 2k uniprocessor system. I could not not understand that why MiniportHandleInterrupt is called multiple time? I understand(might be wrong) that if any DPC is running on a processsor there would not run other DPC on that processor until previous DPC is completed. Is this concept right? -- With regards thanks Anand Choubey
  • 4. Why would Vista x64 give me code 39 for my signed drivers?
    I have a KMDF USB modem driver. We are going through the process of testing it with DTM now. So, to load it on Vista x64, I signed it with our organization's Verisign certificate, following the instructions in the KMCS doc: 1) Inf2cat (the output says it grabbed the .inf, .sys, and the WDF coinstaller .dll) 2) Signtool sign the catalog file (no errors) 3) Signtool verify (says it is signed with class 3 code signing etc.) So, I take it into our lab and try to load it. Eventually it fails out with code 39. The security log in evntviewer.exe says that the hash of my .sys file is not correct or is missing. I also tried signing the .sys file itself (before or after creating and signing the catalog file), but it didn't make any difference. If I do modem properties and click the "Driver" tab, it shows modem.sys as signed, but then mydriver.sys as unsigned, and the WDF coinstaller as unsigned as well. If I actually look at the exact files it's using in Windows Explorer, the "digital signatures" tab shows that both the .sys and .dll are signed. Any ideas?

SRB_FUNCTION_CLAIM_DEVICE IoCallDriver problems with StorPort

Postby U3RldmUgVQ » Fri, 18 May 2007 02:20:01 GMT

Our RAID controller SCSIport miniport driver has been converted to the 
StorPort model, but now I'm having problems with our configuration device.  
We have a second driver that claims our configuration device "SCSI Processor 
Device" for sending commands to the RAID controller.   The config driver is 
also used to support multicard configurations and serves to relay events to 
the event log.
At startup the configuration driver spins through the \Device\ScsiPort list 
of symbolic links, finds our port, then loops through the SCSI inquiry data 
for each LUN on our port until our configuration device is found.   After 
it's found, we try create a device object for it, and that's where I run into 
trouble.  When we manufacture the irp with IOCTL_SCSI_EXECUTE_NONE, SRB to 
SRB_FUNCTION_CLAIM_DEVICE, port, target, lun of the configuration device , 
and send it down with IoCallDevice we get error 0xC0000001.   Under SCSIport 
miniport this works fine, the claim succeeds, our PDO is returned in 
Srb.DataBuffer and we use that create our control device \Device\BCConfig0. 
Any help greatly appreciated.

Re: SRB_FUNCTION_CLAIM_DEVICE IoCallDriver problems with StorPort

Postby heinz » Fri, 18 May 2007 12:54:13 GMT

Unlike scsiport, storport does not accept SRB's sent to the adapter.
Thus, you must send the claim to the processor device. Another thing
is your scanning method is legacy and you might want to modernize it
for future proofing.


Re: SRB_FUNCTION_CLAIM_DEVICE IoCallDriver problems with StorPort

Postby U3RldmUgVQ » Fri, 18 May 2007 13:48:01 GMT

Thanks Heinz, I must be on the right track now.. I got the same advice from 
Bart over in DDK support, I'm just putting those changes in now.  Thanks for 
the tips.





Re: SRB_FUNCTION_CLAIM_DEVICE IoCallDriver problems with StorPort

Postby heinz » Fri, 18 May 2007 20:04:45 GMT

Hmm, google ate my post, let me try again.

Unlike scsiport, storport does not allow SRB's sent to the adapter
object. Thus you must send your claim request to the processor device,
not to the adapter. Your scanning method of spinning through adapters
and inquiry data is also legacy and you should consider replacing that
with a more modern approach both future proofing as well as it should
facilitate the fix your original problem.


Similar Threads:

1.storport, buggy storport

In my very limited amount of work with storport, I have run into a vast
array of unexpected issues. Here are some highlights:

-The docs specify HwStorStartIo is called at DISPATCH_LEVEL yet I have
observed it called at IRQL=7.
-If read SRB's report check condition & set DataTransferLength=0,
storport crashes
-Fields in PORT_CONFIGURATION_INFORMATION are not preset to the values
the documentation says there are. For instance, ScatterGather is false,
not true. NumberOfPhysicalBreaks is 17, not unlimited. And the list
goes on. To make matters worse some of them that are wrong the docs say
not to touch so what are you supposed to do?
-Once installing the KB883646 hot fix storport, it crashes if
HW_INITIALIZATION_DATA.SrbExtensionSize is 0 (oops)

The latest DDK has a storport example (i2o). In my experience when the
docs differ from the samples, the samples are usually right because
they work. Because of this, it is really quite disappointing how
significantly i2o deviates from the docs:
-i2o imply HwStorBuildIo is required, yet the docs say it is optional
-i2o painstakingly fills in HW_INITIALIZATION_DATA VendorId's and
DeviceId's even though the docs say these are all ignored
-i2o sets numerous PORT_CONFIGURATION_INFORMATION fields the docs say
not to touch such as ScatterGather and InitiatorBusId
-i2o calls StorPortNotification(RequestComplete) which the docs say is
ignored
-and the list goes on...

The other thing is, I just can not get a PCMCIABus storport to work.
DriverEntry is called, but nothing else. The docs imply this bus is
supported. Is there a better approach versus storport? A scsi miniport
had none of these issues at all. I didn't expect trying to go the extra
mile to be such a buggy ordeal.

2.IoCallDriver problem under verifier

When my driver is invoked (under verifier, regardless of verifier settings), 
I get a bugcheck 7E (0xc0000005) in ntoskrnl.exe. This happens when my driver 
calls IoCallDriver().
Disassembly reveals that ntoskrnl is dereferencing a NULL pointer (actually 
offset by 0x98), so I assume that somehow I'm writing somewhere I shouldn't 
be, or I just don't have something configured right somewhere along the line.
I'm curious to know how IoCallDriver is handled differently under verifier 
(or if some other related call is handled differently) so I can get a better 
idea of what my problem is.
Clarifying, it isn't a problem found by verifier (wrong bugcheck for that) - 
it just turns up when verifier is enabled on my driver (even with no relevant 
verifier settings enabled)

3.Problem with IoCallDriver() in USB driver

By C rules, arrays are never passed by copying.

NTSTATUS USBBase::StartDataUrb(IN UCHAR data[4])

for the code generator is absolutely the same as

NTSTATUS USBBase::StartDataUrb(IN UCHAR * data)

So the data is passed by a true pointer.

"Doron Holan [MS]" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
> you are passing a stack based parameter to an asynchronous function (when
> this->FirstStart == FALSE)
>
> > NTSTATUS USBBase::StartDataUrb(IN UCHAR data[4])
> data is not a true pointer here, rather a passed in parameter (an array of
4
> bytes)
>


4.IoCallDriver Problem in vista, but ok in 2k/xp/2k3

Hi all:
     I have a question about power manager in my driver, could you help me 
and tell me what's the problem about it.
The driver I wrote for all windows platform, I want to turn off the monitor, 
so I build a IOCTL IRP and send it to display adapter, it can work well in 
2k/xp/2003, but when it run in vista, IoCallDriver return 
0xC0000010,STATUS_INVALID_DEVICE_HANDLE.
   The main code list below:

    RtlInitUnicodeString( &videoName, L"\\Device\\NTPNP_PCI0015" ); // this 
is adapter PDO Name, we can get it through    
"DeviceManager"->display->detail->Phy Obj Name.

    status = IoGetDeviceObjectPointer( &videoName, FILE_READ_ATTRIBUTES, 
&pFile, &pDevice );
    SIOCTL_KDPRINT((0, "IoGetDeviceObjectPointer returned %i\n", result));
    if ( status == STATUS_SUCCESS )
    {
        KeInitializeEvent( &kEvent, NotificationEvent, FALSE );

        newIrp = IoBuildDeviceIoControlRequest( 
IOCTL_VIDEO_SET_OUTPUT_DEVICE_POWER_STATE,
            pDevice,
            &mode,
            sizeof(ULONG),
            0,
            0,
            FALSE,
            &kEvent,
            &ioStatus
            );

        SIOCTL_KDPRINT((0, "IoBuildDeviceIoControlRequest returned %i\n", 
newIrp));
        if ( newIrp )
        {
            status = IoCallDriver( pDevice, newIrp );
            driverBlanked = 1;
        }
        else
        {
            result = 242;
        }
        if ( pFile )
        {
            SIOCTL_KDPRINT((0, "ObDereferenceObject being called\n"));
            ObDereferenceObject( pFile );
            pFile = 0;
        }
    }

    if ( driverBlanked )
    {
        result = 0;
    }
    SIOCTL_KDPRINT((0, "VideoSleep returns %i\n", result));
    return result;

5.MS Storport KB932755 problem?

We have a storport miniport driver sitting on top of our own bus
driver. Recently after we update OS with KB932755, we're not able to
reboot. System hangs.

I've notice the problem comes from the device power IRP of the stack
never being able to reach our bus driver to complete it. Storport
seems to try to pass the IRP to our bus driver by calling
PoCallDriver(). However the IRQL is at DISPATCH when this function
being called by storport and the IRP is lost.

According to DDK document PoCallDriver() should be at
IRQL=PASSIVE_LEVEL because our bus driver reports power IRP must in
PASSIVE level by setting DO_POWER_PAGABLE.

Did I miss anything here? Can someone from MS have a comment?

Thanks,
James

-----------------------
1: kd> kv
ChildEBP RetAddr  Args to Child
f78b2f34 8086d295 8ac8fd90 8ac8fcd8 ba20aa26 nt!PopPresentIrp+0x41
(FPO: [Non-Fpo])
f78b2f58 ba20aa26 8b220f18 8b220fd0 8b203a58 nt!PoCallDriver+0x19b
(FPO: [Non-Fpo])
f78b2f74 ba20aaad 8ac8fcd8 8b203a58 f7727a40 storport!
RaidAdapterDevicePowerstopAdapter+0x88 (FPO: [Non-Fpo])
f78b2f8c ba20285a b9f0b008 8b203a14 f78b2ff4 storport!
RaidAdapterDevicePowerDownSrbComplete+0x4d (FPO: [Non-Fpo])
f78b2f9c 808320f0 8b203a14 8b2039a0 00000000 storport!
RaidpAdapterDpcRoutine+0x28 (FPO: [Non-Fpo])
f78b2ff4 8088db27 f78ce83c 00000000 00000000 nt!KiRetireDpcList+0xca
(FPO: [Non-Fpo])
f78b2ff8 f78ce83c 00000000 00000000 00000000 nt!KiDispatchInterrupt
+0x37 (FPO: [Uses EBP] [0,0,1])
WARNING: Frame IP not in any known module. Following frames may be
wrong.
8088db27 00000000 0000000a 0083850f bb830000 0xf78ce83c
1: kd> !irql
Debugger saved IRQL for processor 0x1 -- 2 (DISPATCH_LEVEL)


6. Why call IoCompleteRequest after pass down irp by IoCallDriver

7. IoCallDriver does not return

8. IoCallDriver



Return to device driver

 

Who is online

Users browsing this forum: No registered users and 7 guest