Hello:

I have a driver that created a control device object and will create an
another virtual device on demand. Each virtual device has a worker
thread to process the IRP that sent to it. The user mode application
can sent IOCTL to the control device object and these virtual device
objects.
This driver also register PnP notifcation by calling
IoRegisterPlugPlayNotification, and in callback function I will build
an IRP_MJ_INTERNAL_DEVICE_CONTROL and send to some virtual device
object. I can get the virtual device object since its created by
myself, but I fail to send this IRP to this virtual device, the return
code of IoCallDriver is 0xC0000010 (INVALID_DEVICE).
Below is the send IRP code snippet, is there any sight that I could dig
into, thanks.

VOID SendInternalIoctl(IN PDEVICE_OBJECT pDeviceObject, IN ULONG uCode)
{
KEVENT event;
IO_STATUS_BLOCK iostatus;
PIRP pIrp;
NTSTATUS status;

KeInitializeEvent(&event, NotificationEvent, FALSE);

pIrp = IoBuildDeviceIoControlRequest(uCode,

pDeviceObject,
NULL, 0, NULL, 0,
TRUE,
&event, &iostatus);

if (pIrp)
status = IoCallDriver(ptarget_object, pIrp);
else
MYDEBUG(TRACE_ERROR, "IoBuildDeviceIoControlRequest error!\n");

if (status == STATUS_PENDING)
{
MYDEBUG(TRACE_ENTRY, "IoCallDriver return pending.\n");
KeWaitForSingleObject(&event,
Executive,
KernelMode,
FALSE,
NULL);
}
else
{
MYDEBUG(TRACE_ENTRY,
"SendInternalIoctl return with status = 0x%x.\n", status);
}
}

Well I assume you have modified your code that you presented, but if not the
obvious answer is you do the IoCallDriver with ptarget_object but everything
else is pDeviceObject.

The real question is why do this in the first place, you are doing a lot of
work to call a different routine in your same driver. Using IRP's for this
communication seems way wasteful.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply




"Nike" <nikechen@seed.net.tw> wrote in message
news:1133879861.383899.116800@g43g2000cwa.googlegr oups.com...

Well I assume you have modified your code that you presented, but if not the
obvious answer is you do the IoCallDriver with ptarget_object but everything
else is pDeviceObject.

The real question is why do this in the first place, you are doing a lot of
work to call a different routine in your same driver. Using IRP's for this
communication seems way wasteful.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply




"Nike" <nikechen@seed.net.tw> wrote in message
news:1133879861.383899.116800@g43g2000cwa.googlegr oups.com...

1. Your status is left uninitialized if IRP creation fails.
2. You send your IRP to a different device object than you create it for.
3. If STATUS_PENDING was returned, you lose the final status of the IRP (it
is in iostatus.Status)

"Nike" <nikechen@seed.net.tw> wrote in message
news:1133879861.383899.116800@g43g2000cwa.googlegr oups.com...

Don:

It's typo, the ptarget_object is actually the pDeviceObject. I do this
since this IOCTL IRP will reference the handle that worker thread had
opened, and I have to queue this IRP to this worker thread. Is there
any design alternatives that I could study, thanks.

Dear all:

I've fixed this bug, it's due to the IoCallDriver will verify the
device type when the IOCTL IRP is IRP_MJ_INTERNAL_DEVICE_CONTROL, if
the IOCTL code you send to is not the right device type, the
IoCallDriver will return 0xC0000010.

IoCallDriver does no validation of IRP_MJ code and the device type.
whatever you did fixed the issue, but it wasn't b/c you are now passing some
validation code in the kernel.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Nike" <nikechen@seed.net.tw> wrote in message
news:1134099531.570850.44990@g47g2000cwa.googlegro ups.com...

But I just changed the InternalDeviceIoControl flag to FALSE when
calling IoBuildDeviceIoControlRequest to force to build
IRP_MJ_DEVICE_CONTROL IRP, instead of IRP_MJ_INTERNAL_DEVICE_CONTROL,
then everything is fine. The device type of passing IOCTL is not the
same as my device. so I guess the IoCallDriver will check the device
type when the issued IRP is IRP_MJ_INTERNAL_DEVICE_CONTROL, but
IRP_MJ_DEVICE_CONTROL will not, please advise this assumption, thanks.

You should provide IRP_MJ_INTERNAL_DEVICE_CONTROL handler in your driver.
Check your DriverEntry, what it fills into
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL].

"Nike" <nikechen@seed.net.tw> wrote in message
news:1134113440.817368.19350@g49g2000cwa.googlegro ups.com...