Sending IOCTLs Down

NTDEV
1

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

2

It depends. It can return imediately, before IRP completion , thus before any completion routines are called, returning
STATUS_PENDING, or if the request is forced synchronous by the device you call or by a device which filters it it can return after IRP completion phase 1, and thus after the IRP is completed and completion routines are called.

The event is set in IO completion phase 1, AFTER the completion routines are called That’s it, IoCompleteRequest()
will first unwind the irp stack locations, calling completion routines one by one. If any of those processing routines
returns STATUS_MORE_PROCESSING_REQUIRED , IoCompleteRequest will imediately abort completion processing,
thus will not free the IRP, signal the user event, and so on.

> the completion of the completion routines.

What do you mean by this ?

> technically DDK docs are correct when they say the event will be signaled when the lower driver completed opeartion. Maybe a bit unclear but correct.

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 11:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

3

And lets not forget this material, it will help you clean all your doubts regarding IoCompletion.

http://www.osr.com/ntinsider/1997/iocomp/iocomp.htm

Ciao, Dan

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 11:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

4

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

I’m not sure why the USB stack is returning a status like this. I use this routine for a bunch of different URBs however this “error” always happens on the same one, and only if more than one of my USB devices is plugged in. To add to things, if you step through the code or add debugging messages between the call to IoCallDriver and the wait, the problem disappears. That why I asked about when IoCallDriver returns and what causes the event to signal. I thought that maybe the event was being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a status of 0. If you change the IOStatus.Status value from the -1073741823 to 0 (from windbg) and let the routine succeed. All goes well as if it had been 0 in the first place. I tried running a free build of my driver and the exact same results appear. I also added verifier to the USB stack drivers to see if anything would happen, but nothing has so far.

Is this a valid status value defined in the USB headers that I don’t know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

5

** Reply to message from “Chris Dore” on Fri, 5 Jul
2002 10:08:40 -0400

> Here’s the problem I am experiencing with this routine:
>
> IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

(snip)

> Is this a valid status value defined in the USB headers that I don’t know of?

Use the HEX representation of this signed ULONG value and you’ll see that it
is actually:

#define STATUS_UNSUCCESSFUL ((NTSTATUS)0xC0000001L)

Of course, that status code is pretty vague :-).

Sincerely,

Chris Myers
Senior Project Engineer
Quatech, Inc.

6

Just set your debugger to actualy dipslay hex, not frustrating decimal values. Then open ntstatus.h and map it to whatever error code is. This particular status is very common. Keep in mind NTSTATUS is a LONG in fact. so negative values are OK , and cool.

Ciao

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Friday, July 05, 2002 5:08 PM
Subject: [ntdev] Re: Sending IOCTLs Down

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

I’m not sure why the USB stack is returning a status like this. I use this routine for a bunch of different URBs however this “error” always happens on the same one, and only if more than one of my USB devices is plugged in. To add to things, if you step through the code or add debugging messages between the call to IoCallDriver and the wait, the problem disappears. That why I asked about when IoCallDriver returns and what causes the event to signal. I thought that maybe the event was being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a status of 0. If you change the IOStatus.Status value from the -1073741823 to 0 (from windbg) and let the routine succeed. All goes well as if it had been 0 in the first place. I tried running a free build of my driver and the exact same results appear. I also added verifier to the USB stack drivers to see if anything would happen, but nothing has so far.

Is this a valid status value defined in the USB headers that I don’t know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

7

Ahhhhh. I got too focused on thinking it was an invalid value!! Thanks, Now
I’m not suspecting the USB stack (at least not as much :slight_smile:

Thanks a lot.

----- Original Message -----
From: “Chris Myers”
To: “NT Developers Interest List”
Sent: Friday, July 05, 2002 9:44 AM
Subject: [ntdev] Re: Sending IOCTLs Down

> ** Reply to message from “Chris Dore” on Fri, 5
Jul
> 2002 10:08:40 -0400
>
>
> > Here’s the problem I am experiencing with this routine:
> >
> > IoCallDriver returns pending, the wait occurs, then IOStatus.Status
= -1073741823
>
> (snip)
>
> > Is this a valid status value defined in the USB headers that I don’t
know of?
>
> Use the HEX representation of this signed ULONG value and you’ll see that
it
> is actually:
>
> #define STATUS_UNSUCCESSFUL ((NTSTATUS)0xC0000001L)
>
>
> Of course, that status code is pretty vague :-).
>
> Sincerely,
>
> Chris Myers
> Senior Project Engineer
> Quatech, Inc.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@connecttech.com
> To unsubscribe send a blank email to %%email.unsub%%

8

Thanks for the read. The “Roll Your Own” article was also helpful.

Chris
----- Original Message -----
From: Dan Partelly
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:47 PM
Subject: [ntdev] Re: Sending IOCTLs Down

And lets not forget this material, it will help you clean all your doubts regarding IoCompletion.

http://www.osr.com/ntinsider/1997/iocomp/iocomp.htm

Ciao, Dan

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 11:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

9

try .enable_long_status 1 in kd or windbg to get it to display signed
long values as hex.

-p
-----Original Message-----
From: Dan Partelly [mailto:xxxxx@rdsor.ro]
Sent: Friday, July 05, 2002 7:59 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Sending IOCTLs Down

Just set your debugger to actualy dipslay hex, not frustrating decimal
values. Then open ntstatus.h and map it to whatever error code is. This
particular status is very common. Keep in mind NTSTATUS is a LONG in
fact. so negative values are OK , and cool.

Ciao

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Friday, July 05, 2002 5:08 PM
Subject: [ntdev] Re: Sending IOCTLs Down

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status =
-1073741823

I’m not sure why the USB stack is returning a status like this. I use
this routine for a bunch of different URBs however this “error” always
happens on the same one, and only if more than one of my USB devices is
plugged in. To add to things, if you step through the code or add
debugging messages between the call to IoCallDriver and the wait, the
problem disappears. That why I asked about when IoCallDriver returns and
what causes the event to signal. I thought that maybe the event was
being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a
status of 0. If you change the IOStatus.Status value from the
-1073741823 to 0 (from windbg) and let the routine succeed. All goes
well as if it had been 0 in the first place. I tried running a free
build of my driver and the exact same results appear. I also added
verifier to the USB stack drivers to see if anything would happen, but
nothing has so far.

Is this a valid status value defined in the USB headers that I don’t
know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB,
pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned
status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE,
NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after
all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed
something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have
completed the requested operation. But to what extent does completed
mean? Just the call to IoCompleteRequest or also the completion of the
completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to %%email.unsub%%

10

Is there a way I can determine why the USB stack is returning STATUS_UNSUCCESSFUL? I need more information as to why it is failing.

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Friday, July 05, 2002 10:08 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

I’m not sure why the USB stack is returning a status like this. I use this routine for a bunch of different URBs however this “error” always happens on the same one, and only if more than one of my USB devices is plugged in. To add to things, if you step through the code or add debugging messages between the call to IoCallDriver and the wait, the problem disappears. That why I asked about when IoCallDriver returns and what causes the event to signal. I thought that maybe the event was being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a status of 0. If you change the IOStatus.Status value from the -1073741823 to 0 (from windbg) and let the routine succeed. All goes well as if it had been 0 in the first place. I tried running a free build of my driver and the exact same results appear. I also added verifier to the USB stack drivers to see if anything would happen, but nothing has so far.

Is this a valid status value defined in the USB headers that I don’t know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

11

Debug it . Make good use of OS symbols, dont just keep them on your harddrive.

Ciao , Dan
----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Tuesday, July 09, 2002 12:02 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Is there a way I can determine why the USB stack is returning STATUS_UNSUCCESSFUL? I need more information as to why it is failing.

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Friday, July 05, 2002 10:08 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

I’m not sure why the USB stack is returning a status like this. I use this routine for a bunch of different URBs however this “error” always happens on the same one, and only if more than one of my USB devices is plugged in. To add to things, if you step through the code or add debugging messages between the call to IoCallDriver and the wait, the problem disappears. That why I asked about when IoCallDriver returns and what causes the event to signal. I thought that maybe the event was being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a status of 0. If you change the IOStatus.Status value from the -1073741823 to 0 (from windbg) and let the routine succeed. All goes well as if it had been 0 in the first place. I tried running a free build of my driver and the exact same results appear. I also added verifier to the USB stack drivers to see if anything would happen, but nothing has so far.

Is this a valid status value defined in the USB headers that I don’t know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

12

If the return values had a meaning or error messages were logged somewhere it would be much better. If the returns/status’ were well documented it would probably save a lot of time. Seems wasteful for people to dig around figuring out what went wrong when the original designers could probably document everything they need to know in order to determine what exactly failed. STATUS_UNSUCCESSFUL doesn’t say much when there is nothing telling me what error conditions generate it.

Just my nickels worth, Chris

----- Original Message -----
From: Dan Partelly
To: NT Developers Interest List
Sent: Monday, July 08, 2002 5:40 PM
Subject: [ntdev] Re: Sending IOCTLs Down

Debug it . Make good use of OS symbols, dont just keep them on your harddrive.

Ciao , Dan
----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Tuesday, July 09, 2002 12:02 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Is there a way I can determine why the USB stack is returning STATUS_UNSUCCESSFUL? I need more information as to why it is failing.

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Friday, July 05, 2002 10:08 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

I’m not sure why the USB stack is returning a status like this. I use this routine for a bunch of different URBs however this “error” always happens on the same one, and only if more than one of my USB devices is plugged in. To add to things, if you step through the code or add debugging messages between the call to IoCallDriver and the wait, the problem disappears. That why I asked about when IoCallDriver returns and what causes the event to signal. I thought that maybe the event was being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a status of 0. If you change the IOStatus.Status value from the -1073741823 to 0 (from windbg) and let the routine succeed. All goes well as if it had been 0 in the first place. I tried running a free build of my driver and the exact same results appear. I also added verifier to the USB stack drivers to see if anything would happen, but nothing has so far.

Is this a valid status value defined in the USB headers that I don’t know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

13

STATUS_UNSUCCESFULL is a generic error code, which is seldom returned. Most of the status codes are named
excelent, and their name is self explanatory. It would be a titanic work to document every possible status code
which can be returned as a result of an IO request sent down to a device stack, and tell you exactly why this happend, even if we take in account drivers which are bundled with the operating system. But dont forget that the IO manager has a layered design, and any 3rd party filter device in the device stack can fail a IO request operation for whatever reason, and return a phantasmagoric error code.

Frankly , it doesnt worth the effort.

Dan
----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Tuesday, July 09, 2002 6:02 PM
Subject: [ntdev] Re: Sending IOCTLs Down

If the return values had a meaning or error messages were logged somewhere it would be much better. If the returns/status’ were well documented it would probably save a lot of time. Seems wasteful for people to dig around figuring out what went wrong when the original designers could probably document everything they need to know in order to determine what exactly failed. STATUS_UNSUCCESSFUL doesn’t say much when there is nothing telling me what error conditions generate it.

Just my nickels worth, Chris

----- Original Message -----
From: Dan Partelly
To: NT Developers Interest List
Sent: Monday, July 08, 2002 5:40 PM
Subject: [ntdev] Re: Sending IOCTLs Down

Debug it . Make good use of OS symbols, dont just keep them on your harddrive.

Ciao , Dan
----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Tuesday, July 09, 2002 12:02 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Is there a way I can determine why the USB stack is returning STATUS_UNSUCCESSFUL? I need more information as to why it is failing.

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Friday, July 05, 2002 10:08 AM
Subject: [ntdev] Re: Sending IOCTLs Down

Here’s the problem I am experiencing with this routine:

IoCallDriver returns pending, the wait occurs, then IOStatus.Status = -1073741823

I’m not sure why the USB stack is returning a status like this. I use this routine for a bunch of different URBs however this “error” always happens on the same one, and only if more than one of my USB devices is plugged in. To add to things, if you step through the code or add debugging messages between the call to IoCallDriver and the wait, the problem disappears. That why I asked about when IoCallDriver returns and what causes the event to signal. I thought that maybe the event was being signaled before the USB stack has finished.

Also, it is does not always happen. Sometimes it gets through with a status of 0. If you change the IOStatus.Status value from the -1073741823 to 0 (from windbg) and let the routine succeed. All goes well as if it had been 0 in the first place. I tried running a free build of my driver and the exact same results appear. I also added verifier to the USB stack drivers to see if anything would happen, but nothing has so far.

Is this a valid status value defined in the USB headers that I don’t know of?
Any thoughts/suggestions?

Thanks, Chris

----- Original Message -----
From: Chris Dore
To: NT Developers Interest List
Sent: Thursday, July 04, 2002 4:17 PM
Subject: [ntdev] Sending IOCTLs Down

In the following procedure:

NTSTATUS CallUSBD (IN PDEVICE_OBJECT pDevObject, IN PURB pUrb)
{
NTSTATUS Status;
PIRP pIrp;
KEVENT Event;
IO_STATUS_BLOCK IOStatus;
PIO_STACK_LOCATION pNextStack;

PAGED_CODE ();

KeInitializeEvent(&Event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest (IOCTL_INTERNAL_USB_SUBMIT_URB, pDevObject,
NULL, 0, NULL, 0, TRUE, &Event, &IOStatus);

// Call the class driver to perform the operation. If the returned status
// is PENDING, wait for the request to complete.

pNextStack = IoGetNextIrpStackLocation (pIrp);
pNextStack->Parameters.Others.Argument1 = pUrb;

Status = IoCallDriver (pDevObject, pIrp);

if (Status == STATUS_PENDING)
KeWaitForSingleObject (&Event, Suspended, KernelMode, FALSE, NULL);
else
IOStatus.Status = Status;

// USBD maps the error code for us
Status = IOStatus.Status;
return (Status);
}

When does IoCallDriver return? Upon completion of the IRP?
Further more, when does the Event get signaled? Upon Completion or after all completion routines have executed?

I couldn’t seem to find concrete answers in the DDK (if I missed something please let me know where it is in the DDK).
The DDK says the event is signaled when the lower driver(s) have completed the requested operation. But to what extent does completed mean? Just the call to IoCompleteRequest or also the completion of the completion routines.

Thanks, Chris

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@connecttech.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@rdsor.ro
To unsubscribe send a blank email to %%email.unsub%%