Re: Changing preferred base address w/ rebase.exe has no effect...

OSR_Community_User · October 28, 2002, 1:06pm

Well then, let’s say that we DO know the base address of the driver and
the address of the instruction that caused the problem, how can we then
use the .MAP file to determine the line in the source code that caused
the blue screen? I’ve used the traditional method (crash address) -
(load address) - 0x1000 but this does not yield the correct value for
lookup in the .MAP file’s Lines section.

I just placed some code in one of my drivers that intentionally
dereferences a NULL pointer. This causes Bug Check 1E, {c0000005,
ed3e30d1, 1, 0}. .drivers shows that my driver’s (PQIMount.sys) base
address is ed3e0000. Since I know exactly which line (987 decimal) in
my source produced the exception, I know which value should be
calculated in order to correctly lookup this line number. However, none
of the calculations I’ve tried arrive at the value that corresponds to
this line number in my MAP file’s Lines section.

So, here’s the data. Can you figure out how to calculate the line that
caused the problem?

987(decimal) - line in source that dereferences NULL pointer
ed3e30d1 - address at which exception occurred
ed3e0000 - base address of loaded driver

Excerpt of .MAP file:

PQIMount

Timestamp is 3dbd6775 (Mon Oct 28 09:36:05 2002)
Preferred load address is fa110000

Start Length Name Class
0001:00000000 00000080H .idata$5 CODE
0001:00000080 00000064H .rdata CODE
0001:000000f0 00005c06H .text CODE
0002:00000000 00000000H .data DATA
0002:00000000 00000470H .bss DATA
0003:00000000 00000028H .idata$2 CODE
0003:00000028 00000014H .idata$3 CODE
0003:0000003c 00000080H .idata$4 CODE
0003:000000bc 0000027eH .idata$6 CODE

Line numbers for obj\i386\pqimount.obj(C:\PQIMount\pqimount.c) segment
.text

56 0001:00000255 57 0001:0000025d 59 0001:00000264
60 0001:0000026b 62 0001:00000290 65 0001:00000295
…
…
987 0001:00002e6e 990 0001:00002e74 991 0001:00002e83
992 0001:00002e8e 993 0001:00002eaa 994 0001:00002ebb

Notice that in order to lookup line 987 we need somehow to calculate the
value 0x2e6e. Can you see any way to do this? I’ve tried all kinds of
possibilities on a hunch that the .text section’s offset is playing some
role here and none of them equate to 0x2e6e:

0x30D1 - 0x80 = 0x3051, 0x3051 - 0x2E6E = 0x1E3 (amount we’re off)
0x30D1 - 0x64 = 0x306D, 0x306D - 0x2E6E = 0x1FF (amount we’re off)
0x30D1 - 0xF0 = 0x2FE1, 0x2FE1 - 0x2E6E = 0x173 (amount we’re off)
0x30D1 - 0xE4 (0x80 + 0x64) = 0x2FED, 0x2FED - 0x2E6E = 0x17F (off)
0x30D1 - 0x170 (0x80 + 0xf0) = 0x2F61, 0x2F61 - 0x2E6E = 0xF3 (off)
0x30D1 - 0x154 (0x64 + 0xf0) = 0x2F7D, 0x2F7D - 0x2E6E = 0x10F (off)
0x20D1 - 0x80 = 0x2051
0x20D1 - 0x64 = 0x206D
0x20D1 - 0xf0 = 0x1FE1

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Monday, October 28, 2002 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has
no effect…

I could be wrong, but I think that at least with w2k and forward, you
have no control over where the kernel loader decides to load your
driver.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Nate Bushman”
To: “NT Developers Interest List”
Date: Mon, 28 Oct 2002 10:02:13 -0700
Subject: [ntdev] Changing preferred base address w/ rebase.exe has no
effect…

> Why is it that, after setting my preferred base address using
> rebase.exe, the system ignores my preferred base address when it
> actually loads my driver’s image? I’ve tried several addresses that
> all
> fall within the range of addresses that the system is already using
for
> other driver images and the system just seems to ignore my preferred
> setting when it loads my driver.
>
>
>
> The .drivers command in WinDbg shows that many of the drivers are
> loaded
> starting at 0xed000000 and another group is loaded starting around
> 0xf8000000. I’ve tried preferred base addresses such as 0xeded0000,
> 0xf0000000 and 0xfa110000 with no effect.
>
>
>
> Is there a range preferred base addresses (for non-Microsoft drivers)
> that the system will accept?
>
>
>
> If you’re wondering why I’m even bothering, well, I’d like to set up a
> tech support procedure where, when bug checks occur that provide the
> address of instructions that cause problems, our tech support people
> can
> follow a simple routine that involves looking up some info in the .MAP
> file and doing a few calculations that determine the line of code that
> caused the problem. It often seems to be the case that customers
> haven’t configured their machines to generate crash dump files and the
> only information they can provide to us is the bug check code and the
> four parameters. I’m trying to maximize the benefit of this limited
> info. Using the MAP file is good way to do this, but it’s only really
> effective if your image is loaded at a base address that you’ve
> defined.
>
>
>
> Nate
>
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to %%email.unsub%%
>

—
You are currently subscribed to ntdev as: xxxxx@powerquest.com
To unsubscribe send a blank email to %%email.unsub%%

OSR_Community_User · October 28, 2002, 2:27pm

The 0x173 bytes that lie in front of driver section #1 are the PE
header. At least, when I look at my own driver in SoftIce, this is what
I see (it’s not 0x173 bytes but a similar size). If you can calculate
the size of this given an arbitrary build of your driver you should be
able to resolve the line number correctly.

Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nate Bushman
Sent: Monday, October 28, 2002 10:02 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/
rebase.exe has no effect…

Well then, let’s say that we DO know the base address of the
driver and the address of the instruction that caused the
problem, how can we then use the .MAP file to determine the
line in the source code that caused the blue screen? I’ve
used the traditional method (crash address) - (load address)

0x1000 but this does not yield the correct value for lookup
in the .MAP file’s Lines section.

I just placed some code in one of my drivers that
intentionally dereferences a NULL pointer. This causes Bug
Check 1E, {c0000005, ed3e30d1, 1, 0}. .drivers shows that my
driver’s (PQIMount.sys) base address is ed3e0000. Since I
know exactly which line (987 decimal) in my source produced
the exception, I know which value should be calculated in
order to correctly lookup this line number. However, none of
the calculations I’ve tried arrive at the value that
corresponds to this line number in my MAP file’s Lines section.

So, here’s the data. Can you figure out how to calculate the
line that caused the problem?

987(decimal) - line in source that dereferences NULL pointer
ed3e30d1 - address at which exception occurred ed3e0000 -
base address of loaded driver

Excerpt of .MAP file:

PQIMount

Timestamp is 3dbd6775 (Mon Oct 28 09:36:05 2002)
Preferred load address is fa110000

Start Length Name Class
0001:00000000 00000080H .idata$5 CODE
0001:00000080 00000064H .rdata CODE
0001:000000f0 00005c06H .text CODE
0002:00000000 00000000H .data DATA
0002:00000000 00000470H .bss DATA
0003:00000000 00000028H .idata$2 CODE
0003:00000028 00000014H .idata$3 CODE
0003:0000003c 00000080H .idata$4 CODE
0003:000000bc 0000027eH .idata$6 CODE

Line numbers for
obj\i386\pqimount.obj(C:\PQIMount\pqimount.c) segment .text

56 0001:00000255 57 0001:0000025d 59 0001:00000264
60 0001:0000026b 62 0001:00000290 65 0001:00000295
…
…
987 0001:00002e6e 990 0001:00002e74 991 0001:00002e83
992 0001:00002e8e 993 0001:00002eaa 994 0001:00002ebb

Notice that in order to lookup line 987 we need somehow to
calculate the value 0x2e6e. Can you see any way to do this?
I’ve tried all kinds of possibilities on a hunch that the
.text section’s offset is playing some role here and none of
them equate to 0x2e6e:

0x30D1 - 0x80 = 0x3051, 0x3051 - 0x2E6E = 0x1E3 (amount we’re
off) 0x30D1 - 0x64 = 0x306D, 0x306D - 0x2E6E = 0x1FF (amount
we’re off) 0x30D1 - 0xF0 = 0x2FE1, 0x2FE1 - 0x2E6E = 0x173
(amount we’re off) 0x30D1 - 0xE4 (0x80 + 0x64) = 0x2FED,
0x2FED - 0x2E6E = 0x17F (off) 0x30D1 - 0x170 (0x80 + 0xf0) =
0x2F61, 0x2F61 - 0x2E6E = 0xF3 (off) 0x30D1 - 0x154 (0x64 +
0xf0) = 0x2F7D, 0x2F7D - 0x2E6E = 0x10F (off) 0x20D1 - 0x80 =
0x2051 0x20D1 - 0x64 = 0x206D 0x20D1 - 0xf0 = 0x1FE1

-----Original Message-----
From: Mark Roddy [mailto:xxxxx@hollistech.com]
Sent: Monday, October 28, 2002 10:20 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/
rebase.exe has no effect…

I could be wrong, but I think that at least with w2k and forward, you
have no control over where the kernel loader decides to load
your driver.

===========================
Mark Roddy
Consultant, Microsoft DDK MVP
Hollis Technology Solutions
xxxxx@hollistech.com
www.hollistech.com
603-321-1032

-----Original Message-----
From: “Nate Bushman”
> To: “NT Developers Interest List”
> Date: Mon, 28 Oct 2002 10:02:13 -0700
> Subject: [ntdev] Changing preferred base address w/ rebase.exe has no
> effect…
>
> > Why is it that, after setting my preferred base address using
> > rebase.exe, the system ignores my preferred base address when it
> > actually loads my driver’s image? I’ve tried several
> addresses that
> > all fall within the range of addresses that the system is already
> > using
> for
> > other driver images and the system just seems to ignore my
> preferred
> > setting when it loads my driver.
> >
> >
> >
> > The .drivers command in WinDbg shows that many of the drivers are
> > loaded starting at 0xed000000 and another group is loaded starting
> > around 0xf8000000. I’ve tried preferred base addresses such as
> > 0xeded0000, 0xf0000000 and 0xfa110000 with no effect.
> >
> >
> >
> > Is there a range preferred base addresses (for
> non-Microsoft drivers)
> > that the system will accept?
> >
> >
> >
> > If you’re wondering why I’m even bothering, well, I’d like
> to set up a
> > tech support procedure where, when bug checks occur that
> provide the
> > address of instructions that cause problems, our tech
> support people
> > can follow a simple routine that involves looking up some
> info in the
> > .MAP file and doing a few calculations that determine the
> line of code
> > that caused the problem. It often seems to be the case
> that customers
> > haven’t configured their machines to generate crash dump
> files and the
> > only information they can provide to us is the bug check
> code and the
> > four parameters. I’m trying to maximize the benefit of this limited
> > info. Using the MAP file is good way to do this, but it’s
> only really
> > effective if your image is loaded at a base address that you’ve
> > defined.
> >
> >
> >
> > Nate
> >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> > unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@powerquest.com To unsubscribe send a blank email
> to %%email.unsub%%
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@nryan.com
> To unsubscribe send a blank email to %%email.unsub%%
>

OSR_Community_User · October 28, 2002, 2:32pm

Okay, I’ve figured it out. I was missing a critical piece of
information that was necessary for the calculation - the “base of code”
value returned from dumpbin.exe.

For anyone interested, if you want to use your .MAP file to determine
which line in your code caused a bug check, for those bug checks that
list the address of the instruction that caused the bug check, you’ll
need to do the following:

First, set up your SOURCES file so that the linker will generate a .MAP
file at build time. Here’s the portion of my SOURCES file for an NT4
driver. Yeah, I know the statements are identical, but I left 'em in
there because they won’t be identical if you use this snippet with the
W2K DDK build environment - you’ll have objfre and objchk in the paths
instead:

!IF $(FREEBUILD)
LINKER_FLAGS=$(LINKER_FLAGS) -MAP:.\obj\i386$(TARGETNAME).map \
-MAPINFO:EXPORTS -MAPINFO:LINES -MAPINFO:FIXUPS
!ELSE
LINKER_FLAGS=$(LINKER_FLAGS) -MAP:.\obj\i386$(TARGETNAME).map \
-MAPINFO:EXPORTS -MAPINFO:LINES -MAPINFO:FIXUPS
!ENDIF

Now, let’s say that you just got a bug check and you’re having trouble
locating the offending code. If the bug check includes the address of
the instruction that caused the problem then do the following:

Use WinDbg’s “.drivers” command and find the base address of your
driver.
Use dumpbin.exe on your driver.sys image and find the “base of code”
address (which is a HEX value).
Perform this calculation:
(address of instruction that caused problem) -
(the base address of your driver shown by .drivers) -
(the “base of code” value shown by dumpbin.exe)
= LookupValue in .MAP file’s Lines section
Go to the Lines section (the third section) of your
.MAP file and lookup the line whose corresponding
offset is >= LookupValue and where the next line’s
offset value is > LookupValue. This will be the line
in your source code that caused the problem.

Ideally you wouldn’t have to use the .drivers command in WinDbg to find
your driver’s base address. I tried using rebase.exe to force my driver
to load to a preferred base address but it doesn’t work on W2K. Mark
thinks it won’t work on anything above NT4. That’s kind of a bummer but
oh well. It would be cool if you could, for the most part, count on
your driver loading to a particular base address because then when your
customers called you with a bug check and they only wrote down the bug
check code and params, you’d still be able to identify exactly which
source line caused the problem.

Nate

-----Original Message-----
From: Nate Bushman
Sent: Monday, October 28, 2002 11:02 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has
no effect…