EXCEPTION_GP_FAULT

NTDEV
1

I wonder if anyone has any pointers to where to go from here. My 1394 device
driver is out with a beta tester and I’ve just received a memory dump with
this fault.

The windbg help sort of suggests that the computer may have a problem, but
I’m wondering if I could have caused this. It appears to have trapped in
ExAllocatePool(NonPagedPool, nMaxBytesPerFrame);

The fault seems to be an attempt to load from ds:-1 which I guess would be
pretty likely to fault - but how did I make ExAllocatePool do that?

(This is derived from the DDK 1394 example and it is actually an
ExAllocatePoolWithTag())

Many thanks - here is what windbg is telling me…

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was taken
(on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

…etc…

kd> kv
ChildEBP RetAddr Args to Child
eda0eacc 804e20e3 badb0d00 88fc0000 804f01c0 nt!KiSystemFatalException+0xf
(FPO: [0,0] TrapFrame @ eda0eacc)
eda0eb44 8054a9e1 82c7e6f8 8054a944 82c7e764
nt!ExpInterlockedPopEntrySListFault (FPO: [0,2,0])
eda0eba0 f8a993f9 00000000 ffdff120 64393331 nt!ExAllocatePoolWithTag+0x3e1
(FPO: [Non-Fpo])
eda0ebec f8a9ad82 00c7e640 82c4a0a8 00000004
lm1394!IsochAllocateResources+0x107 (FPO: [Non-Fpo]) (CONV: stdcall)
[c:\development\lm1394\driver\lm1394\isochapi.c @ 490]
eda0ec34 804e37f7 82c7e640 82c4a0a8 806ed070 lm1394!IoControl+0x282 (FPO:
[Non-Fpo]) (CONV: stdcall) [c:\development\lm1394\driver\lm1394\ioctl.c @
468]
eda0ec44 8056a101 82c4a160 82b9f3e0 82c4a0a8 nt!IopfCallDriver+0x31 (FPO:
[0,0,0])
eda0ec58 80579a8a 82c7e640 82c4a0a8 82b9f3e0
nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
eda0ed00 8057bfa5 000000ac 00000000 00000000 nt!IopXxxControlFile+0x611
(FPO: [Non-Fpo])
eda0ed34 804de7ec 000000ac 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
(FPO: [Non-Fpo])
eda0ed34 7c90eb94 000000ac 00000000 00000000 nt!KiFastCallEntry+0xf8 (FPO:
[0,0] TrapFrame @ eda0ed64)
0012f40c 7c90d8ef 7c801671 000000ac 00000000 ntdll!KiFastSystemCallRet (FPO:
[0,0,0])
0012f410 7c801671 000000ac 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
(FPO: [10,0,0])
0012f470 00404fd7 000000ac 0022201c 0012f4b8 kernel32!DeviceIoControl+0xdd
(FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
00afb428 00000000 167e0081 01080146 0000001c TestFWPC+0x4fd7
kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e
edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

2

Looks like memory corruption, since this address (while bogus) shouldn’t
be generating a GP fault. Look at the descriptor (“dg 23”) and see what
it says the base and limit are.

Bottom line: there’s two odd things in the little chunk you’ve provided.
First, a general protection fault suggests there’s something wrong with
the address bound to the descriptor. Even if that weren’t true, the
address in question isn’t valid and suggests that perhaps someone has
trounced on the pool, but given a bogus ds selector it suggests there is
something more subtle going on, perhaps a stack corruption…

Amazing though, it’s the first time I think I’ve seen anyone come up
with an 0x7f that didn’t have ‘8’ as the fault (stack overflow) in a
VERY long time.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, June 23, 2006 7:51 AM
To: ntdev redirect
Subject: [ntdev] EXCEPTION_GP_FAULT

I wonder if anyone has any pointers to where to go from here. My 1394
device
driver is out with a beta tester and I’ve just received a memory dump
with
this fault.

The windbg help sort of suggests that the computer may have a problem,
but
I’m wondering if I could have caused this. It appears to have trapped in

ExAllocatePool(NonPagedPool, nMaxBytesPerFrame);

The fault seems to be an attempt to load from ds:-1 which I guess would
be
pretty likely to fault - but how did I make ExAllocatePool do that?

(This is derived from the DDK 1394 example and it is actually an
ExAllocatePoolWithTag())

Many thanks - here is what windbg is telling me…

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was
taken
(on x86, this will be the ebp that goes with the procedure
KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

…etc…

kd> kv
ChildEBP RetAddr Args to Child
eda0eacc 804e20e3 badb0d00 88fc0000 804f01c0
nt!KiSystemFatalException+0xf
(FPO: [0,0] TrapFrame @ eda0eacc)
eda0eb44 8054a9e1 82c7e6f8 8054a944 82c7e764
nt!ExpInterlockedPopEntrySListFault (FPO: [0,2,0])
eda0eba0 f8a993f9 00000000 ffdff120 64393331
nt!ExAllocatePoolWithTag+0x3e1
(FPO: [Non-Fpo])
eda0ebec f8a9ad82 00c7e640 82c4a0a8 00000004
lm1394!IsochAllocateResources+0x107 (FPO: [Non-Fpo]) (CONV: stdcall)
[c:\development\lm1394\driver\lm1394\isochapi.c @ 490]
eda0ec34 804e37f7 82c7e640 82c4a0a8 806ed070 lm1394!IoControl+0x282
(FPO:
[Non-Fpo]) (CONV: stdcall) [c:\development\lm1394\driver\lm1394\ioctl.c
@
468]
eda0ec44 8056a101 82c4a160 82b9f3e0 82c4a0a8 nt!IopfCallDriver+0x31
(FPO:
[0,0,0])
eda0ec58 80579a8a 82c7e640 82c4a0a8 82b9f3e0
nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
eda0ed00 8057bfa5 000000ac 00000000 00000000 nt!IopXxxControlFile+0x611
(FPO: [Non-Fpo])
eda0ed34 804de7ec 000000ac 00000000 00000000
nt!NtDeviceIoControlFile+0x2a
(FPO: [Non-Fpo])
eda0ed34 7c90eb94 000000ac 00000000 00000000 nt!KiFastCallEntry+0xf8
(FPO:
[0,0] TrapFrame @ eda0ed64)
0012f40c 7c90d8ef 7c801671 000000ac 00000000 ntdll!KiFastSystemCallRet
(FPO:
[0,0,0])
0012f410 7c801671 000000ac 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xc
(FPO: [10,0,0])
0012f470 00404fd7 000000ac 0022201c 0012f4b8
kernel32!DeviceIoControl+0xdd
(FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be

wrong.
00afb428 00000000 167e0081 01080146 0000001c TestFWPC+0x4fd7
kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e
edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

kd> dg 23
P Si Gr Pr Lo
Sel Base Limit Type l ze an es ng Flags

0023 00000000 ffffffff Data RW Ac 3 Bg Pg P Nl 00000cf3

I’m afraid I haven’t looked at the assembler since the 386 was new so I’m
pretty rusty on this, but I’m assuming that the
mov ebx,[eax]
instruction should move from memory address of ds:eax which looks like it is
permitted into the ebx register.

However if there is no actual memory at this location would it GP_FAULT?
This presumably means the descriptor is garbage. Since both ds and es are
0023 it seems fairly deliberate.

I presume an earlier random write into the pool could cause a later failure
to allocate?

----- Original Message -----
From: Tony Mason
To: Windows System Software Devs Interest List
Sent: Friday, June 23, 2006 1:42 PM
Subject: RE: [ntdev] EXCEPTION_GP_FAULT

Looks like memory corruption, since this address (while bogus) shouldn’t
be generating a GP fault. Look at the descriptor (“dg 23”) and see what
it says the base and limit are.

Bottom line: there’s two odd things in the little chunk you’ve provided.
First, a general protection fault suggests there’s something wrong with
the address bound to the descriptor. Even if that weren’t true, the
address in question isn’t valid and suggests that perhaps someone has
trounced on the pool, but given a bogus ds selector it suggests there is
something more subtle going on, perhaps a stack corruption…

Amazing though, it’s the first time I think I’ve seen anyone come up
with an 0x7f that didn’t have ‘8’ as the fault (stack overflow) in a
VERY long time.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, June 23, 2006 7:51 AM
To: ntdev redirect
Subject: [ntdev] EXCEPTION_GP_FAULT

I wonder if anyone has any pointers to where to go from here. My 1394
device
driver is out with a beta tester and I’ve just received a memory dump
with
this fault.

The windbg help sort of suggests that the computer may have a problem,
but
I’m wondering if I could have caused this. It appears to have trapped in

ExAllocatePool(NonPagedPool, nMaxBytesPerFrame);

The fault seems to be an attempt to load from ds:-1 which I guess would
be
pretty likely to fault - but how did I make ExAllocatePool do that?

(This is derived from the DDK 1394 example and it is actually an
ExAllocatePoolWithTag())

Many thanks - here is what windbg is telling me…

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was
taken
(on x86, this will be the ebp that goes with the procedure
KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

…etc…

kd> kv
ChildEBP RetAddr Args to Child
eda0eacc 804e20e3 badb0d00 88fc0000 804f01c0
nt!KiSystemFatalException+0xf
(FPO: [0,0] TrapFrame @ eda0eacc)
eda0eb44 8054a9e1 82c7e6f8 8054a944 82c7e764
nt!ExpInterlockedPopEntrySListFault (FPO: [0,2,0])
eda0eba0 f8a993f9 00000000 ffdff120 64393331
nt!ExAllocatePoolWithTag+0x3e1
(FPO: [Non-Fpo])
eda0ebec f8a9ad82 00c7e640 82c4a0a8 00000004
lm1394!IsochAllocateResources+0x107 (FPO: [Non-Fpo]) (CONV: stdcall)
[c:\development\lm1394\driver\lm1394\isochapi.c @ 490]
eda0ec34 804e37f7 82c7e640 82c4a0a8 806ed070 lm1394!IoControl+0x282
(FPO:
[Non-Fpo]) (CONV: stdcall) [c:\development\lm1394\driver\lm1394\ioctl.c
@
468]
eda0ec44 8056a101 82c4a160 82b9f3e0 82c4a0a8 nt!IopfCallDriver+0x31
(FPO:
[0,0,0])
eda0ec58 80579a8a 82c7e640 82c4a0a8 82b9f3e0
nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
eda0ed00 8057bfa5 000000ac 00000000 00000000 nt!IopXxxControlFile+0x611
(FPO: [Non-Fpo])
eda0ed34 804de7ec 000000ac 00000000 00000000
nt!NtDeviceIoControlFile+0x2a
(FPO: [Non-Fpo])
eda0ed34 7c90eb94 000000ac 00000000 00000000 nt!KiFastCallEntry+0xf8
(FPO:
[0,0] TrapFrame @ eda0ed64)
0012f40c 7c90d8ef 7c801671 000000ac 00000000 ntdll!KiFastSystemCallRet
(FPO:
[0,0,0])
0012f410 7c801671 000000ac 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xc
(FPO: [10,0,0])
0012f470 00404fd7 000000ac 0022201c 0012f4b8
kernel32!DeviceIoControl+0xdd
(FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be

wrong.
00afb428 00000000 167e0081 01080146 0000001c TestFWPC+0x4fd7
kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e
edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

It’s a GPF because it tries to read a DWORD from the last byte of the
segment.

  • Tom

Thomas Eckert
Sr. Software Engineer
AudioScience Inc.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mike Kemp
Sent: Friday, June 23, 2006 9:36 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] EXCEPTION_GP_FAULT

kd> dg 23
P Si Gr Pr Lo
Sel Base Limit Type l ze an es ng Flags

0023 00000000 ffffffff Data RW Ac 3 Bg Pg P Nl 00000cf3

I’m afraid I haven’t looked at the assembler since the 386 was new so I’m
pretty rusty on this, but I’m assuming that the
mov ebx,[eax]
instruction should move from memory address of ds:eax which looks
like it is
permitted into the ebx register.

However if there is no actual memory at this location would it GP_FAULT?
This presumably means the descriptor is garbage. Since both ds and es are
0023 it seems fairly deliberate.

I presume an earlier random write into the pool could cause a
later failure
to allocate?

----- Original Message -----
From: Tony Mason
To: Windows System Software Devs Interest List
Sent: Friday, June 23, 2006 1:42 PM
Subject: RE: [ntdev] EXCEPTION_GP_FAULT

Looks like memory corruption, since this address (while bogus) shouldn’t
be generating a GP fault. Look at the descriptor (“dg 23”) and see what
it says the base and limit are.

Bottom line: there’s two odd things in the little chunk you’ve provided.
First, a general protection fault suggests there’s something wrong with
the address bound to the descriptor. Even if that weren’t true, the
address in question isn’t valid and suggests that perhaps someone has
trounced on the pool, but given a bogus ds selector it suggests there is
something more subtle going on, perhaps a stack corruption…

Amazing though, it’s the first time I think I’ve seen anyone come up
with an 0x7f that didn’t have ‘8’ as the fault (stack overflow) in a
VERY long time.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mike Kemp
Sent: Friday, June 23, 2006 7:51 AM
To: ntdev redirect
Subject: [ntdev] EXCEPTION_GP_FAULT

I wonder if anyone has any pointers to where to go from here. My 1394
device
driver is out with a beta tester and I’ve just received a memory dump
with
this fault.

The windbg help sort of suggests that the computer may have a problem,
but
I’m wondering if I could have caused this. It appears to have trapped in

ExAllocatePool(NonPagedPool, nMaxBytesPerFrame);

The fault seems to be an attempt to load from ds:-1 which I guess would
be
pretty likely to fault - but how did I make ExAllocatePool do that?

(This is derived from the DDK 1394 example and it is actually an
ExAllocatePoolWithTag())

Many thanks - here is what windbg is telling me…

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it’s a trap of a kind
that the kernel isn’t allowed to have/catch (bound trap) or that
is always instant death (double fault). The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
use .trap on that value
Else
.trap on the appropriate frame will show where the trap was
taken
(on x86, this will be the ebp that goes with the procedure
KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000d, EXCEPTION_GP_FAULT
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

…etc…

kd> kv
ChildEBP RetAddr Args to Child
eda0eacc 804e20e3 badb0d00 88fc0000 804f01c0
nt!KiSystemFatalException+0xf
(FPO: [0,0] TrapFrame @ eda0eacc)
eda0eb44 8054a9e1 82c7e6f8 8054a944 82c7e764
nt!ExpInterlockedPopEntrySListFault (FPO: [0,2,0])
eda0eba0 f8a993f9 00000000 ffdff120 64393331
nt!ExAllocatePoolWithTag+0x3e1
(FPO: [Non-Fpo])
eda0ebec f8a9ad82 00c7e640 82c4a0a8 00000004
lm1394!IsochAllocateResources+0x107 (FPO: [Non-Fpo]) (CONV: stdcall)
[c:\development\lm1394\driver\lm1394\isochapi.c @ 490]
eda0ec34 804e37f7 82c7e640 82c4a0a8 806ed070 lm1394!IoControl+0x282
(FPO:
[Non-Fpo]) (CONV: stdcall) [c:\development\lm1394\driver\lm1394\ioctl.c
@
468]
eda0ec44 8056a101 82c4a160 82b9f3e0 82c4a0a8 nt!IopfCallDriver+0x31
(FPO:
[0,0,0])
eda0ec58 80579a8a 82c7e640 82c4a0a8 82b9f3e0
nt!IopSynchronousServiceTail+0x60 (FPO: [Non-Fpo])
eda0ed00 8057bfa5 000000ac 00000000 00000000 nt!IopXxxControlFile+0x611
(FPO: [Non-Fpo])
eda0ed34 804de7ec 000000ac 00000000 00000000
nt!NtDeviceIoControlFile+0x2a
(FPO: [Non-Fpo])
eda0ed34 7c90eb94 000000ac 00000000 00000000 nt!KiFastCallEntry+0xf8
(FPO:
[0,0] TrapFrame @ eda0ed64)
0012f40c 7c90d8ef 7c801671 000000ac 00000000 ntdll!KiFastSystemCallRet
(FPO:
[0,0,0])
0012f410 7c801671 000000ac 00000000 00000000
ntdll!ZwDeviceIoControlFile+0xc
(FPO: [10,0,0])
0012f470 00404fd7 000000ac 0022201c 0012f4b8
kernel32!DeviceIoControl+0xdd
(FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be

wrong.
00afb428 00000000 167e0081 01080146 0000001c TestFWPC+0x4fd7
kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e
edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na
po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

5

Tony Mason wrote:

Looks like memory corruption, since this address (while bogus) shouldn’t
be generating a GP fault. Look at the descriptor (“dg 23”) and see what
it says the base and limit are.

I’m not sure that an address is allowed to wrap around in protected
mode. The Intel specs imply that such a wrap will cause a GP fault (“an
attempt to fetch a DWORD from an address > LIMIT-3 is a GP fault”), but
it doesn’t specifically address the wraparound situation… It would
only take a couple of gates to include an overflow check, but that would
be uncharacteristically farsighted.

kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

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

6

Subtle point there. Of course, that still means he’s back to “someone
has corrupted memory” in either case, although a garden variety list
corruption is more likely the classic buffer overrun than something
whacking the descriptor table (which at least looked potentially
intriguing.)

So, run with driver verifier and see if you can find the culprit.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, June 23, 2006 12:41 PM
To: ntdev redirect
Subject: Re: [ntdev] EXCEPTION_GP_FAULT

Tony Mason wrote:

Looks like memory corruption, since this address (while bogus)
shouldn’t
be generating a GP fault. Look at the descriptor (“dg 23”) and see
what
it says the base and limit are.

I’m not sure that an address is allowed to wrap around in protected
mode. The Intel specs imply that such a wrap will cause a GP fault (“an
attempt to fetch a DWORD from an address > LIMIT-3 is a GP fault”), but
it doesn’t specifically address the wraparound situation… It would
only take a couple of gates to include an overflow check, but that would
be uncharacteristically farsighted.

kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e
edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

Hi Folks: With the help I’ve received here I see that the garbage access
which will overlap the top of the memory segment must be the reason for the
GP fault. I’ve been trying to get a handle on whether this could be result
of pool memory corruption by my driver that has not been caught by the
driver verifier. (i.e. a “random” write rather than a buffer overrun which
driver verifier can spot - I assume that’s done by the presence of safety
data at start and end of all allocated areas which the verifier can check,
but will miss just plain random writes?) .

I’m in the process of getting the offending laptop here and a second 1394
port on PCMCIA card installed (they don’t have serial ports these days) so I
can get it properly debugged.

From: Tony Mason
To: Windows System Software Devs Interest List
Sent: Friday, June 23, 2006 6:43 PM
Subject: RE: [ntdev] EXCEPTION_GP_FAULT

Subtle point there. Of course, that still means he’s back to “someone
has corrupted memory” in either case, although a garden variety list
corruption is more likely the classic buffer overrun than something
whacking the descriptor table (which at least looked potentially
intriguing.)

So, run with driver verifier and see if you can find the culprit.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, June 23, 2006 12:41 PM
To: ntdev redirect
Subject: Re: [ntdev] EXCEPTION_GP_FAULT

Tony Mason wrote:

Looks like memory corruption, since this address (while bogus)
shouldn’t
be generating a GP fault. Look at the descriptor (“dg 23”) and see
what
it says the base and limit are.

I’m not sure that an address is allowed to wrap around in protected
mode. The Intel specs imply that such a wrap will cause a GP fault (“an
attempt to fetch a DWORD from an address > LIMIT-3 is a GP fault”), but
it doesn’t specifically address the wraparound situation… It would
only take a couple of gates to include an overflow check, but that would
be uncharacteristically farsighted.

kd> .trap eda0eacc
ErrCode = 00000000
eax=ffffffff ebx=80561940 ecx=88fbffff edx=88fc0000 esi=0000001e
edi=82fc3d00
eip=804e20e3 esp=eda0eb40 ebp=82fc3d00 iopl=0 nv up ei ng nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010286
nt!ExpInterlockedPopEntrySListFault:
804e20e3 8b18 mov ebx,[eax]
ds:0023:ffffffff=???

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer