Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Go Back   OSR Online Lists > windbg
Welcome, Guest
You must login to post to this list
  Message 1 of 3  
11 Jul 06 10:49
lallous
xxxxxx@lgwm.org
Join Date: 09 Sep 2004
Posts To This List: 10
Break on driver load

Hello Some PNP drivers are loaded and unloaded when the hardware is plugged/unplugged. Is there is a way to (1) set breakpoints (say @ driver_base+0x1020) (2) display the dispatch table of those drivers as they become ready? I don't have source code of these drivers, but some drivers are from MS whose PDBs are avail. Please advise. -- Elias
  Message 2 of 3  
11 Jul 06 11:02
windbg member 29598
xxxxxx@microsoft.com
Join Date:
Posts To This List: 11
Break on driver load

Use "bu" breakpoints intead of "bp" breakpoints. "bu" breakpoints are automatically re-evaluated when any driver is loaded. If you just want to break when driver foo.sys loads, then use "bu foo!DriverEntry". Alternately, I believe there are some ways to specify relative offsets into foo, but I don't remember the exact syntax. It's something like "bu foo+0x1020". You can display the dispatch table using "!drvobj <driverobject> 2". See the docs on !drvobj. And because breakpoints can execute debugger commands, you can combine them so that the debugger runs !drvobj when your drivers of interest are loaded. For example: bu foo!DriverEntry "!drvobj foo 2" would (I believe -- again, I don't have a machine under KD right now to test) do what you want. If you want to dump the dispatch table of ANY driver that loads, that will require setting a breakpoint in the NT kernel and digging out the pointer to the driver object from the local stack frame. It's possible, but requires some digging. I believe Doron Holan's blog (http://blogs.msdn.com/doronh/) has some info on setting similar breakpoints. -- arlie -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of lallous Sent: Tuesday, July 11, 2006 7:48 AM To: Kernel Debugging Interest List Subject: [windbg] Break on driver load Hello Some PNP drivers are loaded and unloaded when the hardware is plugged/unplugged. Is there is a way to (1) set breakpoints (say @ driver_base+0x1020) (2) display the dispatch table of those drivers as they become ready? I don't have source code of these drivers, but some drivers are from MS whose PDBs are avail. Please advise. -- Elias=20 --- You are currently subscribed to windbg as: xxxxx@microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com
  Message 3 of 3  
11 Jul 06 12:33
Doron Holan
xxxxxx@microsoft.com
Join Date: 08 Sep 2005
Posts To This List: 96
Break on driver load

you can display the dispatch table by using !drvobj <driverobject> 2 (or \Driver\<name> instead of a pointer), but doing so at the start of DriverEntry() is too early. You could something like this bu foo!DriverEntry "gu; !drvobj \Driver\<name> 2" which would break on DriverEntry(), execute the function, break when the function returns and then executes the extension command. =20 You can also use "sxe ld <drivername>.sys" and you will get a software break when the image is loaded (before DriverEntry is called()). If you want to set a bp on any dispatch routine, you can always run "!object \Driver", find the object you want in the output, run "!drvobj <object> 2" to find the function pointer value and set a bp on it. Hope that helps. d -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Arlie Davis Sent: Tuesday, July 11, 2006 8:02 AM To: Kernel Debugging Interest List Subject: RE: [windbg] Break on driver load Use "bu" breakpoints intead of "bp" breakpoints. "bu" breakpoints are automatically re-evaluated when any driver is loaded. If you just want to break when driver foo.sys loads, then use "bu foo!DriverEntry". Alternately, I believe there are some ways to specify relative offsets into foo, but I don't remember the exact syntax. It's something like "bu foo+0x1020". You can display the dispatch table using "!drvobj <driverobject> 2". See the docs on !drvobj. And because breakpoints can execute debugger commands, you can combine them so that the debugger runs !drvobj when your drivers of interest are loaded. For example: bu foo!DriverEntry "!drvobj foo 2" would (I believe -- again, I don't have a machine under KD right now to test) do what you want. If you want to dump the dispatch table of ANY driver that loads, that will require setting a breakpoint in the NT kernel and digging out the pointer to the driver object from the local stack frame. It's possible, but requires some digging. I believe Doron Holan's blog (http://blogs.msdn.com/doronh/) has some info on setting similar breakpoints. -- arlie -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of lallous Sent: Tuesday, July 11, 2006 7:48 AM To: Kernel Debugging Interest List Subject: [windbg] Break on driver load Hello Some PNP drivers are loaded and unloaded when the hardware is plugged/unplugged. Is there is a way to (1) set breakpoints (say @ driver_base+0x1020) (2) display the dispatch table of those drivers as they become ready? I don't have source code of these drivers, but some drivers are from MS whose PDBs are avail. Please advise. -- Elias=20 --- You are currently subscribed to windbg as: xxxxx@microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com --- You are currently subscribed to windbg as: unknown lmsubst tag argument: '' To unsubscribe send a blank email to xxxxx@lists.osr.com
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the windbg list to be able to post.

All times are GMT -5. The time now is 05:37.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license