Breakpoint question.

Hi,

As an exercise in using WinDbg I am trying to single step through my
DriverEntry() function. The driver is very simply and both DriverEntry() and
DriverUnload() just write messages to WinDbg (which works as expected).

The problem is that I cannot set a breakpoint on DriverEntry() without first
loading the symbols for my driver. But in order to do this it appears that I
need to first run the driver on the target PC, which means that I have
already gone passed my intended breakpoint and possibly executed problematic
driver code.

How can I set a breakpoint on the DriverEntry() function on the host PC
without having first run the function on the target PC?

I am using OSR Driver Loader to Register, Unregister, Start and Stop the
driver etc.

Regards FarmerJo

you can put deffered breakpoints.
bu command. look for breakpoint documentation in windbg help!

Regards,
Dhiren

FarmerJo wrote:
Hi,

As an exercise in using WinDbg I am trying to single step through my
DriverEntry() function. The driver is very simply and both DriverEntry() and
DriverUnload() just write messages to WinDbg (which works as expected).

The problem is that I cannot set a breakpoint on DriverEntry() without first
loading the symbols for my driver. But in order to do this it appears that I
need to first run the driver on the target PC, which means that I have
already gone passed my intended breakpoint and possibly executed problematic
driver code.

How can I set a breakpoint on the DriverEntry() function on the host PC
without having first run the function on the target PC?

I am using OSR Driver Loader to Register, Unregister, Start and Stop the
driver etc.

Regards FarmerJo


You are currently subscribed to windbg as: xxxxx@yahoo.co.in
To unsubscribe send a blank email to xxxxx@lists.osr.com

---------------------------------
Best Jokes, Best Friends, Best Food. Get all this and more on Best of Yahoo! Groups.

Hello,

* On Tue, May 27, 2008 at 12:43:23PM +0100 FarmerJo wrote:

How can I set a breakpoint on the DriverEntry() function on the host PC
without having first run the function on the target PC?

bu MyDriver!DriverEntry

You have to replace “MyDriver” with the name of your driver.

HTH,
Spiro.


Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/

Hi,

Thanks for the help. I did actually try this but for some reason the
breakpoint does not trigger. I even followed the Word tutorial which uses
the ioctrl example and it worked fine there.

If on the target PC I run the driver and then on the host press the F9 key
on the DriverEntry() line in the source code, the breakpoint appears in red
and does in fact trigger when the driver on the target PC is started (using
OSR Loader). But of coarse this means that the function has executed before
I have had chance to single step it.

I did notice that all the other modules which were loaded had name that were
8-characters maximum. My driver name is scp-s0-00 and I will shorten it and
see what happens.

Regards FarmerJo

On 5/27/08, FarmerJo wrote:
> How can I set a breakpoint on the DriverEntry() function on the host PC
> without having first run the function on the target PC?
set deferred breakpoints

or if you are adventourous enough set an universal breakpoint :slight_smile: in
ntoskrnl.exe of your system the indirect call that calls your Driver
entry
viz bp 8048#### in IoPLoadDriver+0x66f in xpsp2

Hi,

It does appear that it is my driver filename being longer than eight
characters in length that was stopping the breakpoint from working. I
changed it from scp-s0-00.sys to scps000.sys and the ‘bu’ breakpoint command
works as expected.

Can anyone confirm that there is limitations on the naming of driver
filenames?

Regards FarmerJo

On 5/27/08, FarmerJo wrote:
> Hi,
>
> It does appear that it is my driver filename being longer than eight
> characters in length that was stopping the breakpoint from working. I
> changed it from scp-s0-00.sys to scps000.sys and the ‘bu’ breakpoint command
> works as expected.

nice question i notice all broken Driverentry have just eight or less
than eight chars in thier name

is drivers supoosed to have just eight chars in thier name

kbdclass!DriverEntry (f96abe64)
mouclass!DriverEntry (f96bb4e4)
serial!DriverEntry (f945a380)
serenum!DriverEntry (f987ab00)
fdc!DriverEntry (f96d4f30)
parport!DriverEntry (f96e04a2)
gameenum!DriverEntry (f9881ba0)
ctlsb16!DriverEntry (feaaff00)
cdrom!DriverEntry (f96fdbc0)
*** ERROR: Module load completed but symbols could not be loaded for vpc-s3.sys
vpc_s3+0x73ca (fea4a3ca)
dc21x4!DriverEntry (f947ece0)
audstub!DriverEntry (f9a3f500)
rasl2tp!DriverEntry (f948b780)
ndistapi!DriverEntry (f9891762)
ndiswan!DriverEntry (fea3fae0)
raspptp!DriverEntry (f949a920)
ptilink!DriverEntry (f97282e0)
raspti!DriverEntry (f973b240)
parallel!DriverEntry (f94a2bbe)
swenum!DriverEntry (f9a426c0)
update!DriverEntry (fea2a660)
flpydisk!DriverEntry (f9753b80)

> nice question i notice all broken Driverentry have just eight or less

than eight chars in thier name

is drivers supoosed to have just eight chars in thier name

just a followup it looks like none of ms drivers or any drivers that
ended up in c:\windows\system32\drivers have names that are greater
than 8 chars

did a
C:\WINDOWS\system32\drivers>dir /s /a /b *.sys > c:\driv.txt

and sorted it for char len

2

ks 2
mf 2
p3 2
sr 2

3

aec 3
afd 3
dxg 3
fdc 3
mcd 3
mup 3
pci 3
srv 3
tdi 3
vga 3

max 8 char

videoprt 8
wacompen 8
wadv07nt 8
wadv08nt 8
wadv09nt 8
wadv11nt 8
watv06nt 8
watv10nt 8
WSTCODEC 8

so prolly somewhere there is an unwritten rule

There is a written rule, but I don’t think that it’s correct anymore, at least. I thought that the deal was that 8.3 was a boot
only issue, but I believe that I’ve seen boot drivers that are longer than this and load fine.

I think (total guess here) that this is ‘bu’ and possibly other command specific issue, for two possible reasons. The first is the
prescence of ‘-’ in your driver name. Option parsing in WinDbg commands/extension commands has been known to vary between commands,
so maybe this one thinks that it is an option? Just a thought. The other is perhaps because ‘bu’ stores information as more or
less a text reference (unlike ‘bp,’ which stores it as an address), so that it may recalculate the address when the driver loads or
reloads, whereas with ‘bp,’ it’s fixed, and maybe someone assumed that they need 8.3 to store a module name.

'When you use a bp command, the breakpoint location is always converted to an address. If the code that a bp breakpoint is set on
moves, the breakpoint remains at the address and might point to different code or to an invalid location.

In contrast, a bu breakpoint is always associated with the symbolic value (typically a symbol plus an optional offset) of the
breakpoint location that is specified in the command. This association is maintained even if the code with the symbolic value is
moved or if the module that contains the location is loaded or unloaded.’

So, I guess the things that I wonder is what happens with ‘bp MOD!DriverEntry,’ where ‘MOD’ is greater than 8 characters in length,
and what about a module name that is longer than 8, but contains only [A-Za-z_0-9]?

Cheers,

mm

raj_r wrote:

> nice question i notice all broken Driverentry have just eight or less
> than eight chars in thier name
>
> is drivers supoosed to have just eight chars in thier name

just a followup it looks like none of ms drivers or any drivers that
ended up in c:\windows\system32\drivers have names that are greater
than 8 chars

did a
C:\WINDOWS\system32\drivers>dir /s /a /b *.sys > c:\driv.txt

and sorted it for char len

2

ks 2
mf 2
p3 2
sr 2

3

aec 3
afd 3
dxg 3
fdc 3
mcd 3
mup 3
pci 3
srv 3
tdi 3
vga 3

max 8 char

videoprt 8
wacompen 8
wadv07nt 8
wadv08nt 8
wadv09nt 8
wadv11nt 8
watv06nt 8
watv10nt 8
WSTCODEC 8

so prolly somewhere there is an unwritten rule

Hi all,

you can load drivers with a name longer than 8 chars even in NT4 with FAT…
maybe its just a costum use 8 dot 3 format, I dont know. See the name of the
drivers installed with vmware server, they are such a wmware-blablabla.sys

I can use WinDbg to debug drivers with long names without any troubles…

Regards,

Julian

On Tue, May 27, 2008 at 5:10 PM, Martin O’Brien
wrote:

> There is a written rule, but I don’t think that it’s correct anymore, at
> least. I thought that the deal was that 8.3 was a boot only issue, but I
> believe that I’ve seen boot drivers that are longer than this and load fine.
>
> I think (total guess here) that this is ‘bu’ and possibly other command
> specific issue, for two possible reasons. The first is the prescence of ‘-’
> in your driver name. Option parsing in WinDbg commands/extension commands
> has been known to vary between commands, so maybe this one thinks that it is
> an option? Just a thought. The other is perhaps because ‘bu’ stores
> information as more or less a text reference (unlike ‘bp,’ which stores it
> as an address), so that it may recalculate the address when the driver loads
> or reloads, whereas with ‘bp,’ it’s fixed, and maybe someone assumed that
> they need 8.3 to store a module name.
>
> ‘When you use a bp command, the breakpoint location is always converted to
> an address. If the code that a bp breakpoint is set on moves, the breakpoint
> remains at the address and might point to different code or to an invalid
> location.
>
> In contrast, a bu breakpoint is always associated with the symbolic value
> (typically a symbol plus an optional offset) of the breakpoint location that
> is specified in the command. This association is maintained even if the code
> with the symbolic value is moved or if the module that contains the location
> is loaded or unloaded.’
>
>
> So, I guess the things that I wonder is what happens with ‘bp
> MOD!DriverEntry,’ where ‘MOD’ is greater than 8 characters in length, and
> what about a module name that is longer than 8, but contains only
> [A-Za-z_0-9]?
>
>
> Cheers,
>
> mm
>
>
>
> raj_r wrote:
>
>> nice question i notice all broken Driverentry have just eight or less
>>> than eight chars in thier name
>>>
>>> is drivers supoosed to have just eight chars in thier name
>>>
>>
>> just a followup it looks like none of ms drivers or any drivers that
>> ended up in c:\windows\system32\drivers have names that are greater
>> than 8 chars
>>
>> did a
>> C:\WINDOWS\system32\drivers>dir /s /a /b *.sys > c:\driv.txt
>>
>> and sorted it for char len
>>
>> 2
>>
>> ks 2
>> mf 2
>> p3 2
>> sr 2
>>
>>
>> 3
>>
>> aec 3
>> afd 3
>> dxg 3
>> fdc 3
>> mcd 3
>> mup 3
>> pci 3
>> srv 3
>> tdi 3
>> vga 3
>>
>>
>> max 8 char
>>
>> videoprt 8
>> wacompen 8
>> wadv07nt 8
>> wadv08nt 8
>> wadv09nt 8
>> wadv11nt 8
>> watv06nt 8
>> watv10nt 8
>> WSTCODEC 8
>>
>> so prolly somewhere there is an unwritten rule
>>
>>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

Hi,

It would appear that is it something to do with the hyphen as mm suggested.
I rebuilt the driver using the name scps000abc.sys and the bu command worked
as expected, but when I used scps000-abc.sys the problem came back. Given
that the driver runs correctly on the target PC it would appear that it is a
problem with WinDbg’s bu command. Would that seem fair?

Regards FarmerJo

I would say that the hyphen might be the issue looks promising, but I haven’t any idea of if this is a ‘bu’ only issue or not, and
you’re reasoning totally loses me; that is, I don’t know what the driver running on the target pc has to with this. As far as it
being confined to only, ‘bu’ I guess I would try ‘bp’ and see what happens. If it works correctly, although it would be nice to
know which commands/metacommands/extension commands this affects, personally, I would abandon ship at that point, because the usage
of symbol names and/or address ranges varies quite a bit among commands, and I would personally be all that hot on testing them all.

Thanks,

mm

FarmerJo wrote:

Hi,

It would appear that is it something to do with the hyphen as mm suggested.
I rebuilt the driver using the name scps000abc.sys and the bu command worked
as expected, but when I used scps000-abc.sys the problem came back. Given
that the driver runs correctly on the target PC it would appear that it is a
problem with WinDbg’s bu command. Would that seem fair?

Regards FarmerJo

Hi,

What I meant was that for a two PC setup (as I am using) only the target PC
actually runs the driver code. Hence it was the target PC that I tried out a
number of driver names (including those longer than eight characters and
those including hyphens) to rule out the possibility that the OS was
objecting to the name rather than WinDbg running on the host.

In other words it appears that the OS allows any name but WinDbg does not,
if my understanding is correct of course.

Regards FarmerJo