deviceiocontrol fails for bus driver
in [Device Drivers]
|
Prev: USB suspend issues
Next: Barcode scanner problem
From: DW on 19 Sep 2006 20:10 We currently have a functional bus driver that was installed under the system class. Most of the functionality for the driver has been accessed via an API that makes ioctl calls. Recently, we've created a miniport driver to sit on top of this bus driver so that the bus driver can hook into the Windows network stack. We've installed the two drivers with a single inf, using the ndiswdm/pcidrv sample (netdrv) as a basis (the bus driver is now installed under the net class). The two drivers can communicate with each other. The API was updated so that the bus driver could be found under the net class and the file handle to the device appears to be valid. The issue is that every ioctl call from the API now fails and GetLastError() returns back 1, ERROR_INVALID_FUNCTION. What does this mean exactly? In theory, will this method of accessing the bus driver work (from both the miniport and directly from an API that issues ioctls)?
From: Eliyas Yakub [MSFT] on 20 Sep 2006 14:49 Whoa! I didn't expect somebody would do that. You have updated the lower driver (pcidrv equivalent) to be a bus driver. You are welcome to do that. Are you opening the ndis interface to talk to your bus driver? Or is your bus driver is registering another interfaces on the FDO? In either case, when the app opens the handle to the device-interface, it's going to go thru NDIS. NDIS doesn't allow random ioctls to go thru the stack. That's why you are seeing failures. So you have to workaround that by creating a control-device in your bus driver and have the app talk to that. BTW, are you using KMDF to write the bus driver. If you answer yes, you will get a personal thank you note from me. -- -Eliyas This posting is provided "AS IS" with no warranties, and confers no rights. http://www.microsoft.com/whdc/driver/tips/default.mspx
From: DW on 20 Sep 2006 17:27 Thanks for clarifying. Things are starting to make more sense now... The miniport driver is using NdisMGetDeviceProperty to get the bus driver's device object (the TargetDeviceObject). So when you say that the bus driver will need to create a control device, do you mean that a second interface should be registered (IoRegisterDeviceInterface) or do you mean that another device, perhaps with a name like "\\Device\Foo" must be created (IoCreateDevice)? (It looks like the device interface is the encouraged approach so that Windows is responsible for resolving conflicts with the symbolic names for the devices.) If the ideal solution is to register multiple device interfaces, the how would this work exactly? If the bus driver were to register an interface that only NDIS uses and another control interface that the API uses, then how would the miniport driver/NDIS be told to use a specific interface? Would this be done through the inf file or through code in the miniport driver to get the specific interface dedicated for the miniport? "Eliyas Yakub [MSFT]" wrote: > Whoa! I didn't expect somebody would do that. You have updated the lower > driver (pcidrv equivalent) to be a bus driver. You are welcome to do that. > > Are you opening the ndis interface to talk to your bus driver? Or is your > bus driver is registering another interfaces on the FDO? In either case, > when the app opens the handle to the device-interface, it's going to go thru > NDIS. NDIS doesn't allow random ioctls to go thru the stack. That's why you > are seeing failures. So you have to workaround that by creating a > control-device in your bus driver and have the app talk to that. > > BTW, are you using KMDF to write the bus driver. If you answer yes, you will > get a personal thank you note from me. > -- > -Eliyas > This posting is provided "AS IS" with no warranties, and confers no rights. > http://www.microsoft.com/whdc/driver/tips/default.mspx > >
From: DW on 20 Sep 2006 17:31 Unfortunately, we are not using KDMF. Given more time, I would have liked to look into using the newer framework/tools. "Eliyas Yakub [MSFT]" wrote: > Whoa! I didn't expect somebody would do that. You have updated the lower > driver (pcidrv equivalent) to be a bus driver. You are welcome to do that. > > Are you opening the ndis interface to talk to your bus driver? Or is your > bus driver is registering another interfaces on the FDO? In either case, > when the app opens the handle to the device-interface, it's going to go thru > NDIS. NDIS doesn't allow random ioctls to go thru the stack. That's why you > are seeing failures. So you have to workaround that by creating a > control-device in your bus driver and have the app talk to that. > > BTW, are you using KMDF to write the bus driver. If you answer yes, you will > get a personal thank you note from me. > -- > -Eliyas > This posting is provided "AS IS" with no warranties, and confers no rights. > http://www.microsoft.com/whdc/driver/tips/default.mspx > >
From: Eliyas Yakub [MSFT] on 20 Sep 2006 18:52
I mean another named device object using IoCreateDevice. Device interface is the recommended approach but when the request has to go thru port drivers or class drivers, it's upto the whims of those models to decide whether something should be allowed or not. > If the bus driver were to register an interface that > only NDIS uses and another control interface that the API uses, then how > would the miniport driver/NDIS be told to use a specific interface? You lost me here. NDIS doesn't use any interface so what do you mean by that. -- -Eliyas This posting is provided "AS IS" with no warranties, and confers no rights. http://www.microsoft.com/whdc/driver/tips/default.mspx |