edx corruption

Hi all

I’ve been looking at a memory dump and I came across the following
anomaly:

The following disassembly has been taken from windbg with no omissions
between the first and last line. The edx register is initialised on the
first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] // edx is set
here

f7a35f3 8b1a mov ebx,[edx] // edx must
be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)

bf7a3609 8b4304 mov eax,[ebx+0x4] // and it
goes bang here

On the second line, edx must point to a valid address or the system
would have bugchecked when it was dereferenced. However when the
bugcheck does finally occur, the following registers are shown:

TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)

ErrCode = 00000000

eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
edi=e2693eb8

eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei ng nz na
pe nc

What I can’t figure out is why edx (which according to the disassembly
has not been changed since the first line) no longer points to a valid
address when it must have been valid on line 2. The other registers seem
reasonable and the address used to initialise edx, [edi+18], still looks
valid. The conditional branch is just a NULL pointer check and branches
to the end of the function.

Any thoughts ??

Regards

Mark

The final line uses ebx, not edx. If you are asking about why edx might
have changed and don’t care about the ebx reference, the question to ask
is what value is in [edi+18] and what !pte @edx says. 6 is not
necessarily a bad address, as low memory can be mapped valid.

Jason


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Cook, Mark
Sent: Wednesday, June 29, 2005 10:39 AM
To: Kernel Debugging Interest List
Subject: [windbg] edx corruption

Hi all

I’ve been looking at a memory dump and I came across the following
anomaly:

The following disassembly has been taken from windbg with no omissions
between the first and last line. The edx register is initialised on the
first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] // edx is set
here

f7a35f3 8b1a mov ebx,[edx] // edx must
be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)

bf7a3609 8b4304 mov eax,[ebx+0x4] // and it
goes bang here

On the second line, edx must point to a valid address or the system
would have bugchecked when it was dereferenced. However when the
bugcheck does finally occur, the following registers are shown:

TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)

ErrCode = 00000000

eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
edi=e2693eb8

eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei ng nz na
pe nc

What I can’t figure out is why edx (which according to the disassembly
has not been changed since the first line) no longer points to a valid
address when it must have been valid on line 2. The other registers seem
reasonable and the address used to initialise edx, [edi+18], still looks
valid. The conditional branch is just a NULL pointer check and branches
to the end of the function.

Any thoughts ??

Regards

Mark


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Like Jason said … —609 is using edx, it is using ebx, which is tested in 609 and 603. Its not zero so you fall through and use ebx+4 as a pointer to load eax. As to how inline code like this can go sour is easy: an interrupt occurred and the ISR did not preserve the registers properly.

The personal opinion of
Gary G. Little
“Cook, Mark” <mark.cook> wrote in message news:xxxxx@windbg…
Hi all

I’ve been looking at a memory dump and I came across the following anomaly:

The following disassembly has been taken from windbg with no omissions between the first and last line. The edx register is initialised on the first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] // edx is set here

f7a35f3 8b1a mov ebx,[edx] // edx must be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)

bf7a3609 8b4304 mov eax,[ebx+0x4] // and it goes bang here

On the second line, edx must point to a valid address or the system would have bugchecked when it was dereferenced. However when the bugcheck does finally occur, the following registers are shown:

TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)

ErrCode = 00000000

eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000 edi=e2693eb8

eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei ng nz na pe nc

What I can’t figure out is why edx (which according to the disassembly has not been changed since the first line) no longer points to a valid address when it must have been valid on line 2. The other registers seem reasonable and the address used to initialise edx, [edi+18], still looks valid. The conditional branch is just a NULL pointer check and branches to the end of the function.

Any thoughts ??

Regards

Mark</mark.cook>

Cook, Mark wrote:

Hi all

I’ve been looking at a memory dump and I came across the following
anomaly:

The following disassembly has been taken from windbg with no omissions
between the first and last line. The edx register is initialised on
the first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] // edx is set here

bf7a35f3 8b1a mov ebx,[edx] // edx must be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)
>
> bf7a3609 8b4304 mov eax,[ebx+0x4] // and it goes bang here
>
> On the second line, edx must point to a valid address or the system
> would have bugchecked when it was dereferenced. However when the
> bugcheck does finally occur, the following registers are shown:
>
> TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)
>
> ErrCode = 00000000
>
> eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
> edi=e2693eb8
>
> eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei ng nz na pe nc
>

I have two guesses. My first guess would be that there is another code
path that leads to bf7a3609 without starting at bf7a35f0. Does
[ebp-0x1f8] still equal ebx?

My second guess would be that [edi+0x18] actually equals 6. It is
unlikely but not impossible that e85a86f8 could have come from linear
address 00000006. That would be the segment from the real-mode INT 1
vector and the offset from the real-mode INT 2 vector.


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

Another possibility is that ebx WAS zero, the jump was taken, some
recovery magic performed and then jumped back. It is difficult to draw
conclusions from a mere snippet of code. And while it is possible that
some intervening function (interrupt, APC, DPC) has trashed the
register, that’s relatively uncommon because that sort of thing blows up
surprisingly quickly, so it wouldn’t be my FIRST guess (although
eventually I might get there after checking out other possibilities).

For example, this could be a check of a single linked list to see if
there is an entry and if not it is allocated and then the code sequence
executed. I’m trying to think of how I’d structure this in C code -
perhaps a loop construct.

As Jason points out, there are also REAL process contexts in which page
0 is used, so you might want to verify that 6 is really an invalid
address.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Wednesday, June 29, 2005 2:37 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] edx corruption

Like Jason said … —609 is using edx, it is using ebx, which is
tested in 609 and 603. Its not zero so you fall through and use ebx+4 as
a pointer to load eax. As to how inline code like this can go sour is
easy: an interrupt occurred and the ISR did not preserve the registers
properly.

The personal opinion of

Gary G. Little

“Cook, Mark” <mark.cook> wrote in message
news:xxxxx@windbg…

Hi all

I’ve been looking at a memory dump and I came across the
following anomaly:

The following disassembly has been taken from windbg with no
omissions between the first and last line. The edx register is
initialised on the first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] //
edx is set here

f7a35f3 8b1a mov ebx,[edx] //
edx must be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)

bf7a3609 8b4304 mov eax,[ebx+0x4] //
and it goes bang here

On the second line, edx must point to a valid address or the
system would have bugchecked when it was dereferenced. However when the
bugcheck does finally occur, the following registers are shown:

TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)

ErrCode = 00000000

eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
edi=e2693eb8

eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei
ng nz na pe nc

What I can’t figure out is why edx (which according to the
disassembly has not been changed since the first line) no longer points
to a valid address when it must have been valid on line 2. The other
registers seem reasonable and the address used to initialise edx,
[edi+18], still looks valid. The conditional branch is just a NULL
pointer check and branches to the end of the function.

Any thoughts ??

Regards

Mark


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mark.cook>

Thanks to all for your input. Tony is correct of course in that it is
difficult to see what the code is doing from half a dozen lines of
assembly language but I had tried to keep it brief to make the problem
easier to see. This said however, his analysis of the code is scarily
accurate. This code fragment is exactly what Tony indicated - it is the
start of a while loop which is iterating through a linked list. The
evaluation on line 5 equates to the following line of code where
currentHistoryPtr is stored in EBX.

while (NULL != currentHistoryPtr)

My initial thought was also that this was caused by the branch
instruction but once this branch has been taken, the loop completes so
this section of code will not be called from elsewhere.

Now if I look where EDX was originally loaded from [EDI+0x18] on line 1
of the listing, I see the following:

0: kd> dd [edi+0x18]

e2693ed0 e2e045f8 e14ee1b8 00000000 6f43222c

e2693ee0 52494643 00000009 e2692e28 00000c87

e2693ef0 00000000 00000002 00000000 00000000

e2693f00 e2e04638 e15804d8 00000000 30303639

e2693f10 52494643 00000009 e2692e78 00000c87

e2693f20 00000000 00000000 00000000 00000000

e2693f30 e2779cf8 e1580578 00000000 32393122

e2693f40 52494643 00000009 e2692ec8 00000c87

…but if I dereference this to get ebx (see line 2 of listing) I now
see.

0: kd> dd poi (edi+0x18)

e2e045f8 00000000 00000000 00000000 00000000

e2e04608 00000000 00000000 00000000 00000000

e2e04618 00000000 00000000 00000000 00000000

e2e04628 00000000 00000000 00000000 00000000

e2e04638 00000000 00000000 00000000 00000000

e2e04648 00000000 00000000 00000000 00000000

e2e04658 00000000 00000000 00000000 00000000

e2e04668 00000000 00000000 00000000 00000000

This is different to the value of EBX which indicates that the value
that EDX was pointing to has changed which is undoubtedly the cause of
my system crash. However, my question is aimed at understanding how EDX
itself (instead of what it points to) has changed rather than
understanding why the bugcheck occurred.

Since EBX was loaded from EDX on line two of the listing, it follows
that before EDX was trashed, it was pointing to the current value of EBX
(e85a86f8) and in fact this can be confirmed from line 3 of the listing
where EBX (e85a86f8) is cached in a local variable at [EBP-1F8] since
this value is also e85a86f8.

kd> dd [ebp-1f8]

bfd40b04 e85a86f8 00000000 e14ee1b8 e2693eb8

bfd40b14 e15b4ad0 00010000 0003f5bd 00000002

bfd40b24 00000c87 00440076 005c003a 00480045

bfd40b34 0044004e 00540041 0053004f 0054005c

bfd40b44 00430045 0049004e 005c0043 0070004f

bfd40b54 004d0079 006e0061 004a005c 00700061

bfd40b64 00630065 00630065 00650068 005c0061

bfd40b74 006f0043 00720072 006f0065 006a005c

The bottom line therefore is that even if the memory that EDX was
pointing to has changed from e85a86f8 to zero, I still can’t see why
EDX itself has changed from e2e045f8 to 00000006 between lines 3 and 7.

I take Gary’s point that the context may not have been correctly
preserved correctly when an ISR or context switch occurred but my driver
is a file system filter driver so I haven’t had to implement this
logic.

As a slight aside, I followed Jason’s advice and tried !pte on EDX but
this was invalid (see below).

0: kd> !pte 6

00000006 - PDE at C0300000 PTE at C0000000

contains 0A280867 contains 00000000

pfn a280 --DA–UWV not valid

The previous address of edx (taken from edi+0x18 above) is still valid
though:

0: kd> !pte e2e045f8

E2E045F8 - PDE at C0300E2C PTE at C038B810

contains 788EE963 contains 7AA2D805

pfn 788ee G-DA–KWV pfn 7aa2d ------URV

If anybody has any thoughts on this, please share them with me.

Regards

Mark


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: 29 June 2005 19:54
To: Kernel Debugging Interest List
Subject: RE: [windbg] edx corruption

Another possibility is that ebx WAS zero, the jump was taken, some
recovery magic performed and then jumped back. It is difficult to draw
conclusions from a mere snippet of code. And while it is possible that
some intervening function (interrupt, APC, DPC) has trashed the
register, that’s relatively uncommon because that sort of thing blows up
surprisingly quickly, so it wouldn’t be my FIRST guess (although
eventually I might get there after checking out other possibilities).

For example, this could be a check of a single linked list to see if
there is an entry and if not it is allocated and then the code sequence
executed. I’m trying to think of how I’d structure this in C code -
perhaps a loop construct.

As Jason points out, there are also REAL process contexts in which page
0 is used, so you might want to verify that 6 is really an invalid
address.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Wednesday, June 29, 2005 2:37 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] edx corruption

Like Jason said … —609 is using edx, it is using ebx, which is
tested in 609 and 603. Its not zero so you fall through and use ebx+4 as
a pointer to load eax. As to how inline code like this can go sour is
easy: an interrupt occurred and the ISR did not preserve the registers
properly.

The personal opinion of

Gary G. Little

“Cook, Mark” <mark.cook> wrote in message
news:xxxxx@windbg…

Hi all

I’ve been looking at a memory dump and I came across the
following anomaly:

The following disassembly has been taken from windbg with no
omissions between the first and last line. The edx register is
initialised on the first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] //
edx is set here

f7a35f3 8b1a mov ebx,[edx] //
edx must be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)

bf7a3609 8b4304 mov eax,[ebx+0x4] //
and it goes bang here

On the second line, edx must point to a valid address or the
system would have bugchecked when it was dereferenced. However when the
bugcheck does finally occur, the following registers are shown:

TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)

ErrCode = 00000000

eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
edi=e2693eb8

eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei
ng nz na pe nc

What I can’t figure out is why edx (which according to the
disassembly has not been changed since the first line) no longer points
to a valid address when it must have been valid on line 2. The other
registers seem reasonable and the address used to initialise edx,
[edi+18], still looks valid. The conditional branch is just a NULL
pointer check and branches to the end of the function.

Any thoughts ??

Regards

Mark


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mark.cook>

…one other thing I should have mentioned is the context in which this
function is called. During the completion routine for an IRP_MJ_WRITE
request, the details I require are copied to a data structure and the
IRP is allowed to complete. This data structure is queued off to a work
queue where it is processed at passive level by my worker thread and it
is during this processing that the problem occurs.


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Cook, Mark
Sent: 30 June 2005 12:30
To: Kernel Debugging Interest List
Subject: RE: [windbg] edx corruption

Thanks to all for your input. Tony is correct of course in that it is
difficult to see what the code is doing from half a dozen lines of
assembly language but I had tried to keep it brief to make the problem
easier to see. This said however, his analysis of the code is scarily
accurate. This code fragment is exactly what Tony indicated - it is the
start of a while loop which is iterating through a linked list. The
evaluation on line 5 equates to the following line of code where
currentHistoryPtr is stored in EBX.

while (NULL != currentHistoryPtr)

My initial thought was also that this was caused by the branch
instruction but once this branch has been taken, the loop completes so
this section of code will not be called from elsewhere.

Now if I look where EDX was originally loaded from [EDI+0x18] on line 1
of the listing, I see the following:

0: kd> dd [edi+0x18]

e2693ed0 e2e045f8 e14ee1b8 00000000 6f43222c

e2693ee0 52494643 00000009 e2692e28 00000c87

e2693ef0 00000000 00000002 00000000 00000000

e2693f00 e2e04638 e15804d8 00000000 30303639

e2693f10 52494643 00000009 e2692e78 00000c87

e2693f20 00000000 00000000 00000000 00000000

e2693f30 e2779cf8 e1580578 00000000 32393122

e2693f40 52494643 00000009 e2692ec8 00000c87

…but if I dereference this to get ebx (see line 2 of listing) I now
see.

0: kd> dd poi (edi+0x18)

e2e045f8 00000000 00000000 00000000 00000000

e2e04608 00000000 00000000 00000000 00000000

e2e04618 00000000 00000000 00000000 00000000

e2e04628 00000000 00000000 00000000 00000000

e2e04638 00000000 00000000 00000000 00000000

e2e04648 00000000 00000000 00000000 00000000

e2e04658 00000000 00000000 00000000 00000000

e2e04668 00000000 00000000 00000000 00000000

This is different to the value of EBX which indicates that the value
that EDX was pointing to has changed which is undoubtedly the cause of
my system crash. However, my question is aimed at understanding how EDX
itself (instead of what it points to) has changed rather than
understanding why the bugcheck occurred.

Since EBX was loaded from EDX on line two of the listing, it follows
that before EDX was trashed, it was pointing to the current value of EBX
(e85a86f8) and in fact this can be confirmed from line 3 of the listing
where EBX (e85a86f8) is cached in a local variable at [EBP-1F8] since
this value is also e85a86f8.

kd> dd [ebp-1f8]

bfd40b04 e85a86f8 00000000 e14ee1b8 e2693eb8

bfd40b14 e15b4ad0 00010000 0003f5bd 00000002

bfd40b24 00000c87 00440076 005c003a 00480045

bfd40b34 0044004e 00540041 0053004f 0054005c

bfd40b44 00430045 0049004e 005c0043 0070004f

bfd40b54 004d0079 006e0061 004a005c 00700061

bfd40b64 00630065 00630065 00650068 005c0061

bfd40b74 006f0043 00720072 006f0065 006a005c

The bottom line therefore is that even if the memory that EDX was
pointing to has changed from e85a86f8 to zero, I still can’t see why
EDX itself has changed from e2e045f8 to 00000006 between lines 3 and 7.

I take Gary’s point that the context may not have been correctly
preserved correctly when an ISR or context switch occurred but my driver
is a file system filter driver so I haven’t had to implement this
logic.

As a slight aside, I followed Jason’s advice and tried !pte on EDX but
this was invalid (see below).

0: kd> !pte 6

00000006 - PDE at C0300000 PTE at C0000000

contains 0A280867 contains 00000000

pfn a280 --DA–UWV not valid

The previous address of edx (taken from edi+0x18 above) is still valid
though:

0: kd> !pte e2e045f8

E2E045F8 - PDE at C0300E2C PTE at C038B810

contains 788EE963 contains 7AA2D805

pfn 788ee G-DA–KWV pfn 7aa2d ------URV

If anybody has any thoughts on this, please share them with me.

Regards

Mark


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: 29 June 2005 19:54
To: Kernel Debugging Interest List
Subject: RE: [windbg] edx corruption

Another possibility is that ebx WAS zero, the jump was taken, some
recovery magic performed and then jumped back. It is difficult to draw
conclusions from a mere snippet of code. And while it is possible that
some intervening function (interrupt, APC, DPC) has trashed the
register, that’s relatively uncommon because that sort of thing blows up
surprisingly quickly, so it wouldn’t be my FIRST guess (although
eventually I might get there after checking out other possibilities).

For example, this could be a check of a single linked list to see if
there is an entry and if not it is allocated and then the code sequence
executed. I’m trying to think of how I’d structure this in C code -
perhaps a loop construct.

As Jason points out, there are also REAL process contexts in which page
0 is used, so you might want to verify that 6 is really an invalid
address.

Regards,

Tony

Tony Mason

Consulting Partner

OSR Open Systems Resources, Inc.

http://www.osr.com http:</http:>


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Wednesday, June 29, 2005 2:37 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] edx corruption

Like Jason said … —609 is using edx, it is using ebx, which is
tested in 609 and 603. Its not zero so you fall through and use ebx+4 as
a pointer to load eax. As to how inline code like this can go sour is
easy: an interrupt occurred and the ISR did not preserve the registers
properly.

The personal opinion of

Gary G. Little

“Cook, Mark” <mark.cook> wrote in message
news:xxxxx@windbg…

Hi all

I’ve been looking at a memory dump and I came across the
following anomaly:

The following disassembly has been taken from windbg with no
omissions between the first and last line. The edx register is
initialised on the first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] //
edx is set here

f7a35f3 8b1a mov ebx,[edx] //
edx must be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)

bf7a3609 8b4304 mov eax,[ebx+0x4] //
and it goes bang here

On the second line, edx must point to a valid address or the
system would have bugchecked when it was dereferenced. However when the
bugcheck does finally occur, the following registers are shown:

TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)

ErrCode = 00000000

eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
edi=e2693eb8

eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei
ng nz na pe nc

What I can’t figure out is why edx (which according to the
disassembly has not been changed since the first line) no longer points
to a valid address when it must have been valid on line 2. The other
registers seem reasonable and the address used to initialise edx,
[edi+18], still looks valid. The conditional branch is just a NULL
pointer check and branches to the end of the function.

Any thoughts ??

Regards

Mark


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to %%email.unsub%%


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mark.cook>

I can think of at least three reasons:

  1. an interrupt handler didn’t properly save/restore registers (assuming
    you run at a low IRQL that can take interrupts)
  2. random memory corruption when such save/restore happened (assuming
    you run at a low IRQL, again)
  3. something jumped to an address after bf7a35f0

My money is on 3). In fact, my guess is something jumped straight to
bf7a3609.

Now, wouldn’t it be nice if there was some way of getting the address of
the last branch/jump source instruction? You would have thought they
would have added a debug register for this by now…

Cheers,

/ h+

Cook, Mark wrote:

Hi all

I’ve been looking at a memory dump and I came across the following anomaly:

The following disassembly has been taken from windbg with no omissions
between the first and last line. The edx register is initialised on the
first line and the bugcheck occurs on the last.

bf7a35f0 8b5718 mov edx,[edi+0x18] // edx is set
here

f7a35f3 8b1a mov ebx,[edx] // edx must
be OK here…

bf7a35f5 899d08feffff mov [ebp-0x1f8],ebx

bf7a35fb 8b8d04ffffff mov ecx,[ebp-0xfc]

bf7a3601 85db test ebx,ebx

bf7a3603 0f8492010000 je (bf7a379b)
>
> bf7a3609 8b4304 mov eax,[ebx+0x4] // and it
> goes bang here
>
>
>
>
>
> On the second line, edx must point to a valid address or the system
> would have bugchecked when it was dereferenced. However when the
> bugcheck does finally occur, the following registers are shown:
>
>
>
> TRAP_FRAME: bfd40a74 – (.trap ffffffffbfd40a74)
>
> ErrCode = 00000000
>
> eax=00000007 ebx=e85a86f8 ecx=00000007 edx=00000006 esi=00080000
> edi=e2693eb8
>
> eip=bf7a3609 esp=bfd40ae8 ebp=bfd40cfc iopl=0 nv up ei ng nz na
> pe nc
>
>
>
>
>
> What I can’t figure out is why edx (which according to the disassembly
> has not been changed since the first line) no longer points to a valid
> address when it must have been valid on line 2. The other registers seem
> reasonable and the address used to initialise edx, [edi+18], still looks
> valid. The conditional branch is just a NULL pointer check and branches
> to the end of the function.
>
>
>
> Any thoughts ??
>
>
>
> Regards
>
>
>
> Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com

Cook, Mark wrote:

Thanks to all for your input. Tony is correct of course in that it is
difficult to see what the code is doing from half a dozen lines of
assembly language but I had tried to keep it brief to make the problem
easier to see. This said however, his analysis of the code is scarily
accurate. This code fragment is exactly what Tony indicated – it is
the start of a while loop which is iterating through a linked list.
The evaluation on line 5 equates to the following line of code where
currentHistoryPtr is stored in EBX.

while (NULL != currentHistoryPtr)

My initial thought was also that this was caused by the branch
instruction but once this branch has been taken, the loop completes so
this section of code will not be called from elsewhere.

This is different to the value of EBX which indicates that the value
that EDX was pointing to has changed which is undoubtedly the cause of
my system crash. However, my question is aimed at understanding how
EDX itself (instead of what it points to) has changed rather than
understanding why the bugcheck occurred.

Since EBX was loaded from EDX on line two of the listing, it follows
that before EDX was trashed, it was pointing to the current value of
EBX (e85a86f8) and in fact this can be confirmed from line 3 of the
listing where EBX (e85a86f8) is cached in a local variable at
[EBP-1F8] since this value is also e85a86f8.

The bottom line therefore is that even if the memory that EDX was
pointing to has changed from e85a86f8 to zero, I still can’t see why
EDX itself has changed from e2e045f8 to 00000006 between lines 3 and 7.

You said yourself that this was part of a loop. If you look at the
BOTTOM of the loop, where does it jump back to? It’s quite possible that
lines 1 & 2 (which load edx) are part of the loop initialization, and
that the bottom of the loop jumps back to line 3 (which saves ebx into a
temporary). If so, the code in the loop itself probably changed edx.
Lines 3 on do not depend on the value of edx, so its value is not
meaningful.


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