That was why I asked my other questions. I am guessing a second handle is being opened that does not open a pipe via the device’s namespace and that is going down this path.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Saturday, March 03, 2012 8:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] DispatchReadWrite return invalid handle…
I’ve seen a lot of code in the old WDM PNP drivers devoted to pending IRPs that come in before initialization is complete, and code in the start handler to dequeue them. I always thought this was something the I/O Manager should have done, and it sounds like it is doing it. Apparently this code is only needed during bus reconfiguration, after a stop, which was unclear from the code examples. Thanks for the info.
However, it stll suggests that the code that is supposed to set the FsContext is either not executing, or is executing incorrectly, so that’s the first place I’d look. If it IS being set correctly, I’d put breakpoints in all the places that set it to NULL, to see if it is being inadvertently reset. I’m surprised the OP did not indicate that either technique had been tried.
joe
You can’t open a handle on the stack until the start irp successfully
completes back to the pnp manager so you don’t need to handle and pend
the pre start case.
d
debt from my phone
From: xxxxx@flounder.com
Sent: 3/3/2012 6:55 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] DispatchReadWrite return invalid handle…
I’d check to see where the FsContext is set, and most likely I’d try
putting a breakpoint somewhere in that function.
Note that the USB example for WDM is non-compliant because it doen’t
pend IRPs that come in before IRP_MJ_PNP:IRP_MN_START_DEVICE, so it
mught be the case that an IRP gets processed before device
initialization is complete. But, it might also mean that the code
that was executed doesn’t see the endpoint as a bulk pipe, and therefore fails to set the FsContext.
It doesn’t do any good to report where the problem was detected,
because all you are telling us is that there is a problem somewhere
else in the code. Go look for that somewhere else.
joe
> Hello guys,
>
> I got issues with read and write to USB device…After tracing the
> code, I found out this excerpt of code return the invalid handle coz
> by fileObject->FsContext is null. How do i rectify this problem. Any
> ideas.
> FYI, the device already open coz got valid handle after invoking the
> Createfile function.
>
> if(fileObject && fileObject->FsContext) {
>
> pipeInformation = fileObject->FsContext;
>
> if(UsbdPipeTypeBulk != pipeInformation->PipeType) {
>
> BulkUsb_DbgPrint(1, (“Usbd pipe type is not bulk\n”));
>
> ntStatus = STATUS_INVALID_HANDLE;
> goto BulkUsb_DispatchReadWrite_Exit;
> }
> }
> else {
>
> BulkUsb_DbgPrint(1, (“Invalid handle\n”));
>
> ntStatus = STATUS_INVALID_HANDLE;
> goto BulkUsb_DispatchReadWrite_Exit;
> }
>
> —
> 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
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
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
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