[wdmaudiodev] Re: Need audio driver deivce interface registration help!
- From: Anthony Palomba <APalomba@xxxxxxxxxxxx>
- To: "'wdmaudiodev@xxxxxxxxxxxxx'" <wdmaudiodev@xxxxxxxxxxxxx>,'Walter Oney' <waltoney@xxxxxxxxxxxx>
- Date: Fri, 17 Jan 2003 09:36:43 -0600
I have a sneaky suspicion that the IRP_MJ_CREATE is not making it to
portclass.
When ZwCreateFile is called, it returns STATUS_OBJECT_NAME_NOT_FOUND, but
IoStatusBlock.Information is not set to any value.
That is to say:
IoStatusBlock.Information = 0xdeadbeef;
RtlInitUnicodeString(&Ustr, SymbolicLink);
InitializeObjectAttributes(&oa, &Ustr, OBJ_CASE_INSENSITIVE, NULL, NULL);
Status = ZwCreateFile(FileHandle, GENERIC_READ | GENERIC_WRITE, &oa,
&IoStatusBlock, NULL, FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ|FILE_SHARE_WRITE,
FILE_OPEN, 0, NULL, 0);
IoStatusBlock.Information is still 0xdeadbeef! If it had made it to
portclass
would portclass have not set IoStatusBlock.Information?
Thank you for your feedback.
Anthony
-----Original Message-----
From: Walter Oney [mailto:waltoney@xxxxxxxxxxxx]
Sent: Friday, January 10, 2003 12:11 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Need audio driver deivce interface registration
help!
Anthony Palomba wrote:
> FOOBAR_DEVICE_INTERFACE is a guid that my audio driver registers as an
> interface with IoRegisterDeviceInterface. It then enables it with
> IoSetDeviceInterfaceState. When we call IoGetDeviceInterfaces from my
> external driver we get a list of symbolic names. Each name is
> separated by a NULL terminator with the whole list ending with an
> extra NULL terminator. My code only handles the first entry in the
> list, which is all right because we are the only device using this
> interface. So the link between my audio driver and the registered
> interface definitely exists because I am getting my devices symbolic
> name. The question is, where is ZwCreateFile looking to resolve the
> symbolic name?
I don't understand why there would be more than one entry in the list given
that it's your interface GUID, but never mind. Out of curiosity, how are you
getting the PDO address that you specify in your call to
IoRegisterDeviceInterface?
I think you'll need to trace the IRP_MJ_CREATE handler for your own driver
object to see what's happening. You may find that KS.SYS is rejecting it.
This could happen because KS expects additional name components to tell it
exactly what sort of entity associated with the filter is being opened.
If this is the case, you'll have to do something fairly sleazy. Namely,
after you make your registration call in DriverEntry, record the address of
the MajorFunction[IRP_MJ_CREATE] pointer in a global static variable. Then
plug in your own dispatch pointer. When you see an IRP that looks like it's
aimed at you, process it yourself. Delegate all other IRPs to the dispatch
function you've remembered.
All of the class drivers I have seen have just one dispatch routine for each
type of IRP. Thus, you shouldn't need to worry that KS will be using
different dispatch routines for different device objects.
--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars Check out our
schedule at http://www.oneysoft.com
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.de/
******************
WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
http://www.wdmaudiodev.de/
Other related posts:
