0x7f stack corruprtion

WINDBG
1

Hi, guys
I am analyzing a dump which has arrived from another satisfied customer.
!analyze -v
UNEXPECTED_KERNEL_MODE_TRAP (7f)

Arguments:
Arg1: 00000000, EXCEPTION_DIVIDED_BY_ZERO
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

OVERLAPPED_MODULE: Address regions for ‘kmixer’ and ‘kmixer.sys’ overlap

BUGCHECK_STR: 0x7f_0

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: csrss.exe

TRAP_FRAME: a7f64bc0 – (.trap 0xffffffffa7f64bc0)
ErrCode = 00000000
eax=881f52d8 ebx=e3f5aa9c ecx=00000000 edx=00010002 esi=e3f5aaa0 edi=00000000
eip=00011f79 esp=a7f64c34 ebp=a7f64c6c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000246
00011f79 0000 add byte ptr [eax],al ds:0023:881f52d8=c8
Resetting default scope

LAST_CONTROL_TRANSFER: from 805a26fd to 804f9f1e

STACK_TEXT:
a7f64b5c 805a26fd 0000007f 00011f79 e3f5aaa0 nt!KeBugCheck+0x14
a7f64bb4 80542284 a7f64bc0 a7f64c6c 00011f79 nt!Ki386CheckDivideByZeroTrap+0x41
a7f64bb4 00011f79 a7f64bc0 a7f64c6c 00011f79 nt!KiTrap00+0x84
WARNING: Frame IP not in any known module. Following frames may be wrong.
a7f64c30 805bb48e e3f5aab8 00000002 00000000 0x11f79
a7f64c6c 805266fa e3f5aab8 00000000 00000000 nt!ObpRemoveObjectRoutine+0xc4
a7f64c84 bf80343a bbf5d780 a7f64c9c bf8029a0 nt!ObfDereferenceObject+0x4c
a7f64c90 bf8029a0 e314e4d8 a7f64cf8 bf838c2c win32k!DereferenceW32Thread+0x25
a7f64c9c bf838c2c a7f64cb4 bbf5d780 e3750008 win32k!PopAndFreeW32ThreadLock+0x25
a7f64cf8 bf8391f4 bbf5d780 e3750008 00000000 win32k!xxxSetForegroundWindow2+0x3d4
a7f64d28 bf85845f bbf5d780 00000001 a7f64d54 win32k!xxxSetForegroundWindow+0x164
a7f64d38 bf824614 bbf5d780 0136fce4 00000000 win32k!xxxStubSetForegroundWindow+0xf
a7f64d54 8054167c 002a16ba 0000005b 0136fce4 win32k!NtUserCallHwndLock+0x4b
a7f64d54 7c90e514 002a16ba 0000005b 0136fce4 nt!KiFastCallEntry+0xfc
0136fce4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet

This is Win7x32

The strange return address here is of course 0x11f79. The customer says the system was “hung” and he just pushed the power button. He also says that when he turned on the machine again the dump was being written. From other stacks I clearly see the dump describes the memory snapshot during system shutdown (Winlogon calls ExitWindowsEx() from other thread and message is sent to CSRSS.exe). I have two questions:

  1. Is it possible that somehow the dump written after reboot represents a snapshot of the memory before reboot?
  2. Is this just a plain stack corruption caused by pushing a power button?

Thanks!

2

Could you reload symbols and post the output of ‘lml?’

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Tuesday, April 12, 2011 1:09 PM
To: Kernel Debugging Interest List
Subject: [windbg] 0x7f stack corruprtion

Hi, guys
I am analyzing a dump which has arrived from another satisfied customer.
!analyze -v
UNEXPECTED_KERNEL_MODE_TRAP (7f)

Arguments:
Arg1: 00000000, EXCEPTION_DIVIDED_BY_ZERO
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

OVERLAPPED_MODULE: Address regions for ‘kmixer’ and ‘kmixer.sys’ overlap

BUGCHECK_STR: 0x7f_0

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: csrss.exe

TRAP_FRAME: a7f64bc0 – (.trap 0xffffffffa7f64bc0)
ErrCode = 00000000
eax=881f52d8 ebx=e3f5aa9c ecx=00000000 edx=00010002 esi=e3f5aaa0
edi=00000000
eip=00011f79 esp=a7f64c34 ebp=a7f64c6c iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000246
00011f79 0000 add byte ptr [eax],al
ds:0023:881f52d8=c8
Resetting default scope

LAST_CONTROL_TRANSFER: from 805a26fd to 804f9f1e

STACK_TEXT:
a7f64b5c 805a26fd 0000007f 00011f79 e3f5aaa0 nt!KeBugCheck+0x14
a7f64bb4 80542284 a7f64bc0 a7f64c6c 00011f79
nt!Ki386CheckDivideByZeroTrap+0x41
a7f64bb4 00011f79 a7f64bc0 a7f64c6c 00011f79 nt!KiTrap00+0x84
WARNING: Frame IP not in any known module. Following frames may be wrong.
a7f64c30 805bb48e e3f5aab8 00000002 00000000 0x11f79
a7f64c6c 805266fa e3f5aab8 00000000 00000000 nt!ObpRemoveObjectRoutine+0xc4
a7f64c84 bf80343a bbf5d780 a7f64c9c bf8029a0 nt!ObfDereferenceObject+0x4c
a7f64c90 bf8029a0 e314e4d8 a7f64cf8 bf838c2c
win32k!DereferenceW32Thread+0x25
a7f64c9c bf838c2c a7f64cb4 bbf5d780 e3750008
win32k!PopAndFreeW32ThreadLock+0x25
a7f64cf8 bf8391f4 bbf5d780 e3750008 00000000
win32k!xxxSetForegroundWindow2+0x3d4
a7f64d28 bf85845f bbf5d780 00000001 a7f64d54
win32k!xxxSetForegroundWindow+0x164
a7f64d38 bf824614 bbf5d780 0136fce4 00000000
win32k!xxxStubSetForegroundWindow+0xf
a7f64d54 8054167c 002a16ba 0000005b 0136fce4 win32k!NtUserCallHwndLock+0x4b
a7f64d54 7c90e514 002a16ba 0000005b 0136fce4 nt!KiFastCallEntry+0xfc
0136fce4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet

This is Win7x32

The strange return address here is of course 0x11f79. The customer says the
system was “hung” and he just pushed the power button. He also says that
when he turned on the machine again the dump was being written. From other
stacks I clearly see the dump describes the memory snapshot during system
shutdown (Winlogon calls ExitWindowsEx() from other thread and message is
sent to CSRSS.exe). I have two questions:

  1. Is it possible that somehow the dump written after reboot represents a
    snapshot of the memory before reboot?
  2. Is this just a plain stack corruption caused by pushing a power button?

Thanks!

WINDBG 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

3

>The strange return address here is of course 0x11f79.

ObpRemoveObjectRoutine makes calls through function pointers extracted from
the object being torn down. So, it looks like the object here (a thread?) is
corrupted, which would point to some kind of memory corruption. Does your
driver work with Verifier enabled?

-scott

–
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@windbg…

Hi, guys
I am analyzing a dump which has arrived from another satisfied customer.
!analyze -v
UNEXPECTED_KERNEL_MODE_TRAP (7f)

Arguments:
Arg1: 00000000, EXCEPTION_DIVIDED_BY_ZERO
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

OVERLAPPED_MODULE: Address regions for ‘kmixer’ and ‘kmixer.sys’ overlap

BUGCHECK_STR: 0x7f_0

DEFAULT_BUCKET_ID: DRIVER_FAULT

PROCESS_NAME: csrss.exe

TRAP_FRAME: a7f64bc0 – (.trap 0xffffffffa7f64bc0)
ErrCode = 00000000
eax=881f52d8 ebx=e3f5aa9c ecx=00000000 edx=00010002 esi=e3f5aaa0
edi=00000000
eip=00011f79 esp=a7f64c34 ebp=a7f64c6c iopl=0 nv up ei pl zr na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000246
00011f79 0000 add byte ptr [eax],al
ds:0023:881f52d8=c8
Resetting default scope

LAST_CONTROL_TRANSFER: from 805a26fd to 804f9f1e

STACK_TEXT:
a7f64b5c 805a26fd 0000007f 00011f79 e3f5aaa0 nt!KeBugCheck+0x14
a7f64bb4 80542284 a7f64bc0 a7f64c6c 00011f79
nt!Ki386CheckDivideByZeroTrap+0x41
a7f64bb4 00011f79 a7f64bc0 a7f64c6c 00011f79 nt!KiTrap00+0x84
WARNING: Frame IP not in any known module. Following frames may be wrong.
a7f64c30 805bb48e e3f5aab8 00000002 00000000 0x11f79
a7f64c6c 805266fa e3f5aab8 00000000 00000000 nt!ObpRemoveObjectRoutine+0xc4
a7f64c84 bf80343a bbf5d780 a7f64c9c bf8029a0 nt!ObfDereferenceObject+0x4c
a7f64c90 bf8029a0 e314e4d8 a7f64cf8 bf838c2c
win32k!DereferenceW32Thread+0x25
a7f64c9c bf838c2c a7f64cb4 bbf5d780 e3750008
win32k!PopAndFreeW32ThreadLock+0x25
a7f64cf8 bf8391f4 bbf5d780 e3750008 00000000
win32k!xxxSetForegroundWindow2+0x3d4
a7f64d28 bf85845f bbf5d780 00000001 a7f64d54
win32k!xxxSetForegroundWindow+0x164
a7f64d38 bf824614 bbf5d780 0136fce4 00000000
win32k!xxxStubSetForegroundWindow+0xf
a7f64d54 8054167c 002a16ba 0000005b 0136fce4 win32k!NtUserCallHwndLock+0x4b
a7f64d54 7c90e514 002a16ba 0000005b 0136fce4 nt!KiFastCallEntry+0xfc
0136fce4 00000000 00000000 00000000 00000000 ntdll!KiFastSystemCallRet

This is Win7x32

The strange return address here is of course 0x11f79. The customer says the
system was “hung” and he just pushed the power button. He also says that
when he turned on the machine again the dump was being written. From other
stacks I clearly see the dump describes the memory snapshot during system
shutdown (Winlogon calls ExitWindowsEx() from other thread and message is
sent to CSRSS.exe). I have two questions:

  1. Is it possible that somehow the dump written after reboot represents a
    snapshot of the memory before reboot?
  2. Is this just a plain stack corruption caused by pushing a power button?

Thanks!

4

Thanks!

Could you reload symbols and post the output of ‘lml?’

1: kd> .reload
Loading Kernel Symbols
…
…
…
Loading User Symbols
…
…
…
Loading unloaded module list
…
1: kd> lml
start end module name
7c900000 7c9b2000 ntdll (pdb symbols) c:\symbols\ntdll.pdb\CEFC0863B1F84130A11E0F54180CD21A2\ntdll.pdb
804d7000 806e5000 nt (pdb symbols) c:\symbols\ntkrpamp.pdb\ADBB8940685E4448A748028B784C8F3A1\ntkrpamp.pdb
bf800000 bf9c4e00 win32k (pdb symbols) c:\symbols\win32k.pdb\FA73BD4EB15C4AA793F12403BBB5C32C2\win32k.pdb

Does your driver work with Verifier enabled?
We are trying to make it work with driver verifier lately and the driver is rather stable with a verifier enabled. But this machine was not running a driver verifer…

5

Can you dig out the first parameter passed to ObpRemoveObjectRoutine? When
you do, try running !object and !pool

1 on the result. Maybe we
can see what the corruption looks like.

-scott

--
Scott Noone
Consulting Associate and Chief System Problem Analyst
OSR Open Systems Resources, Inc.
http://www.osronline.com
6

I’ve done some disassembly work on ObpRemoveObjectRoutine and looks like the correct parameter is shown on the stack (no manipulations with [ebp + 8]):

1: kd> dds a7f64c30 l15
a7f64c30 00000246
a7f64c34 805bb48e nt!ObpRemoveObjectRoutine+0xc4
a7f64c38 e3f5aab8
a7f64c3c 00000002
a7f64c40 00000000
a7f64c44 00000000
a7f64c48 00000000
a7f64c4c e3f5aab4
a7f64c50 00000000
a7f64c54 00000000
a7f64c58 00000000
a7f64c5c 00000000
a7f64c60 e3f5aaa0
a7f64c64 e3f5aab8
a7f64c68 881f52d8
a7f64c6c a7f64c90
a7f64c70 805266fa nt!ObfDereferenceObject+0x4c
a7f64c74 e3f5aab8
a7f64c78 00000000
a7f64c7c 00000000
a7f64c80 e3f5aab8

1: kd> !object e3f5aab8
Type information missing error for FltGlobals
e3f5aab8: Not a valid object (ObjectType.Name at 0x63000000 invalid)

!pool e3f5aab8 1
*e3f5aab0 size: 160 previous size: 30 (Free) *SeSc
Pooltag SeSc : Captured Security Descriptor, Binary : nt!se
e3f5aab8 e8d9de28 e314e4d8 e314e4e0 00000000
e3f5aac8 00000000 00000000 00000150 00000000
e3f5aad8 00000000 e3f5ab88 000000c8 00000005
e3f5aae8 00000000 0000001a 00000500 0000003a
e3f5aaf8 00000000 80000000 0000001a 00000000
e3f5ab08 00000004 0000001a 0000001f 00000000
e3f5ab18 00000002 0000004e 00000500 00000004
e3f5ab28 00000008 0000001f 00000035 00000000
e3f5ab38 00000002 0000004e 00000054 000003ce
e3f5ab48 000003d4 000004d3 000004d7 00000008
e3f5ab58 00000004 00000035 0000003a 00000000
e3f5ab68 00000002 0000004e 00000500 00000004
e3f5ab78 00000000 0000003a 7fffffff 00000000
e3f5ab88 00000208 00000000 00bdd316 00000000
e3f5ab98 00000000 00000000 00000000 00000501
e3f5aba8 00000000 00000000 00000000 bf8076ae
e3f5abb8 bf8076ae 00000000 00000000 e3f5abcc
e3f5abc8 e3f5ab78 00ff0000 0000ff00 000000ff
e3f5abd8 00000000 00000008 00000010 00000010
e3f5abe8 00000008 00000000 00000008 00000008
e3f5abf8 00000008 a0020000 00000201 05000000
e3f5ac08 00000020 00000220

7

“Well there’s your problem”

!pool e3f5aab8 1
*e3f5aab0 size: 160 previous size: 30 (Free) *SeSc
Pooltag SeSc : Captured Security Descriptor, Binary : nt!se

The O/S is trying to dereference an object but instead it’s a block of freed
memory, so you’ve appeared to have corrupted something. Because it seems
like it’s a thread here, a bogus dereference on a thread object seems like a
decent enough guess. Do you do anything strange with threads in your driver?
Like directly call ObDereferenceObject on them for some reason? Or call
PsGetCurrentThread and put the thread address in a structure that gets
passed around (like an IRP, maybe?).

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

8

Scott, as usual, thanks a lot :slight_smile: