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

I think your hunch that the .text offset is playing a role here is correct,
which is your 0x1000. That is not necessarily the correct value. Try using
the VirtualAddress of the .text section, which is in the
IMAGE_SECTION_HEADER in the file. You can get this number with,
“dumpbin /SECTION:.text driver.sys”

From: “Nate Bushman”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has no
> effect…
>Date: Mon, 28 Oct 2002 11:01:59 -0700
>
>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@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Unlimited Internet access – and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp

Thanks James, that’s a more precise technique than the one I used.

Nate

-----Original Message-----
From: James A [mailto:xxxxx@hotmail.com]
Sent: Monday, October 28, 2002 12:24 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has no effect…

I think your hunch that the .text offset is playing a role here is correct,
which is your 0x1000. That is not necessarily the correct value. Try using
the VirtualAddress of the .text section, which is in the
IMAGE_SECTION_HEADER in the file. You can get this number with,
“dumpbin /SECTION:.text driver.sys”

From: “Nate Bushman”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has no
> effect…
>Date: Mon, 28 Oct 2002 11:01:59 -0700
>
>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@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Unlimited Internet access – and 2 months free!? Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


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

You should be able to write a kernel mode exception handler that displays
the base address before calling the standard handler. You can add that info
to the dump. I am not sure of the technique, but I have heard it can be
made to work. Keep that routine simple or you could cause triple faults
which will give you less info. You could just use a debug print routine for
in house work and maybe flesh it out to write to the log files or dump file
for production. Depends upon which you need.

The creation of the map file is much easier if you use “USE-MAPSYM=1” in the
sources file. It will create that useless .sym file, but because the map
file is needed, it will be available. I know of no other way to do it
easily and have it give you all the info you want. This works in all the
various versions of BUILD for NT4, 2K, & XP.

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

Thanks James, that’s a more precise technique than the one I used.

Nate

-----Original Message-----
From: James A [mailto:xxxxx@hotmail.com]
Sent: Monday, October 28, 2002 12:24 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has no
effect…

I think your hunch that the .text offset is playing a role here is correct,
which is your 0x1000. That is not necessarily the correct value. Try using
the VirtualAddress of the .text section, which is in the
IMAGE_SECTION_HEADER in the file. You can get this number with,
“dumpbin /SECTION:.text driver.sys”

>From: “Nate Bushman”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has no
> effect…
>Date: Mon, 28 Oct 2002 11:01:59 -0700
>
>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@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Unlimited Internet access – and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


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@yoshimuni.com
To unsubscribe send a blank email to %%email.unsub%%

Well, yeah, hmm… using USE_MAPSYM=1 doesn’t generate the Lines section
in the .MAP file, which is what I’m really interested in, so I’d still
need to add -MAPINFO:LINES to my LINKER_FLAGS. I may just start logging
the base address if there is no better option. If I get in a jam it
could prove useful for bug checks 0x0A 0x1E 0x50 0x7E 0x80 0xC5 0xCC
0xCD 0xCE 0xCF 0xD0 0xD1 0xD3 0xD4 0xD5 0xD6 0xDB. All of these bug
checks return the offending instruction’s address as a parameter. Given
that there are so many, I’m surprised that the rebase’d preferred base
address is no longer honored. It seems that we’ve lost some support for
a useful debugging technique.

-----Original Message-----
From: David J. Craig [mailto:xxxxx@yoshimuni.com]
Sent: Monday, October 28, 2002 1:56 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has
no effect…

You should be able to write a kernel mode exception handler that
displays
the base address before calling the standard handler. You can add that
info
to the dump. I am not sure of the technique, but I have heard it can be
made to work. Keep that routine simple or you could cause triple faults
which will give you less info. You could just use a debug print routine
for
in house work and maybe flesh it out to write to the log files or dump
file
for production. Depends upon which you need.

The creation of the map file is much easier if you use “USE-MAPSYM=1” in
the
sources file. It will create that useless .sym file, but because the
map
file is needed, it will be available. I know of no other way to do it
easily and have it give you all the info you want. This works in all
the
various versions of BUILD for NT4, 2K, & XP.

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

Thanks James, that’s a more precise technique than the one I used.

Nate

-----Original Message-----
From: James A [mailto:xxxxx@hotmail.com]
Sent: Monday, October 28, 2002 12:24 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has
no
effect…

I think your hunch that the .text offset is playing a role here is
correct,
which is your 0x1000. That is not necessarily the correct value. Try
using
the VirtualAddress of the .text section, which is in the
IMAGE_SECTION_HEADER in the file. You can get this number with,
“dumpbin /SECTION:.text driver.sys”

>From: “Nate Bushman”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Changing preferred base address w/ rebase.exe has
no
> effect…
>Date: Mon, 28 Oct 2002 11:01:59 -0700
>
>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@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Unlimited Internet access – and 2 months free! Try MSN.
http://resourcecenter.msn.com/access/plans/2monthsfree.asp


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@yoshimuni.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%%