The hubwalker loops through PDO devices 0-15 and it hangs at number 11. So the device name (hub name) should be "\Device\USBPDO-11". Is that what you wanted?
I'm still trying to figure out how to step through assembly code in windbg. I just started windows in debug mode and connected windbg. In the mean time, I found the link below which suggests queuing a work item to call IoGetDeviceObjectPointer using ioallocateworkitem routine, should I give that a try? http://www.osronline.com/article.cfm?id=24 Here is a little snippet: *Figure 5 – The wrong way to write a PnP Notification Callback* * * And, while you’d be partially right, you *do* get a pointer to a device object using its name by calling *IoGetDeviceObject Pointer*, you’d also get bitten by one of the conditions of PnP Notification routines. As it very clearly states in the documentation: *A callback routine must not open the device directly. If the provider of the interface causes blocking PnP events, the notification callback routine can cause a deadlock if it tries to open the device in the callback thread.* * * When you call *IoGetDeviceObjectPointer, *you’re actually issuing an open (IRP_MJ_CREATE) for the specified device. That’s why you get back a File Object pointer, in addition to the Device Object pointer that you wanted. So, the proper thing to do is queue a work item that does the call to *IoGetDeviceObjectPointer*, as shown in *Figure 6*. On Tue, Mar 13, 2012 at 2:10 PM, Huihong Luo <[email protected]> wrote: > This api simply returns a device object from a name, and usually does not > block. What is the > device name? you can examine ObjectName unicode string. > > IoGetDeviceObjectPointer() does the following thing: > > ZwOpenFile(ObjectName) to get a handle > ObReferenceObjectByHandle(handle) to get the FileObject > IoGetRelatedDeviceObject(FileObject) to get the device object > > you can further step into the assembly code to nail down which function > call causes the lock. > > you can also list all locks using these commands in windbg: > > !locks > !deadlock > > --- On *Tue, 3/13/12, Ribhi Kamal <[email protected]>* wrote: > > > From: Ribhi Kamal <[email protected]> > Subject: Re: [vbox-dev] IoGetDeviceObjectPointer hangs vboxusbmon > To: "vbox-dev" <[email protected]> > Date: Tuesday, March 13, 2012, 10:49 AM > > > Sorry, actually the IRQL == PASSIVE_LEVEL is okay. So just ignore that bit. > > On Tue, Mar 13, 2012 at 1:27 PM, Ribhi Kamal > <[email protected]<http://us.mc1603.mail.yahoo.com/mc/[email protected]> > > wrote: > > I've been troubleshooting an issue that prevents vbox from capturing USB > devices when other specific USB devices are plugged in (i.e. Sprint USB > crap). I finally managed to track down the problem to > IoGetDeviceObjectPointer in VboxUsbMonHubDevWalk. IoGetDeviceObjectPointer > was getting called, however, it never returned. > > I'm not an expert in windows driver development so I'd like to run things > by you before I start fixing it. > > Firstly, I'm not really sure why it hangs (deadlocks?) there for some > devices and not others. However, I believe that it may be due to the fact > that some driver interfaces cause blocking PnP events. Due to that, > vboxusbmon runs into a deadlock when executing IoGetDeviceObjectPointer > because it is being used directly from a callback function, > VBoxUsbMonDeviceControl, and IRQL==PASSIVE_LEVEL. > > What led me to that conclusion is that right after > IoGetDeviceObjectPointer is executed, I start seeing lots of PnP events. > USBMon::vboxUsbMonHubDevWalk: > IoGetDeviceObjectPointer - Starting > > USBMon::VBoxUsbMonPnPHook: > VBoxUsbMonPnPHook In > > USBMon::VBoxUsbMonPnPHook: > ==>PnP: Mn(IRP_MN_QUERY_DEVICE_RELATIONS), PDO(0x8833d028), > IRP(0x882a71a8), Status(0xc00000bb) > > See attached for complete debug view. > > Are my assumptions correct? If so how would you go about fixing the > problem. > > Thanks! > > -- > -- Ribhi > > > > > -- > -- Ribhi > > -----Inline Attachment Follows----- > > _______________________________________________ > vbox-dev mailing list > [email protected]<http://us.mc1603.mail.yahoo.com/mc/[email protected]> > https://www.virtualbox.org/mailman/listinfo/vbox-dev > > -- -- Ribhi
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
