why I can not debug a driver ( not programmed by me )

hello, why I can not do it? or how to Can I do it?

There’s a document in your windbg directory called
‘kernel_debugging_tutorial.doc.’

It’s a good place to start.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, September 03, 2012 12:25 PM
To: Kernel Debugging Interest List
Subject: [windbg] why I can not debug a driver ( not programmed by me )

hello, why I can not do it? or how to Can I do it?


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

You can do it, but assuming that you don’t have the sources (the not
programmed by me) comment means you will have to do this all in assembler
with limited symbol support. The work can be done, just like one can walk
through a system routine.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, September 03, 2012 3:25 PM
To: Kernel Debugging Interest List
Subject: [windbg] why I can not debug a driver ( not programmed by me )

hello, why I can not do it? or how to Can I do it?


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

thanks, yes, about symbols does not matter, I want to debug a driver without symbols, for information only.
I set a breakpoint and then when I load the driver, Windbg shows:

watchdog!WdUpdateRecoveryState: Recovery enabled.
*** ERROR: Module load completed but symbols could not be loaded for drvkold.sys
Breakpoint 5’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt!DebugService2+0x11:
8052e4f5 5d pop ebp

How did you set the breakpoint?

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, September 03, 2012 12:48 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

thanks, yes, about symbols does not matter, I want to debug a driver without
symbols, for information only.
I set a breakpoint and then when I load the driver, Windbg shows:

watchdog!WdUpdateRecoveryState: Recovery enabled.
*** ERROR: Module load completed but symbols could not be loaded for
drvkold.sys Breakpoint 5’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt!DebugService2+0x11:
8052e4f5 5d pop ebp


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Before loading the driver I break to windbg, then
bp driver!DriverEntry, and I use osrloader to load and starts the driver.
If I remove the breakpoint, it runs normally

In general, you’re going to have to set breakpoints by address, since you
don’t have symbols.

mm
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, September 03, 2012 1:05 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

Before loading the driver I break to windbg, then bp driver!DriverEntry, and
I use osrloader to load and starts the driver.
If I remove the breakpoint, it runs normally


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

right, So how can I find the address of the entry point if the driver is not loaded yet?

Look in the PE header.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, September 03, 2012 1:13 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

right, So how can I find the address of the entry point if the driver is not
loaded yet?


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

still without success, I tried to find the entry point and/or use the bu command but does not works

Do you need to debug DriverEntry? If not use !drvobj to get the drivers
object and its dispatch entry points.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Monday, September 03, 2012 5:29 PM
To: Kernel Debugging Interest List
Subject: RE:[windbg] why I can not debug a driver ( not programmed by me )

still without success, I tried to find the entry point and/or use the bu
command but does not works


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

yes, I would like to debug DriverEntry…

Well, assuming it is your test system , and the driver you are trying to
debug is manually loaded, here is a trick you could try.

  1. Write a simple driver of your own.
  2. Register callback using PsSetLoadImageNotify. The callback function
    could be a no-op. Simply return.
  3. Load your driver (the one whose source code and symbols you have)
  4. Put a break point at the callback function.
  5. Now load your *target* driver.
  6. Your break-point should hit and give you the memory addresses where the
    target driver is mapped.
  7. Parse the PE headers from ImageBase address to get to the Entry point
    address.

This should be the DriverEntry routine which will be invoked after your
callback exits. Use ba to put a break point.

Good luck and let know if it worked :slight_smile:

On Mon, Sep 3, 2012 at 3:22 PM, wrote:

> yes, I would like to debug DriverEntry…
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

OR, just write “KdBreakPoint();” at the beginning of the DriverEntry.

Since the driver is not programmed by you, you can patch the first

byte at entry point in an EXE editing tool, and then change the byte

back when debugger stops there.

Run driver with debugger attached, you are good to go.

Note: Loading such driver without debugger attached leads

to BSOD with bugcheck code 0x80000003 (breakpoint).

L.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Atul Kabra
Sent: Tuesday, September 04, 2012 7:35 AM
To: Kernel Debugging Interest List
Subject: Re: [windbg] why I can not debug a driver ( not programmed by me )

Well, assuming it is your test system , and the driver you are trying to
debug is manually loaded, here is a trick you could try.

  1. Write a simple driver of your own.

  2. Register callback using PsSetLoadImageNotify. The callback function could
    be a no-op. Simply return.

  3. Load your driver (the one whose source code and symbols you have)

  4. Put a break point at the callback function.

  5. Now load your *target* driver.

  6. Your break-point should hit and give you the memory addresses where the
    target driver is mapped.

  7. Parse the PE headers from ImageBase address to get to the Entry point
    address.

This should be the DriverEntry routine which will be invoked after your
callback exits. Use ba to put a break point.

Good luck and let know if it worked :slight_smile:

On Mon, Sep 3, 2012 at 3:22 PM, wrote:

yes, I would like to debug DriverEntry…


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

— WINDBG is sponsored by OSR For our schedule of WDF, WDM, debugging and
other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

I forgot one thing - If you are going to patch the driver entry,

you also need to recalculate the image checksum, otherwise

it won’t be loaded. I use a tool named HIEW for both.

L.

“Atul Kabra” wrote in message news:xxxxx@windbg…
>Well, assuming it is your test system , and the driver you are trying to
>debug is manually loaded,
>here is a trick you could try.

There’s an easier way to do this. The debugger already has support for
breaking in when a particular module is loaded, so you just need to enable
that support for the module of interest. From there, you can use information
in the PE header to find the entry point in the image. Note that this entry
point is typically not the driver’s DriverEntry, but some pre-processing
code that will eventually jump to DriverEntry.

Here’s an example with a driver called nothing.sys:

1. Enable a break in the debugger when the module is loaded:

sxe ld nothing.sys

2. Resume the debugger:

g

3. Load the driver

4. Debugger will break in as a result of the module load:

nt!DebugService2+0x5:
fffff80147ae9985 cc int 3<br><br>5. Dump the PE header for the loaded module with !dh<br><br>1: kd&gt; !dh nothing<br><br>File Type: EXECUTABLE IMAGE<br> FILE HEADER VALUES<br> 8664 machine (X64)<br> 6 number of sections<br> 503BCFB3 time date stamp Mon Aug 27 15:51:15 2012<br><br>0 file pointer to symbol table<br> 0 number of symbols<br> F0 size of optional header<br> 22 characteristics<br> Executable<br> App can handle &gt;2gb addresses<br><br>OPTIONAL HEADER VALUES<br> 20B magic #<br> 11.00 linker version<br> C00 size of code<br> 800 size of initialized data<br> 0 size of uninitialized data<br> 157C address of entry point<br> 1000 base of code<br> ----- new -----<br> 000007f6d9930000 image base<br> 1000 section alignment<br> 200 file alignment<br> 1 subsystem (Native)<br> 6.02 operating system version<br> 6.02 image version<br> 6.02 subsystem version<br> 7000 size of image<br> 400 size of headers<br> 4AFF checksum<br><br>6. Add the value of, "address of entry point" to the base of the image to <br>get the breakpoint address:<br><br>1: kd&gt; bp nothing+157C<br> *** ERROR: Module load completed but symbols could not be loaded for <br>NOTHING.sys<br><br>7. Resume the debugger and hit the breakpoint:<br><br>1: kd&gt; g<br> Breakpoint 0 hit<br> NOTHING+0x157c:<br> fffff8800d9e657c 48895c2408 mov qword ptr [rsp+8],rbx

For demonstration, with symbols loaded you can see that this breakpoint is
in some pre-processing code that eventually jumps to my DriverEntry:

fffff8800d9e657c mov qword ptr [rsp+8],rbx<br>fffff8800d9e6581 push rdi
fffff8800d9e6582 sub rsp,20h<br>fffff8800d9e6586 mov rbx,rdx
fffff8800d9e6589 mov rdi,rcx<br>fffff8800d9e658c call NOTHING!__security_init_cookie
fffff8800d9e6591 mov rdx,rbx<br>fffff8800d9e6594 mov rcx,rdi
fffff8800d9e6597 mov rbx,qword ptr [rsp+30h]<br>fffff8800d9e659c add rsp,20h
fffff8800d9e65a0 pop rdi<br>fffff8800d9e65a1 jmp NOTHING!DriverEntry

-scott

“Atul Kabra” wrote in message news:xxxxx@windbg…
Well, assuming it is your test system , and the driver you are trying to
debug is manually loaded, here is a trick you could try.

1) Write a simple driver of your own.
2) Register callback using PsSetLoadImageNotify. The callback function could
be a no-op. Simply return.
3) Load your driver (the one whose source code and symbols you have)
4) Put a break point at the callback function.
5) Now load your target driver.
6) Your break-point should hit and give you the memory addresses where the
target driver is mapped.
7) Parse the PE headers from ImageBase address to get to the Entry point
address.

This should be the DriverEntry routine which will be invoked after your
callback exits. Use ba to put a break point.

Good luck and let know if it worked :slight_smile:

On Mon, Sep 3, 2012 at 3:22 PM, wrote:
yes, I would like to debug DriverEntry…


WINDBG is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

well you can break on most of drivers entry with this two breakpoints
demo is for xp sp3 32bit but you can adapt it for all the os

Will breakin at next boot. ( using ctr+alt+r or sxe ibp or -b on command line )
kd> .reboot
Shutdown occurred at (Wed Sep 5 00:59:09.234 2012 (UTC +
5:30))…unloading all symbol tables.
Waiting to reconnect…
Connected to Windows XP 2600 x86 compatible target at (Wed Sep 5
00:59:23.437 2012 (UTC + 5:30)), ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRV*F:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
System Uptime: not available
eax=00000003 ebx=00000000 ecx=0005ffa4 edx=0005ff74 esi=8008a978 edi=8008aa1c
eip=80506d3e esp=0005ff60 ebp=0005ff60 iopl=0 nv up di ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000086
nt!DebugService2+0x10:
80506d3e cc int 3

grep for an indirect call that calls driver entry of bootloaded drivers

kd> .shell -ci “uf /c nt!IopInitializeBuiltinDriver” grep -B 1 -i “call.*[e.*h”
nt!IopInitializeBuiltinDriver+0x25d (806a9ef9):
unresolvable call: call dword ptr [ebx+2Ch]
.shell: Process exited

grep for an indirect call that calls driver entry of demand start drivers

kd> .shell -ci “uf /c nt!IopLoadDriver” grep -B 1 -i “call.*[e.*h”
nt!IopLoadDriver+0x66a (805a399a):
unresolvable call: call dword ptr [edi+2Ch]
.shell: Process exited

i am setting a logging bp on them for demo
this can be customised to your will

kd> bp 806a9ef9 “.printf "%y\t\t%msu\n\n" , poi (ebx+2ch),poi (esp+4);g”
kd> bp 805a399a “.printf "%y\t\t%msu\n\n" , poi (edi+2ch),poi (esp+4);g”

kd> bl
0 e 806a9ef9 0001 (0001) nt!IopInitializeBuiltinDriver+0x25d
“.printf "%y\t\t%msu\n\n" , poi (ebx+2ch),poi (esp+4);g”
1 e 805a399a 0001 (0001) nt!IopLoadDriver+0x66a “.printf
"%y\t\t%msu\n\n" , poi (edi+2ch),poi (esp+4);g”

the msu will print the registry path
NTSTATUS
DriverEntry(
__in PDRIVER_OBJECT DriverObject,
__in PUNICODE_STRING RegistryPath <--------------------

the %y actual driver entry that is called

kd> g
nt!RawInitialize (806a61f7)
ACPI!GsDriverEntry
(bafda059) \Registry\Machine\System\CurrentControlSet\Services\ACPI
pci!GsDriverEntry
(bafae004) \Registry\Machine\System\CurrentControlSet\Services\PCI
isapnp+0x7a02 (fc4c3a02) \Registry\Machine\System\CurrentControlSet\Services\isapnp
intelide+0xf05 (fc9c0f05) \Registry\Machine\System\CurrentControlSet\Services\IntelIde
MountMgr!GsDriverEntry
(fc4d5234) \Registry\Machine\System\CurrentControlSet\Services\MountMgr
ftdisk!DriverEntry
(baf9c4e2) \Registry\Machine\System\CurrentControlSet\Services\Ftdisk
dmload!DriverEntry
(fc9c2bf6) \Registry\Machine\System\CurrentControlSet\Services\dmload

**********************cut**************** total 92 driver entry broken

aec!GsDriverEntry
(f901686a) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\aec
swmidi!GsDriverEntry
(f9259c85) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\swmidi
DMusic!GsDriverEntry
(f9249024) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\DMusic
kmixer!GsDriverEntry
(f8ff2105) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\kmixer
drmkaud!GsDriverEntry
(fcbd5505) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\drmkaud
HTTP!GsDriverEntry
(f8e0c757) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\HTTP

On 9/4/12, Scott Noone wrote:
> “Atul Kabra” wrote in message
> news:xxxxx@windbg…
>>Well, assuming it is your test system , and the driver you are trying to
>>debug is manually loaded,
>>here is a trick you could try.
>
> There’s an easier way to do this. The debugger already has support for
> breaking in when a particular module is loaded, so you just need to enable
> that support for the module of interest. From there, you can use information
>
> in the PE header to find the entry point in the image. Note that this entry
>
> point is typically not the driver’s DriverEntry, but some pre-processing
> code that will eventually jump to DriverEntry.
>
> Here’s an example with a driver called nothing.sys:
>
> 1. Enable a break in the debugger when the module is loaded:
>
> sxe ld nothing.sys
>
> 2. Resume the debugger:
>
> g
>
> 3. Load the driver
>
> 4. Debugger will break in as a result of the module load:
>
> nt!DebugService2+0x5:
> fffff80147ae9985 cc int 3<br>&gt;<br>&gt;<br>&gt; 5. Dump the PE header for the loaded module with !dh<br>&gt;<br>&gt; 1: kd&gt; !dh nothing<br>&gt;<br>&gt; File Type: EXECUTABLE IMAGE<br>&gt; FILE HEADER VALUES<br>&gt; 8664 machine (X64)<br>&gt; 6 number of sections<br>&gt; 503BCFB3 time date stamp Mon Aug 27 15:51:15 2012<br>&gt;<br>&gt; 0 file pointer to symbol table<br>&gt; 0 number of symbols<br>&gt; F0 size of optional header<br>&gt; 22 characteristics<br>&gt; Executable<br>&gt; App can handle &gt;2gb addresses<br>&gt;<br>&gt; OPTIONAL HEADER VALUES<br>&gt; 20B magic #<br>&gt; 11.00 linker version<br>&gt; C00 size of code<br>&gt; 800 size of initialized data<br>&gt; 0 size of uninitialized data<br>&gt; 157C address of entry point<br>&gt; 1000 base of code<br>&gt; ----- new -----<br>&gt; 000007f6d9930000 image base<br>&gt; 1000 section alignment<br>&gt; 200 file alignment<br>&gt; 1 subsystem (Native)<br>&gt; 6.02 operating system version<br>&gt; 6.02 image version<br>&gt; 6.02 subsystem version<br>&gt; 7000 size of image<br>&gt; 400 size of headers<br>&gt; 4AFF checksum<br>&gt;<br>&gt; 6. Add the value of, "address of entry point" to the base of the image to<br>&gt; get the breakpoint address:<br>&gt;<br>&gt; 1: kd&gt; bp nothing+157C<br>&gt; *** ERROR: Module load completed but symbols could not be loaded for<br>&gt; NOTHING.sys<br>&gt;<br>&gt; 7. Resume the debugger and hit the breakpoint:<br>&gt;<br>&gt; 1: kd&gt; g<br>&gt; Breakpoint 0 hit<br>&gt; NOTHING+0x157c:<br>&gt; fffff8800d9e657c 48895c2408 mov qword ptr [rsp+8],rbx
>
> For demonstration, with symbols loaded you can see that this breakpoint is
> in some pre-processing code that eventually jumps to my DriverEntry:
>
> fffff8800d9e657c mov qword ptr [rsp+8],rbx<br>&gt; fffff8800d9e6581 push rdi
> fffff8800d9e6582 sub rsp,20h<br>&gt; fffff8800d9e6586 mov rbx,rdx
> fffff8800d9e6589 mov rdi,rcx<br>&gt; fffff8800d9e658c call NOTHING!__security_init_cookie
> fffff8800d9e6591 mov rdx,rbx<br>&gt; fffff8800d9e6594 mov rcx,rdi
> fffff8800d9e6597 mov rbx,qword ptr [rsp+30h]<br>&gt; fffff8800d9e659c add rsp,20h
> fffff8800d9e65a0 pop rdi<br>&gt; fffff8800d9e65a1 jmp NOTHING!DriverEntry
>
> -scott
>
>
> “Atul Kabra” wrote in message
> news:xxxxx@windbg…
> Well, assuming it is your test system , and the driver you are trying to
> debug is manually loaded, here is a trick you could try.
>
> 1) Write a simple driver of your own.
> 2) Register callback using PsSetLoadImageNotify. The callback function could
>
> be a no-op. Simply return.
> 3) Load your driver (the one whose source code and symbols you have)
> 4) Put a break point at the callback function.
> 5) Now load your target driver.
> 6) Your break-point should hit and give you the memory addresses where the
> target driver is mapped.
> 7) Parse the PE headers from ImageBase address to get to the Entry point
> address.
>
> This should be the DriverEntry routine which will be invoked after your
> callback exits. Use ba to put a break point.
>
> Good luck and let know if it worked :slight_smile:
>
>
>
> On Mon, Sep 3, 2012 at 3:22 PM, wrote:
> yes, I would like to debug DriverEntry…
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> WINDBG is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

i had this script but couldnt dig it yesterday so i posted a .shell
substitute yesterday
but .shell has a drawback that i cannot use the result as input to
another debugger extension command so i used a .foreach earlier and
made this script generic

ie i can run it and it will always be available through out the
session when ever any driver loads

windbg will simply show me all the relevent details about the driver

script is like this

.foreach /pS 1 /ps 10 ( place { # call*dword*ptr*[*+*]
nt!IopInitializeBuiltinDriver} ) {bp place “.printf "%msu\n",
poi(esp+4);r $t0 = poi(esp); gu; !drvobj $t0 2;g”}

.foreach /pS 1 /ps 10 ( place { # call*dword*ptr*[*+*]
nt!IoploadDriver} ) {bp place “.printf "%msu\n", poi(esp+4);r $t1
= poi(esp); gu; !drvobj $t1 2;g”}

it searches for the patten in the function (first match is taken here
not fool proof )
call dword ptr [R32+const]
sets a bp there and prints the registry path
sets the driverobj that is passed to driver entry to a pseudo register
executes the driver entry and then
prints out the dispatch routines of the driver that was loaded

and it lies dormant waiting for any driver that loads through this route

demo below

kd> sxe ibp;.reboot
Shutdown occurred at (Wed Sep 5 17:37:17.343 2012 (UTC +
5:30))…unloading all symbol tables.
Waiting to reconnect…
Connected to Windows XP 2600 x86 compatible target at (Wed Sep 5
17:37:27.703 2012 (UTC + 5:30)), ptr64 FALSE
Kernel Debugger connection established. (Initial Breakpoint requested)
Symbol search path is: SRV*F:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 UP Free x86 compatible
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
*******************************************************************************
* *
* You are seeing this message because you pressed either *
* CTRL+C (if you run kd.exe) or, *
* CTRL+BREAK (if you run WinDBG), *
* on your debugger machine’s keyboard. *
* *
* THIS IS NOT A BUG OR A SYSTEM CRASH *
* *
* If you did not intend to break into the debugger, press the “g” key, then *
* press the “Enter” key now. This message might immediately reappear. If it *
* does, press “g” and “Enter” again. *
* *
*******************************************************************************
nt!RtlpBreakWithStatusInstruction:
804e3592 cc int 3
kd> $$>a< .\scripts\drventry.txt
kd> bl
0 e 806a9ef9 0001 (0001) nt!IopInitializeBuiltinDriver+0x25d
“.printf "%msu\n", poi(esp+4);r $t0 = poi(esp); gu; !drvobj $t0
2;g”
1 e 805a399a 0001 (0001) nt!IopLoadDriver+0x66a “.printf
"%msu\n", poi(esp+4);r $t1 = poi(esp); gu; !drvobj $t1 2;g”

kd> g

*** ERROR: Module load completed but symbols could not be loaded for isapnp.sys
*** ERROR: Module load completed but symbols could not be loaded for
diskperf.sys
*** ERROR: Module load completed but symbols could not be loaded for
intelide.sys
Driver object (812ade18) is for:
\FileSystem\RAW
DriverEntry: 806a61f7 nt!RawInitialize
DriverStartIo: 00000000
DriverUnload: 8063043a nt!RawUnload
AddDevice: 00000000

Dispatch routines:
[00] IRP_MJ_CREATE 805a09c1 nt!RawDispatch
[01] IRP_MJ_CREATE_NAMED_PIPE 804fa87e nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE 805a09c1 nt!RawDispatch
[03] IRP_MJ_READ 805a09c1 nt!RawDispatch
[04] IRP_MJ_WRITE 805a09c1 nt!RawDispatch
[05] IRP_MJ_QUERY_INFORMATION 805a09c1 nt!RawDispatch
[06] IRP_MJ_SET_INFORMATION 805a09c1 nt!RawDispatch
[07] IRP_MJ_QUERY_EA 804fa87e nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA 804fa87e nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS 804fa87e nt!IopInvalidDeviceRequest
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION 805a09c1 nt!RawDispatch
[0b] IRP_MJ_SET_VOLUME_INFORMATION 804fa87e nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL 804fa87e nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL 805a09c1 nt!RawDispatch
[0e] IRP_MJ_DEVICE_CONTROL 805a09c1 nt!RawDispatch
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL 804fa87e nt!IopInvalidDeviceRequest
[10] IRP_MJ_SHUTDOWN 806303d5 nt!RawShutdown
[11] IRP_MJ_LOCK_CONTROL 804fa87e nt!IopInvalidDeviceRequest
[12] IRP_MJ_CLEANUP 805a09c1 nt!RawDispatch
[13] IRP_MJ_CREATE_MAILSLOT 804fa87e nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY 804fa87e nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY 804fa87e nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER 804fa87e nt!IopInvalidDeviceRequest
[17] IRP_MJ_SYSTEM_CONTROL 804fa87e nt!IopInvalidDeviceRequest
[18] IRP_MJ_DEVICE_CHANGE 804fa87e nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA 804fa87e nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA 804fa87e nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP 805a09c1 nt!RawDispatch

\Registry\Machine\System\CurrentControlSet\Services\ACPI
Driver object (812ad998) is for:
\Driver\ACPI
DriverEntry: fc496059 ACPI!GsDriverEntry
DriverStartIo: 00000000
DriverUnload: fc473866 ACPI!ACPIUnload
AddDevice: fc473a9a ACPI!ACPIDispatchAddDevice

Dispatch routines:
[00] IRP_MJ_CREATE fc473cb8 ACPI!ACPIDispatchIrp
[01] IRP_MJ_CREATE_NAMED_PIPE fc473cb8 ACPI!ACPIDispatchIrp
[02] IRP_MJ_CLOSE fc473cb8 ACPI!ACPIDispatchIrp
[03] IRP_MJ_READ fc473cb8 ACPI!ACPIDispatchIrp
[04] IRP_MJ_WRITE fc473cb8 ACPI!ACPIDispatchIrp
[05] IRP_MJ_QUERY_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
[06] IRP_MJ_SET_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
[07] IRP_MJ_QUERY_EA fc473cb8 ACPI!ACPIDispatchIrp
[08] IRP_MJ_SET_EA fc473cb8 ACPI!ACPIDispatchIrp
[09] IRP_MJ_FLUSH_BUFFERS fc473cb8 ACPI!ACPIDispatchIrp
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
[0b] IRP_MJ_SET_VOLUME_INFORMATION fc473cb8 ACPI!ACPIDispatchIrp
[0c] IRP_MJ_DIRECTORY_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
[0d] IRP_MJ_FILE_SYSTEM_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
[0e] IRP_MJ_DEVICE_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
[10] IRP_MJ_SHUTDOWN fc473cb8 ACPI!ACPIDispatchIrp
[11] IRP_MJ_LOCK_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
[12] IRP_MJ_CLEANUP fc473cb8 ACPI!ACPIDispatchIrp
[13] IRP_MJ_CREATE_MAILSLOT fc473cb8 ACPI!ACPIDispatchIrp
[14] IRP_MJ_QUERY_SECURITY fc473cb8 ACPI!ACPIDispatchIrp
[15] IRP_MJ_SET_SECURITY fc473cb8 ACPI!ACPIDispatchIrp
[16] IRP_MJ_POWER fc473cb8 ACPI!ACPIDispatchIrp
[17] IRP_MJ_SYSTEM_CONTROL fc473cb8 ACPI!ACPIDispatchIrp
[18] IRP_MJ_DEVICE_CHANGE fc473cb8 ACPI!ACPIDispatchIrp
[19] IRP_MJ_QUERY_QUOTA fc473cb8 ACPI!ACPIDispatchIrp
[1a] IRP_MJ_SET_QUOTA fc473cb8 ACPI!ACPIDispatchIrp
[1b] IRP_MJ_PNP fc473cb8 ACPI!ACPIDispatchIrp

Fast I/O routines:
FastIoDetachDevice
fc4740d4 ACPI!ACPIFilterFastIoDetachCallback

the paste below is a demand start drivers driver entry and its dispatch routines

\REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\CDO
[Cdo]: Driver being loaded
[Cdo]: Creating CDO …
[Cdo]: Creating CDO successful
[Cdo]: FltObjects is fc913a6c Flags is 1 VolumeDeviceType is
14 VolumefileSystemType is 7
[Cdo]: FltObjects is fc913a6c Flags is 1 VolumeDeviceType is
14 VolumefileSystemType is 6
[Cdo]: FltObjects is fc913a6c Flags is 1 VolumeDeviceType is
8 VolumefileSystemType is 2
*** ERROR: Module load completed but symbols could not be loaded for cdo.sys
Driver object (ffab0a30) is for:
\FileSystem\CDO
DriverEntry: fc8186f4 cdo
DriverStartIo: 00000000
DriverUnload: fc3f2f08 fltMgr!FltpMiniFilterDriverUnload
AddDevice: 00000000

Dispatch routines:
[00] IRP_MJ_CREATE fc815710 cdo+0x1710
[01] IRP_MJ_CREATE_NAMED_PIPE fc815710 cdo+0x1710
[02] IRP_MJ_CLOSE fc815710 cdo+0x1710
[03] IRP_MJ_READ fc815710 cdo+0x1710
[04] IRP_MJ_WRITE fc815710 cdo+0x1710
[05] IRP_MJ_QUERY_INFORMATION fc815710 cdo+0x1710
[06] IRP_MJ_SET_INFORMATION fc815710 cdo+0x1710
[07] IRP_MJ_QUERY_EA fc815710 cdo+0x1710
[08] IRP_MJ_SET_EA fc815710 cdo+0x1710
[09] IRP_MJ_FLUSH_BUFFERS fc815710 cdo+0x1710
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION fc815710 cdo+0x1710
[0b] IRP_MJ_SET_VOLUME_INFORMATION fc815710 cdo+0x1710
[0c] IRP_MJ_DIRECTORY_CONTROL fc815710 cdo+0x1710
[0d] IRP_MJ_FILE_SYSTEM_CONTROL fc815710 cdo+0x1710
[0e] IRP_MJ_DEVICE_CONTROL fc815710 cdo+0x1710
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fc815710 cdo+0x1710
[10] IRP_MJ_SHUTDOWN fc815710 cdo+0x1710
[11] IRP_MJ_LOCK_CONTROL fc815710 cdo+0x1710
[12] IRP_MJ_CLEANUP fc815710 cdo+0x1710
[13] IRP_MJ_CREATE_MAILSLOT fc815710 cdo+0x1710
[14] IRP_MJ_QUERY_SECURITY fc815710 cdo+0x1710
[15] IRP_MJ_SET_SECURITY fc815710 cdo+0x1710
[16] IRP_MJ_POWER fc815710 cdo+0x1710
[17] IRP_MJ_SYSTEM_CONTROL fc815710 cdo+0x1710
[18] IRP_MJ_DEVICE_CHANGE fc815710 cdo+0x1710
[19] IRP_MJ_QUERY_QUOTA fc815710 cdo+0x1710
[1a] IRP_MJ_SET_QUOTA fc815710 cdo+0x1710
[1b] IRP_MJ_PNP fc815710 cdo+0x1710

Fast I/O routines:
FastIoCheckIfPossible fc815fe0 cdo+0x1fe0
FastIoRead fc8160f0 cdo+0x20f0
FastIoWrite fc816200 cdo+0x2200
FastIoQueryBasicInfo fc816310 cdo+0x2310
FastIoQueryStandardInfo fc816420 cdo+0x2420
FastIoLock fc816530 cdo+0x2530
FastIoUnlockSingle fc816640 cdo+0x2640
FastIoUnlockAll fc816750 cdo+0x2750
FastIoUnlockAllByKey fc816860 cdo+0x2860
FastIoDeviceControl fc816970 cdo+0x2970
FastIoQueryNetworkOpenInfo fc816ab0 cdo+0x2ab0
MdlRead fc816bc0 cdo+0x2bc0
MdlReadComplete fc814b90 cdo+0xb90
PrepareMdlWrite fc816cd0 cdo+0x2cd0
MdlWriteComplete fc814c50 cdo+0xc50
FastIoReadCompressed fc816de0 cdo+0x2de0
FastIoWriteCompressed fc816ef0 cdo+0x2ef0
MdlReadCompleteCompressed fc814d10 cdo+0xd10
MdlWriteCompleteCompressed fc814dd0 cdo+0xdd0
FastIoQueryOpen fc817000 cdo+0x3000

[Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0x0 )
[Cdo]: CdoHandlePrivateOpen entry ( Irp = 81183D68 )
[Cdo]: CdoHandlePrivateOpen -> Device open successful. ( Irp =
81183D68, Flags = 0x3, status = 0x0 )
[Cdo]: CdoHandlePrivateOpen exit ( Irp = 81183D68, status = 0x0 )
[Cdo]: Value At Irp->IoStatus.Information is 1
[Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
0x0, status = 0x0 )
[Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0xd )
[Cdo]: CdoHandlePrivateFsControl entry ( Irp = 81183D68 )
IoControlCode = 0x90060
InputBuffer = 811C9518
??
InputBufferLength = 0x38
OutputBuffer = 811C9518
OutputBufferLength = 0x38
[Cdo]: CdoHandlePrivateFsControl -> Processing IOCTL while handle to
CDO is definitely open. ( Irp = 81183D68, IoControlCode = 0x90060 )
[Cdo]: CdoHandlePrivateFsControl exit ( Irp = 81183D68, IoControlCode
= 0x90060, status = 0x0 )
[Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
0xd, status = 0x0 )
[Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0xd )
[Cdo]: CdoHandlePrivateFsControl entry ( Irp = 81183D68 )
IoControlCode = 0x90060
InputBuffer = 81144480

InputBufferLength = 0x0
OutputBuffer = 81144480
OutputBufferLength = 0x38
[Cdo]: CdoHandlePrivateFsControl -> Processing IOCTL while handle to
CDO is definitely open. ( Irp = 81183D68, IoControlCode = 0x90060 )
[Cdo]: CdoHandlePrivateFsControl exit ( Irp = 81183D68, IoControlCode
= 0x90060, status = 0x0 )
[Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
0xd, status = 0x0 )
[Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0x12 )
[Cdo]: CdoHandlePrivateCleanup entry ( Irp = 81183D68 )
[Cdo]: CdoHandlePrivateCleanup -> Device cleanup successful. ( Irp =
81183D68, Flags = 0x1, status = 0x0 )
[Cdo]: CdoHandlePrivateCleanup exit ( Irp = 81183D68, status = 0x0 )
[Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
0x12, status = 0x0 )
[Cdo]: CdoMajorFunction entry ( Irp = 81183D68, irpSp->MajorFunction = 0x2 )
[Cdo]: CdoHandlePrivateClose entry ( Irp = 81183D68 )
[Cdo]: CdoHandlePrivateClose -> Device close successful. ( Irp =
81183D68, Flags = 0x0, status = 0x0 )
[Cdo]: CdoHandlePrivateClose exit ( Irp = 81183D68, status = 0x0 )
[Cdo]: CdoMajorFunction exit ( Irp = 81183D68, irpSp->MajorFunction =
0x2, status = 0x0 )
[Cdo]: Unloading driver
[Cdo]: Deleting CDO …
[Cdo]: Deleting CDO successful

On 9/5/12, raj_r wrote:
> well you can break on most of drivers entry with this two breakpoints
> demo is for xp sp3 32bit but you can adapt it for all the os
>
> Will breakin at next boot. ( using ctr+alt+r or sxe ibp or -b on command
> line )
> kd> .reboot
> Shutdown occurred at (Wed Sep 5 00:59:09.234 2012 (UTC +
> 5:30))…unloading all symbol tables.
> Waiting to reconnect…
> Connected to Windows XP 2600 x86 compatible target at (Wed Sep 5
> 00:59:23.437 2012 (UTC + 5:30)), ptr64 FALSE
> Kernel Debugger connection established.
> Symbol search path is:
> SRVF:\symbolshttp://msdl.microsoft.com/download/symbols
> Executable search path is:
> Windows XP Kernel Version 2600 UP Free x86 compatible
> Built by: 2600.xpsp.080413-2111
> Machine Name:
> Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
> System Uptime: not available
> eax=00000003 ebx=00000000 ecx=0005ffa4 edx=0005ff74 esi=8008a978
> edi=8008aa1c
> eip=80506d3e esp=0005ff60 ebp=0005ff60 iopl=0 nv up di ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00000086
> nt!DebugService2+0x10:
> 80506d3e cc int 3
>
> grep for an indirect call that calls driver entry of bootloaded drivers
>
> kd> .shell -ci “uf /c nt!IopInitializeBuiltinDriver” grep -B 1 -i
> “call.*[e.h"
> nt!IopInitializeBuiltinDriver+0x25d (806a9ef9):
> unresolvable call: call dword ptr [ebx+2Ch]
> .shell: Process exited
>
> grep for an indirect call that calls driver entry of demand start drivers
>
> kd> .shell -ci “uf /c nt!IopLoadDriver” grep -B 1 -i "call.
[e.*h”
> nt!IopLoadDriver+0x66a (805a399a):
> unresolvable call: call dword ptr [edi+2Ch]
> .shell: Process exited
>
> i am setting a logging bp on them for demo
> this can be customised to your will
>
> kd> bp 806a9ef9 “.printf "%y\t\t%msu\n\n" , poi (ebx+2ch),poi (esp+4);g”
> kd> bp 805a399a “.printf "%y\t\t%msu\n\n" , poi (edi+2ch),poi (esp+4);g”
>
>
> kd> bl
> 0 e 806a9ef9 0001 (0001) nt!IopInitializeBuiltinDriver+0x25d
> “.printf "%y\t\t%msu\n\n" , poi (ebx+2ch),poi (esp+4);g”
> 1 e 805a399a 0001 (0001) nt!IopLoadDriver+0x66a “.printf
> "%y\t\t%msu\n\n" , poi (edi+2ch),poi (esp+4);g”
>
> the msu will print the registry path
> NTSTATUS
> DriverEntry(
> in PDRIVER_OBJECT DriverObject,
>
in PUNICODE_STRING RegistryPath <--------------------
>
> the %y actual driver entry that is called
>
>
>
> kd> g
> nt!RawInitialize (806a61f7)
> ACPI!GsDriverEntry
> (bafda059) \Registry\Machine\System\CurrentControlSet\Services\ACPI
> pci!GsDriverEntry
> (bafae004) \Registry\Machine\System\CurrentControlSet\Services\PCI
> isapnp+0x7a02
> (fc4c3a02) \Registry\Machine\System\CurrentControlSet\Services\isapnp
> intelide+0xf05
> (fc9c0f05) \Registry\Machine\System\CurrentControlSet\Services\IntelIde
> MountMgr!GsDriverEntry
> (fc4d5234) \Registry\Machine\System\CurrentControlSet\Services\MountMgr
> ftdisk!DriverEntry
> (baf9c4e2) \Registry\Machine\System\CurrentControlSet\Services\Ftdisk
> dmload!DriverEntry
> (fc9c2bf6) \Registry\Machine\System\CurrentControlSet\Services\dmload
>
>
> ******cut total 92 driver entry broken
>
>
> aec!GsDriverEntry
> (f901686a) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\aec
> swmidi!GsDriverEntry
> (f9259c85) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\swmidi
> DMusic!GsDriverEntry
> (f9249024) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\DMusic
> kmixer!GsDriverEntry
> (f8ff2105) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\kmixer
> drmkaud!GsDriverEntry
> (fcbd5505) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\drmkaud
> HTTP!GsDriverEntry
> (f8e0c757) \REGISTRY\MACHINE\SYSTEM\ControlSet002\Services\HTTP
>
>
>
> On 9/4/12, Scott Noone wrote:
>> “Atul Kabra” wrote in message
>> news:xxxxx@windbg…
>>>Well, assuming it is your test system , and the driver you are trying to
>>>debug is manually loaded,
>>>here is a trick you could try.
>>
>> There’s an easier way to do this. The debugger already has support for
>> breaking in when a particular module is loaded, so you just need to
>> enable
>> that support for the module of interest. From there, you can use
>> information
>>
>> in the PE header to find the entry point in the image. Note that this
>> entry
>>
>> point is typically not the driver’s DriverEntry, but some
>> pre-processing
>> code that will eventually jump to DriverEntry.
>>
>> Here’s an example with a driver called nothing.sys:
>>
>> 1. Enable a break in the debugger when the module is loaded:
>>
>> sxe ld nothing.sys
>>
>> 2. Resume the debugger:
>>
>> g
>>
>> 3. Load the driver
>>
>> 4. Debugger will break in as a result of the module load:
>>
>> nt!DebugService2+0x5:
>> fffff80147ae9985 cc int 3<br>&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; 5. Dump the PE header for the loaded module with !dh<br>&gt;&gt;<br>&gt;&gt; 1: kd&gt; !dh nothing<br>&gt;&gt;<br>&gt;&gt; File Type: EXECUTABLE IMAGE<br>&gt;&gt; FILE HEADER VALUES<br>&gt;&gt; 8664 machine (X64)<br>&gt;&gt; 6 number of sections<br>&gt;&gt; 503BCFB3 time date stamp Mon Aug 27 15:51:15 2012<br>&gt;&gt;<br>&gt;&gt; 0 file pointer to symbol table<br>&gt;&gt; 0 number of symbols<br>&gt;&gt; F0 size of optional header<br>&gt;&gt; 22 characteristics<br>&gt;&gt; Executable<br>&gt;&gt; App can handle &gt;2gb addresses<br>&gt;&gt;<br>&gt;&gt; OPTIONAL HEADER VALUES<br>&gt;&gt; 20B magic #<br>&gt;&gt; 11.00 linker version<br>&gt;&gt; C00 size of code<br>&gt;&gt; 800 size of initialized data<br>&gt;&gt; 0 size of uninitialized data<br>&gt;&gt; 157C address of entry point<br>&gt;&gt; 1000 base of code<br>&gt;&gt; ----- new -----<br>&gt;&gt; 000007f6d9930000 image base<br>&gt;&gt; 1000 section alignment<br>&gt;&gt; 200 file alignment<br>&gt;&gt; 1 subsystem (Native)<br>&gt;&gt; 6.02 operating system version<br>&gt;&gt; 6.02 image version<br>&gt;&gt; 6.02 subsystem version<br>&gt;&gt; 7000 size of image<br>&gt;&gt; 400 size of headers<br>&gt;&gt; 4AFF checksum<br>&gt;&gt;<br>&gt;&gt; 6. Add the value of, "address of entry point" to the base of the image to<br>&gt;&gt; get the breakpoint address:<br>&gt;&gt;<br>&gt;&gt; 1: kd&gt; bp nothing+157C<br>&gt;&gt; *** ERROR: Module load completed but symbols could not be loaded for<br>&gt;&gt; NOTHING.sys<br>&gt;&gt;<br>&gt;&gt; 7. Resume the debugger and hit the breakpoint:<br>&gt;&gt;<br>&gt;&gt; 1: kd&gt; g<br>&gt;&gt; Breakpoint 0 hit<br>&gt;&gt; NOTHING+0x157c:<br>&gt;&gt; fffff8800d9e657c 48895c2408 mov qword ptr [rsp+8],rbx
>>
>> For demonstration, with symbols loaded you can see that this breakpoint
>> is
>> in some pre-processing code that eventually jumps to my DriverEntry:
>>
>> fffff8800d9e657c mov qword ptr [rsp+8],rbx<br>&gt;&gt; fffff8800d9e6581 push rdi
>> fffff8800d9e6582 sub rsp,20h<br>&gt;&gt; fffff8800d9e6586 mov rbx,rdx
>> fffff8800d9e6589 mov rdi,rcx<br>&gt;&gt; fffff8800d9e658c call NOTHING!__security_init_cookie
>> fffff8800d9e6591 mov rdx,rbx<br>&gt;&gt; fffff8800d9e6594 mov rcx,rdi
>> fffff8800d9e6597 mov rbx,qword ptr [rsp+30h]<br>&gt;&gt; fffff8800d9e659c add rsp,20h
>> fffff8800d9e65a0 pop rdi<br>&gt;&gt; fffff8800d9e65a1 jmp NOTHING!DriverEntry
>>
>> -scott
>>
>>
>> “Atul Kabra” wrote in message
>> news:xxxxx@windbg…
>> Well, assuming it is your test system , and the driver you are trying to
>> debug is manually loaded, here is a trick you could try.
>>
>> 1) Write a simple driver of your own.
>> 2) Register callback using PsSetLoadImageNotify. The callback function
>> could
>>
>> be a no-op. Simply return.
>> 3) Load your driver (the one whose source code and symbols you have)
>> 4) Put a break point at the callback function.
>> 5) Now load your target driver.
>> 6) Your break-point should hit and give you the memory addresses where
>> the
>> target driver is mapped.
>> 7) Parse the PE headers from ImageBase address to get to the Entry point
>> address.
>>
>> This should be the DriverEntry routine which will be invoked after your
>> callback exits. Use ba to put a break point.
>>
>> Good luck and let know if it worked :slight_smile:
>>
>>
>>
>> On Mon, Sep 3, 2012 at 3:22 PM, wrote:
>> yes, I would like to debug DriverEntry…
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>>
>> —
>> WINDBG is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>