last control transfer and differences of addresses

NTDEV
1

Hi,
there is a definition on my BSOD error page; LAST_CONTROL_TRANSFER from x to y; what is it mean?
I have a problem about overwriting memory (BAD_POOL_HEADER (19)), i wonder about different addresses at STACK_TEXT;

LAST_CONTROL_TRANSFER: from fffff800029716d2 to fffff800028727a0

STACK_TEXT:
fffff880033ddea8 fffff800029716d2 : 0000000000000020 fffffa8003d21660 0000000000000065 fffff800028b8c24 : nt!DbgBreakPointWithStatus
fffff880033ddeb0 fffff800029724be : fffffa8000000003 0000000000000000 fffff800028b57f0 0000000000000019 : nt!KiBugCheckDebugBreak+0x12
fffff880033ddf10 fffff8000287a844 : 0000000000000000 0000000000000001 fffff80002a09880 0000000000000000 : nt!KeBugCheck2+0x71e
fffff880033de5e0 fffff800029ad6d3 : 0000000000000019 0000000000000020 fffffa80039d4c90 fffffa80039d4d10 : nt!KeBugCheckEx+0x104
fffff880033de620 fffff80002899d9e : 00000000a0000003 0000000000000001 fffff80020206f49 00000000000006f8 : nt!ExDeferredFreePool+0x12c4
fffff880033de6d0 fffff8000287d0dd : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 : nt!IopCompleteRequest+0x5ce
fffff880033de7a0 fffff88003deb139 : 000000000000000e fffffa80039d4c00 fffff88004200000 0000000000000000 : nt!IopfCompleteRequest+0x75d
fffff880033de880 fffff88003df0d79 : fffffa800420bb10 fffffa8000000000 000000000000001c fffff880033de970 : apco25_vpcc_device_driver!CompleteRequest+0x39 [c:\osman\apco25_vpcc_device_driver\apco25_vpcc_driver_entry.cpp @ 286]
fffff880033de8b0 fffff88003c67825 : fffffa8002f38060 fffffa800420bb10 fffffa8002ae5260 fffffa800420bb10 : apco25_vpcc_device_driver!DispatchControl+0x5f9 [c:\osman\apco25_vpcc_device_driver\apco25_vpcc_read_write.cpp @ 746]
fffff880033de9b0 fffff80002b93547 : fffffa8003aeaf20 fffff880033deca0 fffffa8000000000 fffffa8003aeaf20 : ksthunk!CKernelFilterDevice::DispatchIrp+0x11d
fffff880033dea10 fffff80002b93da6 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!IopXxxControlFile+0x607
fffff880033deb40 fffff80002879993 : 0000000000002515 000000000886e7f8 fffffa8002ab7d10 0000007fffffffff : nt!NtDeviceIoControlFile+0x56
fffff880033debb0 0000000074032dd9 : 0000000074032932 0000000077220190 0000000000000023 0000000000000202 : nt!KiSystemServiceCopyEnd+0x13

Till the error log, some first 32 bit value of addresses is fffffa80, others fffff880. I expected that all first 32 bit values are the same. Why are they different? any idea?

Osman

2

xxxxx@netas.com.tr wrote:

there is a definition on my BSOD error page; LAST_CONTROL_TRANSFER from x to y; what is it mean?

That tells you the last jump instruction that was executed. That’s
stored in one of the machine-specific registers in the CPU.

I have a problem about overwriting memory (BAD_POOL_HEADER (19)), i wonder about different addresses at STACK_TEXT;
…
Till the error log, some first 32 bit value of addresses is fffffa80, others fffff880. I expected that all first 32 bit values are the same. Why are they different? any idea?

The virtual address space is divided into various different sections for
various purposes. It’s an implementation detail of the operating
system. Based upon what you have there, it looks like fffff880xxxxxxxx
is used for stack, fffff800xxxxxxxx is used for instructions, and
fffffa80xxxxxxxx is used for data.

Why do you expect them to be the same?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

3

The parameters of driver codes only porting 32 bit to 64 bit, i expected
that only last 32 bit value of addresses must change(i think), so i
thought that there is an porting or user-mode error the addresses begin
FFFFFA80…

Osman

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, March 24, 2011 6:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] last control transfer and differences of addresses

xxxxx@netas.com.tr wrote:

there is a definition on my BSOD error page; LAST_CONTROL_TRANSFER
from x to y; what is it mean?

That tells you the last jump instruction that was executed. That’s
stored in one of the machine-specific registers in the CPU.

I have a problem about overwriting memory (BAD_POOL_HEADER (19)), i
wonder about different addresses at STACK_TEXT; …
Till the error log, some first 32 bit value of addresses is fffffa80,
others fffff880. I expected that all first 32 bit values are the same.
Why are they different? any idea?

The virtual address space is divided into various different sections for
various purposes. It’s an implementation detail of the operating
system. Based upon what you have there, it looks like fffff880xxxxxxxx
is used for stack, fffff800xxxxxxxx is used for instructions, and
fffffa80xxxxxxxx is used for data.

Why do you expect them to be the same?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV 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

4

Osman TOKER wrote:

The parameters of driver codes only porting 32 bit to 64 bit, i expected
that only last 32 bit value of addresses must change(i think), so i
thought that there is an porting or user-mode error the addresses begin
FFFFFA80…

No, that’s the kernel-mode region in a 64-bit system. The current x64
processors all require that the top 17 bits of all addresses be
identical. So, all 64-bit addresses will be either:
00000000,00000000 to 00007fff,ffffffff – user mode
or
ffff8000,00000000 to ffffffff,ffffffff – kernel mode

The kernel region is further subdivided by Windows (just by software
convention) into the kinds of regions I described in the last message.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

5

The last jump address is rarely going to be of any interest when you have
bad pool header; the code that did the damage probably happened billions of
instructions in the past.

Use the Driver Verifier and use special storage pools. That would be a
better start.

In years of debugging, I have never found the last control transfer address
to be of the slightest use. I view it largely as noise. I’m sure there
must be conditions under which it is useful, but I have yet to discover one
in my own programming.

Bad pool header causes:
* Taking a long walk off a short pier (memory overrun on a heap-allocated
structure; watch for off-by-one array indices, sizeof(something*) when you
mean sizeof(something), and any uses of strcpy/strcat/sprintf or the
wcs-equivalents, which should never be used in serious programming
* Uninitialized pointers on the stack. Every pointer variable should be
declared as
whatever * p = NULL;
or
whatever * p = initialization_expression;
but never, ever
whatever * p;
If you believe that assigning NULL is “inefficient”, please examine your
fundamental premises of good programming. If the =NULL is redundant, the
compiler will eliminate it for you!
* Uninitialized pointers in heap-allocated structures
* Freeing storage before you are done with it. Most commonly caused by race
conditions where someone frees storage when another thread might still be
using it, but this is not the only cause

Look carefully at all these. Note that bad pool header reports when the
damage is *detected*, not when it is *caused*; or, as I explain it, “you
just fell into an open manhole. The problem is not that you fell in; the
problem is that last week someone took the cover off, and your job is to
find out who did this last week”
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Osman TOKER
Sent: Friday, March 25, 2011 3:32 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] last control transfer and differences of addresses

The parameters of driver codes only porting 32 bit to 64 bit, i expected
that only last 32 bit value of addresses must change(i think), so i
thought that there is an porting or user-mode error the addresses begin
FFFFFA80…

Osman

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Thursday, March 24, 2011 6:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] last control transfer and differences of addresses

xxxxx@netas.com.tr wrote:

there is a definition on my BSOD error page; LAST_CONTROL_TRANSFER
from x to y; what is it mean?

That tells you the last jump instruction that was executed. That’s
stored in one of the machine-specific registers in the CPU.

I have a problem about overwriting memory (BAD_POOL_HEADER (19)), i
wonder about different addresses at STACK_TEXT; …
Till the error log, some first 32 bit value of addresses is fffffa80,
others fffff880. I expected that all first 32 bit values are the same.
Why are they different? any idea?

The virtual address space is divided into various different sections for
various purposes. It’s an implementation detail of the operating
system. Based upon what you have there, it looks like fffff880xxxxxxxx
is used for stack, fffff800xxxxxxxx is used for instructions, and
fffffa80xxxxxxxx is used for data.

Why do you expect them to be the same?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

NTDEV 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

NTDEV 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

–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.