inside windbg, click Disassembly window, it will display assembly code, then you can set a breakpoint by click the left side of the code line.
--- On Tue, 3/13/12, Ribhi Kamal <[email protected]> wrote: From: Ribhi Kamal <[email protected]> Subject: Re: [vbox-dev] IoGetDeviceObjectPointer hangs vboxusbmon To: "Huihong Luo" <[email protected]> Cc: "vbox-dev" <[email protected]> Date: Tuesday, March 13, 2012, 12:29 PM The \Device\USBPDO-11 physical device is a sprint hub driver BcmBusCtr.SYS. But I've seen it happen with other devices as well (Apple trackpad) Will update you once I get windbg working. Thanks On Tue, Mar 13, 2012 at 3:08 PM, Ribhi Kamal <[email protected]> wrote: 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]> 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] https://www.virtualbox.org/mailman/listinfo/vbox-dev -- -- Ribhi -- -- Ribhi
_______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
