Hi,
I’m writing driver that should call some services from another driver( IOCTLS). I’m using IoGetDeviceObjectPointer to retrieve the object, IoBuildDeviceIoControlRequest and IoCallDriver to execute call. But I getting the Bugcheck 8e; The same operations go well when called from User mode application.
After some search I found, that driver creates some data and attaches it to FileObject on call of Create and uses this data on IOCtl.
Can you please recommend some standard way to do this IOCTL? Is it enough to fill pointer to FileObject( which I got on call of IoBuildDeviceIoControlRequest ) to IrpStack?
8e - KERNEL_MODE_EXCEPTION_NOT_HANDLED
call !analyze -v
you’ll see where it crashed
How do you call IoBuildDeviceIoControlRequest+IoCallDriver ?
RtlInitUnicodeString( &us, L"\Device\YourDriver");
pDO = IoGetDeviceObjectPointer( &us, FILE_READ_DATA, &pFileObject,
&pDeviceObject );
KeInitializeEvent( &event, SynchronizationEvent, FALSE );
pIrp = IoBuildDeviceIoControlRequest( IOCTL_CODE, pDeviceObject, NULL, 0,
&MyStruct, sizeof( MyStruct ), TRUE, &event, &iosb );
if ( !pIrp ) …
status = IoCallDriver( pDeviceObject, pIrp );
if ( STATUS_PENDING == status ) KeWaitForSingleObject( &event … )
-pk
wrote in message news:xxxxx@ntdev…
> Hi,
> I’m writing driver that should call some services from another driver(
> IOCTLS). I’m using IoGetDeviceObjectPointer to retrieve the object,
> IoBuildDeviceIoControlRequest and IoCallDriver to execute call. But I
> getting the Bugcheck 8e; The same operations go well when called from User
> mode application.
> After some search I found, that driver creates some data and attaches it
> to FileObject on call of Create and uses this data on IOCtl.
> Can you please recommend some standard way to do this IOCTL? Is it enough
> to fill pointer to FileObject( which I got on call of
> IoBuildDeviceIoControlRequest ) to IrpStack?
>
Just to…
I’m using the (about) same code, as you wrote. I also wrote about this. but ths code cannot work with the driver that I call because a problematic usage of file object context. I need to send file object to called driver too. This is a thing that I ask about.
Anyway, thank you for your answer.
If the driver expects the file object to be present, you need to set it your.
Irp = IoBuild(…);
IoGetNextIrpStackLocation(Irp)->FileObject = fileobject;
Now, you also said that you were using IoGetDeviceObjectPointer to retrieve the device to send the irp to. The problem with this way of getting the device object pointer and for devices that use the fileobject on each io is that IoGetDeviceObjectPointer opens the device and then closes the handle, causing an IRP_MJ_CLEANUP to be sent to the deivce. If the device actually cleans up state in IRP_MJ_CLEANUP, you cannot send your io
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Thursday, December 13, 2007 11:50 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IOCTL call from driver - problem
Just to…
I’m using the (about) same code, as you wrote. I also wrote about this. but ths code cannot work with the driver that I call because a problematic usage of file object context. I need to send file object to called driver too. This is a thing that I ask about.
Anyway, thank you for your answer.
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
Doron, thanks.
I expect, that if device created the file object on IRP_MJ_CREATE, it cleanups it on closing:(
I tried also to open the device by ZwCreateFile,but the object that I got was problematic: for example, Irp Stack size in it was 0, that led to a number of problems in build irp and IoCallDriver.
Can you recommend the way to get DeviceObject and FileOnject for my case?
Can you use the ZwCreateFile/ZwDeviceIoControl calls for you environment?
This will take care of the file object problems.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Doron, thanks.
> I expect, that if device created the file object on IRP_MJ_CREATE, it
> cleanups it on closing:(
> I tried also to open the device by ZwCreateFile,but the object that I got
> was problematic: for example, Irp Stack size in it was 0, that led to a
> number of problems in build irp and IoCallDriver.
> Can you recommend the way to get DeviceObject and FileOnject for my case?
>
may be, if ZwDeviceIoControl exists. I did not found it neither in DDK documentation no in online help.
Sorry my typo ZwDeviceIoControlFile see the WDK it is documented.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> may be, if ZwDeviceIoControl exists. I did not found it neither in DDK
> documentation no in online help.
>
Thanks. I will try to use it.
Just do what IoGetDeviceObject pointer does and skip closing the file handle immediately (e.g. close the handle when you are done using the device)
ZwOpenFile(&handle, …);
ObReferenceObjectByHandle(handle, …, IoFileObjectType,…, &fileobject);
DeviceObject = IoGetRelatedDeviceObject(fileobject)
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@intel.com
Sent: Thursday, December 13, 2007 1:27 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IOCTL call from driver - problem
may be, if ZwDeviceIoControl exists. I did not found it neither in DDK documentation no in online help.
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
ZwDeviceIoControlFile
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> may be, if ZwDeviceIoControl exists. I did not found it neither in DDK
documentation no in online help.
>
Just to finish the thread:
I tryed both of methods; Usage of ZwDeviceIoControlFile was impossible, returned status was STATUS_INVALID_HANDLE; May be because this call is legal not for all types of devices.
The second way ( Recommended by Doron ) is working;
KeInitializeEvent(&event, NotificationEvent, FALSE);
irp = IoBuildDeviceIoControlRequest( IoCtl, p_DVCEXT->HeciDeviceObject,pInputBuff, InputBufferSize,pOutputBuff , OutputBufferSize, FALSE,&event,ioStatusBlock );
if (irp == NULL)
{
status = STATUS_INSUFFICIENT_RESOURCES;
__leave ;
}
IoGetNextIrpStackLocation(irp)->FileObject = p_DVCEXT->HeciFileObject ;
status = IoCallDriver (p_DVCEXT->HeciDeviceObject, irp);
if ( NT_ERROR(status))
{
__leave ;
}
if (status == STATUS_PENDING)
{
KeWaitForSingleObject(&event, Executive, KernelMode, FALSE, NULL);
if (NT_SUCCESS(status))
status = ioStatusBlock->Status;
}
wrote in message news:xxxxx@ntdev…
> Just to finish the thread:
> I tryed both of methods; Usage of ZwDeviceIoControlFile was impossible,
> returned status was STATUS_INVALID_HANDLE; May be because this call is
> legal not for all types of devices.
Then you did something wrong, the call is legal period. I’ve used it in a
number of cases where the need to have things like a file object was
desirable, useing the call makes it easy to handle all the IRP fields
correctly for those cases where anything other than the IoBuildXXx calls
will work
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
Just to be clear, you can validate buffer length values and the presence of a buffer (e.g. != NULL), but you cannot verify the pointer value itself if it is != NULL to be valid, nor can you verify that the given buffer length corresponds to the true buffer length of the provided buffer. Since both components at the same security level, at the end you have to trust that they filled out the irp and the stack location “somewhat” correctly with respect to the buffer size set and the actual buffer size
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Sunday, December 16, 2007 6:40 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IOCTL call from driver - problem
wrote in message news:xxxxx@ntdev…
> Just to finish the thread:
> I tryed both of methods; Usage of ZwDeviceIoControlFile was impossible,
> returned status was STATUS_INVALID_HANDLE; May be because this call is
> legal not for all types of devices.
Then you did something wrong, the call is legal period. I’ve used it in a
number of cases where the need to have things like a file object was
desirable, useing the call makes it easy to handle all the IRP fields
correctly for those cases where anything other than the IoBuildXXx calls
will work
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
—
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