Hi,
I am writing audio device drivers. This architecture has 3 dfferent drivers - 2 KMDF based drvers and 1 WDM driver. I would like to know:
-
If it is possible for a WDM driver to open a handle (file object) on a KMDF driver. I tried to open a handle and was able to successfully open it.
-
If it is possible for a WDM driver to send IRPs (custom created) to device object of the KMDF driver opened. I tried but I get a STATUS_ACCESS_DENIED.
My understanding is that - a WDM driver should be able to interaction with a KMDF driver - am I correct in my assumption here? If not then what should I be doing.
Thanks, Neetu.
Yes you can interact between the two drivers, opening a driver and
sending IRP’s to it will not change just because it is WDM or KMDF.
Your failure indicates something wrong in one of your drivers
Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
-----Original Message-----
From: xxxxx@gmail.com [mailto:xxxxx@gmail.com]
Posted At: Thursday, July 01, 2010 1:08 PM
Posted To: ntdev
Conversation: Interaction between a KMDF and WDM driver??
Subject: Interaction between a KMDF and WDM driver??
Hi,
I am writing audio device drivers. This architecture has 3 dfferent
drivers -
2 KMDF based drvers and 1 WDM driver. I would like to know:
-
If it is possible for a WDM driver to open a handle (file object) on
a KMDF
driver. I tried to open a handle and was able to successfully open it.
-
If it is possible for a WDM driver to send IRPs (custom created) to
device
object of the KMDF driver opened. I tried but I get a
STATUS_ACCESS_DENIED.
My understanding is that - a WDM driver should be able to interaction
with a
KMDF driver - am I correct in my assumption here? If not then what
should I be
doing.
Thanks, Neetu.
__________ Information from ESET Smart Security, version of virus
signature
database 5244 (20100701) __________
The message was checked by ESET Smart Security.
http://www.eset.com
xxxxx@gmail.com wrote:
I am writing audio device drivers. This architecture has 3 dfferent drivers - 2 KMDF based drvers and 1 WDM driver. I would like to know:
- If it is possible for a WDM driver to open a handle (file object) on a KMDF driver. I tried to open a handle and was able to successfully open it.
KMDF drivers are WDM drivers. KMDF is just a “layer” on top of WDM
(although a sophisticated one…).
- If it is possible for a WDM driver to send IRPs (custom created) to device object of the KMDF driver opened. I tried but I get a STATUS_ACCESS_DENIED.
Are you sending IRPs to the device object, or ioctls to the file
object? They are very different things. You should be able to send
IRP_MJ_INTERNAL_DEVICE_CONTROL IRPs to the device object using
IoCallDriver regardless of file permissions. If you are using
ZwDeviceIoControl to send to the file handle, that raises other issues.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> - If it is possible for a WDM driver to open a handle (file object) on a KMDF driver.
Yes. ZwCreateFile.
Or use IoGetDeviceObjectPointer, which is internally a sequence of:
ZwCreateFile
ObReferenceObjectByHandle
ZwClose
IoGetRelatedDeviceObject
- If it is possible for a WDM driver to send IRPs (custom created) to device object of the KMDF driver
opened. I tried but I get a STATUS_ACCESS_DENIED.
It is possible, you have some bug, probably with the security descriptor in KMDF.
Actually, the outside world just don’t know whether the driver is KMDF or not.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks for your responses. I don’t have the pointer to device object so I am using IoGetDeviceObjectPointer to extract that. Could you please point out what could be the problems related to this? Here is the code that I am using:
ntStatus = IoGetDeviceObjectPointer(&SymbolicLink, FILE_ALL_ACCESS, &pFileObject, &m_pDeviceObject);
if (NT_SUCCESS(ntStatus))
{
PIRP pIrp = NULL;
KEVENT Event;
IO_STATUS_BLOCK ioStatus;
pIrp = IoBuildDeviceIoControlRequest (IOCTL_GET_CALLBACK_INFO, m_pDeviceObject, NULL, 0, NULL, 0, TRUE, &Event, &ioStatus);
KeInitializeEvent (&Event, NotificationEvent, FALSE);
IoCopyCurrentIrpStackLocationToNext(pIrp);
ntStatus = IoCallDriver (m_pDeviceObject, pIrp);
if (ntStatus == STATUS_PENDING)
{
KeWaitForSingleObject (&Event, Executive, KernelMode, FALSE, NULL);
ntStatus = ioStatus.Status;
}
}
}
Why are you using setting InternalDeviceIoControl to true?
IRP_MJ_INTERNAL_DEVICE_CONTROL. is generally for SCSI or USB stacks, you
would need a DispatchInteralDeviceControl dispatch routine for this IRP type
in the target driver, and in general it is more usual to simply use
IRP_MJ_DEVICE_CONTROL. which ends up in the DispatchDeviceControl routine
you probably do have.
You do not need this code: IoCopyCurrentIrpStackLocationToNext(pIrp);
The target driver is your own driver right? Have you used a debugger to
trace what happens here?
Mark Roddy
On Sat, Jul 3, 2010 at 2:57 PM, wrote:
> IoGetDeviceObjectPointer
One thing that jumps out is that there is no need to call IoCopyCurrentIrpStackLocationToNext(pIrp) here.
Hi Neetu,
If you can’t get a handle to the WDF device, then device access rights are probably not allowing you to do so. For Device Access in Framework Drivers you can get more information from the following link: http://msdn.microsoft.com/en-us/library/ff540750(v=VS.85).aspx. You might want to check if the WDF device is specified as exclusive, if this is the case any previously opened file handle would prevent you from getting another file handle on the device: http://msdn.microsoft.com/en-us/library/ff546097(VS.85).aspx.
BTW since IoGetDeviceObjectPointer is taking an extra reference on the file object for you, please call ObjDereferenceObject on the returned file handle after the work is done with the file handle.
Thank you,
Neslihan
Not to beat this issue to death, but it’s a bit more serious than that. Not only do you not NEED to call it, you really CAN’T correctly call it. You don’t have a current I/O stack location when you create a new IRP. Think about it, there’s no need for you to have one, YOU’RE not going to process the request…
Sorry… at least for the archives I thought we should be clear,
Peter
OSR
Hi All,
Thanks a lot for help and guidance. I have been able to solve the problem. The problem was related to the symbolic link.
Peter, Mark, Tai-Hing - Yes, that was a copy paste mistake I corrected it immediately.
Neslihan - Yes, I am using ObjDereferenceObject for closing file object.
Don, Tim, Maxim - Thanks for providing me details on WDF and on how to open a file. It really gave me direction to solve the problem.
cheers, Neetu.
(Another satisfied customer!)