invalid frames in call stack

WINDBG
1

I know anyone on here beyond ‘new user with windbg’ will probably scoff at this message, but please bare with me : )

Im trying to find out who the source caller is into these methods. If Im reading it correctly, there’s no valid return address for the first frame listed, not to mention it can’t seem to find who 0x7c90eb94 belongs to. Is there a way to determine who the caller was at this point?
A tried a u 0x7c90eb94 but I get a “Memory access error in ‘u 0x7c90eb94’”. Any thoughts?

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx” referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
+69686374
69686374 ?? ???

TRAP_FRAME: f5897c68 – (.trap fffffffff5897c68)
ErrCode = 00000000
eax=85984680 ebx=86406860 ecx=deadbeef edx=85c86ff0 esi=85c86fd8 edi=e50961b0
eip=69686374 esp=f5897cdc ebp=f5897cfc iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
69686374 ?? ???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 805897e2 to 69686374

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
f5897cd8 805897e2 86406860 85c86ff0 000010d8 0x69686374
f5897cfc 8056e9bc e1a2b810 85c86ff0 000010d8 nt!ObpCloseHandleTableEntry+0x3b
f5897d44 8056ea06 000010d8 00000001 00000000 nt!ObpCloseHandle+0x87
f5897d58 804dd99f 000010d8 01ccfc38 7c90eb94 nt!NtClose+0x1d
f5897d58 7c90eb94 000010d8 01ccfc38 7c90eb94 nt!KiFastCallEntry+0xfc
01ccfc28 00000000 00000000 00000000 00000000 0x7c90eb94

Powered by http://www.DWmail.net a free service
Check your email [any email, anytime, anywhere]

2

My first guess is that someone has scribbled on the stack. The address
there (69686374) looks like ASCII to me, which makes me wonder if
there’s some place further down in the call stack that someone copied a
string and overwrote a return address; the return instruction then
loaded that address into the EIP register and BAM - there you have it.

I’d generally start looking at the stack directly to see if I could get
a hint as to what happened here; you might also wish to convert the
handle (10d8) into an object to see what was being closed (I’ll hazard a
guess: a file handle). If so, the bug is likely in a file system filter
driver somewhere on that stack, in their handling of the IRP_MJ_CLEANUP
or IRP_MJ_CLOSE case. In fact, want to bet they hard coded something
like MAX_PATH into their driver? Of course MAX_PATH isn’t really
MAX_PATH for the OS (it is for MS-DOS) and continues to cause periodic
buffer overflow issues eerily similar to the one you have right there.

Now, how’s that for a stretch?

Regards,

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 Adam Tuliper
Sent: Friday, June 10, 2005 2:28 PM
To: Kernel Debugging Interest List
Subject: [windbg] invalid frames in call stack

I know anyone on here beyond ‘new user with windbg’ will probably scoff
at this message, but please bare with me : )

Im trying to find out who the source caller is into these methods. If Im
reading it correctly, there’s no valid return address for the first
frame listed, not to mention it can’t seem to find who 0x7c90eb94
belongs to. Is there a way to determine who the caller was at this
point?
A tried a u 0x7c90eb94 but I get a “Memory access error in ‘u
0x7c90eb94’”. Any thoughts?

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at “0x%08lx”
referenced memory at “0x%08lx”. The memory could not be “%s”.

FAULTING_IP:
+69686374
69686374 ?? ???

TRAP_FRAME: f5897c68 – (.trap fffffffff5897c68)
ErrCode = 00000000
eax=85984680 ebx=86406860 ecx=deadbeef edx=85c86ff0 esi=85c86fd8
edi=e50961b0
eip=69686374 esp=f5897cdc ebp=f5897cfc iopl=0 nv up ei pl nz na
po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010206
69686374 ?? ???
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 805897e2 to 69686374

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be
wrong.
f5897cd8 805897e2 86406860 85c86ff0 000010d8 0x69686374
f5897cfc 8056e9bc e1a2b810 85c86ff0 000010d8
nt!ObpCloseHandleTableEntry+0x3b
f5897d44 8056ea06 000010d8 00000001 00000000 nt!ObpCloseHandle+0x87
f5897d58 804dd99f 000010d8 01ccfc38 7c90eb94 nt!NtClose+0x1d
f5897d58 7c90eb94 000010d8 01ccfc38 7c90eb94 nt!KiFastCallEntry+0xfc
01ccfc28 00000000 00000000 00000000 00000000 0x7c90eb94

Powered by http://www.DWmail.net a free service
Check your email [any email, anytime, anywhere]

You are currently subscribed to windbg as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

Adam Tuliper wrote:

I know anyone on here beyond ‘new user with windbg’ will probably scoff at this message, but please bare with me : )

Im trying to find out who the source caller is into these methods. If Im reading it correctly, there’s no valid return address for the first frame listed, not to mention it can’t seem to find who 0x7c90eb94 belongs to. Is there a way to determine who the caller was at this point?
A tried a u 0x7c90eb94 but I get a “Memory access error in ‘u 0x7c90eb94’”. Any thoughts?

That’s in user mode, in ntdll.dll, at KiFastSystemCallRet. All you know
is that you are handling a “Close” request from user mode.

FAULTING_IP:
+69686374
69686374 ?? ???

Tony is absolutely correct: that’s ASCII. It’s “tchi”, which might be
part of a debug string, like “No matching something”.

TRAP_FRAME: f5897c68 – (.trap fffffffff5897c68)
ErrCode = 00000000
eax=85984680 ebx=86406860 ecx=deadbeef edx=85c86ff0 esi=85c86fd8 edi=e50961b0
eip=69686374 esp=f5897cdc ebp=f5897cfc iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
69686374 ?? ???
Resetting default scope

Note also the value in ecx, “deadbeef”. I don’t think any compiler or
operating system utilities set that, although I often use it as a marker
for uninitialized storage.

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

LAST_CONTROL_TRANSFER: from 805897e2 to 69686374

STACK_TEXT:
WARNING: Frame IP not in any known module. Following frames may be wrong.
f5897cd8 805897e2 86406860 85c86ff0 000010d8 0x69686374
f5897cfc 8056e9bc e1a2b810 85c86ff0 000010d8 nt!ObpCloseHandleTableEntry+0x3b
f5897d44 8056ea06 000010d8 00000001 00000000 nt!ObpCloseHandle+0x87
f5897d58 804dd99f 000010d8 01ccfc38 7c90eb94 nt!NtClose+0x1d
f5897d58 7c90eb94 000010d8 01ccfc38 7c90eb94 nt!KiFastCallEntry+0xfc
01ccfc28 00000000 00000000 00000000 00000000 0x7c90eb94

Did you catch this live, or is it a dump analysis? If it’s live, you
should be able to continue looking at 01CCFC28.

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

4

Thanks for the responses Tony and Tim.

How do you determine the handle type (or convert to an object for that matter) , what I see is:

1: kd> !handle 10d8 13
processor number 1, process 86406860
PROCESS 86406860 SessionId: 0 Cid: 0a4c Peb: 7ffde000 ParentCid: 0a10
DirBase: 25646000 ObjectTable: e1a2b810 HandleCount: 1077.
Image: explorer.exe

Just dumping everything out (!handle 1 f) gives me this segment:
The system is setup for a kernel dump, so I’ll have to grab a complete dump. (10d8 being the important one)

10d4: Object: e4a81ec8 GrantedAccess: 0002001f
Object: e4a81ec8 Type: (867ba180) Key
ObjectHeader: e4a81eb0
HandleCount: 1 PointerCount: 1
Directory Object: 00000000 Name: \REGISTRY\USER\S-1-5-21-2613124935-1853311096-1006542572-1006\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\EXPLORER\MENUORDER\START MENU2\PROGRAMS

10d8: Object: 85c86ff0 GrantedAccess: 001f0003 (Locked)
Page eade not present in the dump file. Type “.hh dbgerr004” for details

Object: 85c86ff0 Type: (deadbeef)
ObjectHeader: 85c86fd8
HandleCount: 2244505552 PointerCount: 2244503552

10dc: Object: 85964e58 GrantedAccess: 001f0003
Object: 85964e58 Type: (867c1490) Event
ObjectHeader: 85964e40
HandleCount: 1 PointerCount: 1

searching out of curiosity to see if I can find a filename, etc.
s -a 0x0000000 L?99999999 “tchi”
is showing nothing except
Page xxxx not present in the dump file. Type “.hh dbgerr004” for details
Since I only had a kernel dump, Im going to try to get a complete dump next.
In that area of memory Ive found a couple entries, some 5 bytes (tchih), hoping to see something more obvious there. I’ll keep searching.

./K.p.v…y…w…
.~8…s.@…
0x…qS…
tchih|…
.{…- R…
tchih|…tchi
tchi(|…8y…x…
…N…v…w…\y…

-----Original Message-----
From: Tim Roberts
Sent: Fri, 10 June 2005 19:36:46
To: Kernel Debugging Interest List
Subject: Re: [windbg] invalid frames in call stack

Adam Tuliper wrote:

>I know anyone on here beyond ‘new user with windbg’ will probably scoff at this message, but please bare with me : )
>
>Im trying to find out who the source caller is into these methods. If Im reading it correctly, there’s no valid return address for the first frame listed, not to mention it can’t seem to find who 0x7c90eb94 belongs to. Is there a way to determine who the caller was at this point?
>A tried a u 0x7c90eb94 but I get a “Memory access error in ‘u 0x7c90eb94’”. Any thoughts?
>
>

That’s in user mode, in ntdll.dll, at KiFastSystemCallRet. All you know
is that you are handling a “Close” request from user mode.

>FAULTING_IP:
>+69686374
>69686374 ?? ???
>
>

Tony is absolutely correct: that’s ASCII. It’s “tchi”, which might be
part of a debug string, like “No matching something”.

>TRAP_FRAME: f5897c68 – (.trap fffffffff5897c68)
>ErrCode = 00000000
>eax=85984680 ebx=86406860 ecx=deadbeef edx=85c86ff0 esi=85c86fd8 edi=e50961b0
>eip=69686374 esp=f5897cdc ebp=f5897cfc iopl=0 nv up ei pl nz na po nc
>cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
>69686374 ?? ???
>Resetting default scope
>
>

Note also the value in ecx, “deadbeef”. I don’t think any compiler or
operating system utilities set that, although I often use it as a marker
for uninitialized storage.

>DEFAULT_BUCKET_ID: DRIVER_FAULT
>
>BUGCHECK_STR: 0x8E
>
>LAST_CONTROL_TRANSFER: from 805897e2 to 69686374
>
>STACK_TEXT:
>WARNING: Frame IP not in any known module. Following frames may be wrong.
>f5897cd8 805897e2 86406860 85c86ff0 000010d8 0x69686374
>f5897cfc 8056e9bc e1a2b810 85c86ff0 000010d8 nt!ObpCloseHandleTableEntry+0x3b
>f5897d44 8056ea06 000010d8 00000001 00000000 nt!ObpCloseHandle+0x87
>f5897d58 804dd99f 000010d8 01ccfc38 7c90eb94 nt!NtClose+0x1d
>f5897d58 7c90eb94 000010d8 01ccfc38 7c90eb94 nt!KiFastCallEntry+0xfc
>01ccfc28 00000000 00000000 00000000 00000000 0x7c90eb94
>
>

Did you catch this live, or is it a dump analysis? If it’s live, you
should be able to continue looking at 01CCFC28.

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

—
You are currently subscribed to windbg as: xxxxx@nni.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

-------------------------------------------------
Powered by http://www.DWmail.net a free service
Check your email [any email, anytime, anywhere]
-------------------------------------------------

5

Adam Tuliper wrote:

Thanks for the responses Tony and Tim.

How do you determine the handle type (or convert to an object for that matter) , what I see is:

1: kd> !handle 10d8 13
processor number 1, process 86406860
PROCESS 86406860 SessionId: 0 Cid: 0a4c Peb: 7ffde000 ParentCid: 0a10
DirBase: 25646000 ObjectTable: e1a2b810 HandleCount: 1077.
Image: explorer.exe

Well, this is a “process” handle, although I don’t know why someone
would be closing a handle to the Explorer process. What were you doing
when this crash occurred?

searching out of curiosity to see if I can find a filename, etc.
s -a 0x0000000 L?99999999 “tchi”

There are interesting kernel memory pools at C0000000 and E0000000, so
stopping at 99999999 isn’t really enough. However, if this is just a
dump file, you probably don’t have enough interesting stuff anyway.

is showing nothing except
Page xxxx not present in the dump file. Type “.hh dbgerr004” for details
Since I only had a kernel dump, Im going to try to get a complete dump next.
In that area of memory Ive found a couple entries, some 5 bytes (tchih), hoping to see something more obvious there. I’ll keep searching.

./K.p.v…y…w…
.~8…s.@…
0x…qS…
tchih|…
.{…- R…
tchih|…tchi
tchi(|…8y…x…
…N…v…w…\y…

This is probably the stack dump from the exception, not from the
origination. The “h” in “tchih” is from the next DWORD and is not related.

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

6

This started happening during a restoration after hibernation. The hibernation is fine, coming out it blue screens. Now it happens sometimes on boot but only after I have hibernated and try to come up. If I boot into safemode and then reboot, all is ok… so just trying to narrow down the source.
It may (or may not) be related to beta 2 of whidbey, but started a day or two after I installed it. Usually I have it attached to inetinfo for some isapi debugging, but I’ve tried shutting it all down and still have the same issue. Unless theres a newer mdm.exe from whidbey that runs that keeps a handle to explorer… the only thing I can think of as to why a handle to explorer would be open. I’ll try killing that before I hibernate each time.

-----Original Message-----
From: Tim Roberts
Sent: Fri, 10 June 2005 20:50:23
To: Kernel Debugging Interest List
Subject: Re: [windbg] invalid frames in call stack

Adam Tuliper wrote:

>Thanks for the responses Tony and Tim.
>
>How do you determine the handle type (or convert to an object for that matter) , what I see is:
>------------------
>1: kd> !handle 10d8 13
>processor number 1, process 86406860
>PROCESS 86406860 SessionId: 0 Cid: 0a4c Peb: 7ffde000 ParentCid: 0a10
> DirBase: 25646000 ObjectTable: e1a2b810 HandleCount: 1077.
> Image: explorer.exe
>
>

Well, this is a “process” handle, although I don’t know why someone
would be closing a handle to the Explorer process. What were you doing
when this crash occurred?

>searching out of curiosity to see if I can find a filename, etc.
>s -a 0x0000000 L?99999999 “tchi”
>
>

There are interesting kernel memory pools at C0000000 and E0000000, so
stopping at 99999999 isn’t really enough. However, if this is just a
dump file, you probably don’t have enough interesting stuff anyway.

>is showing nothing except
>Page xxxx not present in the dump file. Type “.hh dbgerr004” for details
>Since I only had a kernel dump, Im going to try to get a complete dump next.
>In that area of memory Ive found a couple entries, some 5 bytes (tchih), hoping to see something more obvious there. I’ll keep searching.
>
>./K.p.v…y…w…
>.~8…s.@…
>0x…qS…
>tchih|…
>.{…- R…
>tchih|…tchi
>tchi(|…8y…x…
>…N…v…w…y…
>
>

This is probably the stack dump from the exception, not from the
origination. The “h” in “tchih” is from the next DWORD and is not related.

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

—
You are currently subscribed to windbg as: xxxxx@nni.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

-------------------------------------------------
Powered by http://www.DWmail.net a free service
Check your email [any email, anytime, anywhere]
-------------------------------------------------