Strange Traps?

OSR_Community_User · November 8, 2003, 2:09pm

Hello Everyone,

I am new to the list (I am not sure if NTDEV is right, but I also sent to
WINDBG list), but I have been seeing some strange traps that I cannot seem
to figure out what's going on and would like some ideas. Basically, I
have 2 traps on quad processor machines that are valid instructions,
however, they caused a bluescreen.

The trap occurs in the context of Winlogon. One of Winlogon's threads is
basically just making a GetMessage() call. The OS is Windows 2003.

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
that an unaligned data reference was encountered. The trap frame will
supply additional information.
Arguments:
Arg1: c000001d, The exception code that was not handled
Arg2: bf8e59bc, The address that the exception occurred at
Arg3: ec251be0, Trap Frame
Arg4: 00000000

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal
Instruction An attempt was made to execute an illegal instruction.

FAULTING_IP:
win32k+e59bc
bf8e59bc 8945e0 mov [ebp-0x20],eax

TRAP_FRAME: ec251be0 -- (.trap ffffffffec251be0)
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8 edi=00000000
eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010287
win32k+0xe59bc:
bf8e59bc 8945e0 mov [ebp-0x20],eax ss:0010:ec251c74=00000000
Resetting default scope

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x8E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from bf8e5db1 to bf8e59bc

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
0092fef8 77d06718 77d067e0 0092ff64 00000000 SharedUserData!SystemCallStub+0x4
0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc

FAILED_INSTRUCTION_ADDRESS:
win32k+e59bc
bf8e59bc 8945e0 mov [ebp-0x20],eax

FOLLOWUP_IP:
win32k+e59bc
bf8e59bc 8945e0 mov [ebp-0x20],eax

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: win32k+e59bc

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 3e801611

STACK_COMMAND: .trap ffffffffec251be0 ; kb

BUCKET_ID: 0x8E_BAD_IP_win32k+e59bc

Followup: MachineOwner

1: kd> .trap ffffffffec251be0
ErrCode = 00000000
eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8 edi=00000000
eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010287
win32k+0xe59bc:
bf8e59bc 8945e0 mov [ebp-0x20],eax ss:0010:ec251c74=00000000
1: kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
0092fef8 77d06718 77d067e0 0092ff64 00000000 SharedUserData!SystemCallStub+0x4
0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc

1: kd> u bf8e5db1
win32k+0xe5db1:
bf8e5db1 85c0 test eax,eax
bf8e5db3 0f84ee030000 je win32k+0xe61a7 (bf8e61a7)
bf8e5db9 e9f1010000 jmp win32k+0xe5faf (bf8e5faf)
bf8e5dbe e873ecffff call win32k+0xe4a36 (bf8e4a36)
bf8e5dc3 e9f5020000 jmp win32k+0xe60bd (bf8e60bd)
bf8e5dc8 83600400 and dword ptr [eax+0x4],0x0
bf8e5dcc 8b464c mov eax,[esi+0x4c]
bf8e5dcf 85c2 test edx,eax

1: kd> u win32k+e59bc
win32k+0xe59bc:
bf8e59bc 8945e0 mov [ebp-0x20],eax
bf8e59bf e894eeffff call win32k+0xe4858 (bf8e4858)
bf8e59c4 56 push esi
bf8e59c5 e844000000 call win32k+0xe5a0e (bf8e5a0e)
bf8e59ca e9b2feffff jmp win32k+0xe5881 (bf8e5881)
bf8e59cf 8b4640 mov eax,[esi+0x40]
bf8e59d2 8b400c mov eax,[eax+0xc]
bf8e59d5 0b869c000000 or eax,[esi+0x9c]

1: kd> dds ec251c94 -40
ec251c54 00000000
ec251c58 bc1717c8
ec251c5c 00000000
ec251c60 00000100
ec251c64 855dd020
ec251c68 804f0000 nt!KiRetireDpcList+0x10
ec251c6c bc1717c8
ec251c70 00000000
ec251c74 00000000
ec251c78 00000000
ec251c7c ec251c54
ec251c80 ec2516e8
ec251c84 ec251cdc
ec251c88 bf980f8a win32k+0x180f8a
ec251c8c bf994f60 win32k+0x194f60
ec251c90 ffffffff
ec251c94 ec251cec
ec251c98 bf8e5db1 win32k+0xe5db1
ec251c9c 000025ff
ec251ca0 00000000
ec251ca4 00000001
ec251ca8 ec251d64
ec251cac 0092ff14
ec251cb0 bf8e66fa win32k+0xe66fa
ec251cb4 00000000

Seems valid memory is being accessed.

CP F/M/S Manufacturer MHz
0 15,2,7 GenuineIntel 2392
1 15,2,7 GenuineIntel 2392
2 15,2,7 GenuineIntel 2392
3 15,2,7 GenuineIntel 2392
1: kd> !ready
Processor 0: No threads in READY state
Processor 1: Ready Threads at priority 8
THREAD 85928570 Cid 0220.0820 Teb: 7ff8d000 Win32Thread: bc3bca20 READY
Processor 2: No threads in READY state
Processor 3: Ready Threads at priority 13
THREAD 858a1020 Cid 0fac.23e0 Teb: 7ffdb000 Win32Thread: bc0109c0 READY
Processor 3: Ready Threads at priority 11
THREAD 85e28768 Cid 028c.02e4 Teb: 7ffad000 Win32Thread: 00000000 READY
Processor 3: Ready Threads at priority 8
THREAD 84e48020 Cid 2c60.29f4 Teb: 7ffde000 Win32Thread: bc4da770 READY
1: kd> !thread
THREAD 855dd020 Cid 1428.2378 Teb: 7ffda000 Win32Thread: bc1717c8 RUNNING
on processor 1
Not impersonating
DeviceMap e1001900
Owning Process 8553f020
Wait Start TickCount 5333443 Elapsed Ticks: 0
Context Switch Count 280 LargeStack
UserTime 00:00:00.0000
KernelTime 00:00:00.0015
Start Address kernel32!FlsSetValue (0x77e4a99b)
Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
Stack Init ec252000 Current ec251bc4 Base ec252000 Limit ec24d000 Call 0
Priority 15 BasePriority 13 PriorityDecrement 0
ChildEBP RetAddr Args to Child
ec2517b4 80527624 0000008e c000001d bf8e59bc nt!KeBugCheckEx+0x19
ec251b70 804e087a ec251b8c 00000000 ec251be0 nt!KiDispatchException+0x2f5
ec251bd8 804e07fa 804ed800 855dd0c0 855dd020
nt!CommonDispatchException+0x4a (FPO: [0,20,0])
ec251c04 804eda20 00000000 00000000 00000023 nt!KiExceptionExit+0x16a
ec251c38 00000000 ec251c94 00000000 bf8e59bc nt!KeWaitForSingleObject+0x249

1: kd> !process -1 0
PROCESS 8553f020 SessionId: 4 Cid: 1428 Peb: 7ffdf000 ParentCid: 01d8
DirBase: 1fb9f000 ObjectTable: e287ad60 HandleCount: 221.
Image: winlogon.exe

1: kd> !cpuinfo
CP F/M/S Manufacturer MHz Update Signature Features
0 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
TargetInfo::ReadMsr is not available in the current debug session
1 15,2,7 GenuineIntel 2392>0000003400000000<00033fff
2 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
3 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
1: kd> !running

System Processors f (affinity mask)
Idle Processors 0

Prcb Current Next
0 ffdff120 85533020 ................
1 f772f120 855dd020 ................
2 f773f120 85150020 ................
3 f774f120 84ccd020 ................

1: kd> !irql
Debugger saved IRQL for processor 0x1 -- 0 (LOW_LEVEL)

c000001d == Invalid Instruction.

So, is there something I am missing? Is this a hardware failure? I would
say that the OS got into a bad state, but the processor is the one who
generates the exceptions, the OS just handles them. Any ideas where I
should look for this problem? Perhaps there is really a trap here
somewhere but the bluescreen information is invalid somehow. I have a few
of these traps, all in the same thread, in the context of GetMessage()
pretty much but traps in different places, all valid. Sometimes it's a
CALL it trapped on, another time it was "DEC ESP" or EBP. Nothing makes
much sense. I did get 1 trap that was really a trap in the same context,
someone apparently did a ret (most likely) or jmp to the thread context and
trapped on accessing invalid memory there. Perhaps something simmilar
happened with the rest, but the dumps are messed up.

2: kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
ec4e0c94 bf8e5db1 000025ff 00000000 00000001 0xbc165018
ec4e0cec bf8e6721 ec4e0d18 00000000 00000000 win32k+0xe5db1
ec4e0d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
ec4e0d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
0092fef8 77d06718 77d067e0 0092ff64 00000000 SharedUserData!SystemCallStub+0x4
0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
0092ffb8 77e4a990 002546d8 00000000 00000000 msvcrt!_endthreadex+0x95
0092ffec 00000000 77bc917e 002546d8 00000000 kernel32!FlsSetValue+0x779
2: kd> dd bc165018
bc165018 85524020 00000001 00000000 004c0740
bc165028 00000000 00000000 00000000 00000000
bc165038 bc165038 bc165038 00000000 bc0043b0
bc165048 bc16b698 bc1a8ba0 be251920 85482338
bc165058 be250650 bdd70000 7ffda6cc 03000000
bc165068 00000000 00000000 00000000 bc1b1c50
bc165078 04ebb876 00000001 00000000 00000104
bc165088 00000000 00000000 00000000 00000000
2: kd> !thread 85524020
THREAD 85524020 Cid 1520.1f2c Teb: 7ffda000 Win32Thread: bc165018 RUNNING
on processor 2
Not impersonating
DeviceMap e1001900
Owning Process 8549b968
Wait Start TickCount 5283651 Elapsed Ticks: 0
Context Switch Count 38 LargeStack
UserTime 00:00:00.0015
KernelTime 00:00:00.0000
Start Address kernel32!FlsSetValue (0x77e4a99b)
Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
Stack Init ec4e1000 Current ec4e00a0 Base ec4e1000 Limit ec4dc000 Call 0
Priority 15 BasePriority 13 PriorityDecrement 0
ChildEBP RetAddr Args to Child
ec4e07bc 80527624 0000008e c0000005 bc165018 nt!KeBugCheckEx+0x19
ec4e0b78 804e087a ec4e0b94 00000000 ec4e0be8 nt!KiDispatchException+0x2f5
ec4e0be0 804e0812 85524020 85421248 85465d40
nt!CommonDispatchException+0x4a (FPO: [0,20,0])
ec4e0c04 804eda20 00000000 bc165018 00000000 nt!KiExceptionExit+0x182
ec4e0c38 00000000 bc165018 00000000 ec4e0c94 nt!KeWaitForSingleObject+0x249

I started to look at other threads, perhaps the trap occured somewhere else
on another processor or on another thread that was previuosly active.

Also, does anyone know where to get the symbols for WIN32K.SYS for Windows
2003. It appears that the symbol server attempts to search for win32k.sys
as the symbol, but even renaming the win32k.pdb to win32k.sys it will not
load it, invalid signature. The dates for the files are the same day but
different times as well. Has anyone experienced this problem? I usually
use the symbol server, but I even downloaded the symbols from MS.

0: kd> lm v mwin32k
start end module name
bf800000 bf9c6000 win32k (no symbols)
Loaded symbol image file: win32k.sys
Image path: \SystemRoot\System32\win32k.sys
Timestamp: Tue Mar 25 03:40:49 2003 (3E801611) Checksum: 001CC3D7
ImageSize : 001C6000
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

Thanks

OSR_Community_User · November 8, 2003, 7:02pm

mov [ebp-0x20],eax ss:0010:ec251c74=00000000

It seems like the stack at ebp-0x20 is 0 and U r trying to indirect
(dereferencing ) 0 ???

-prokash
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 08, 2003 11:08 AM
Subject: [ntdev] Strange Traps?

> Hello Everyone,
>
> I am new to the list (I am not sure if NTDEV is right, but I also sent to
> WINDBG list), but I have been seeing some strange traps that I cannot seem
> to figure out what’s going on and would like some ideas. Basically, I
> have 2 traps on quad processor machines that are valid instructions,
> however, they caused a bluescreen.
>
> The trap occurs in the context of Winlogon. One of Winlogon’s threads is
> basically just making a GetMessage() call. The OS is Windows 2003.
>
> 1: kd> !analyze -v
>
************************************************************************

>

> * Bugcheck Analysis

>

>
*************************************************************************

>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
> This is a very common bugcheck. Usually the exception address pinpoints
> the driver/function that caused the problem. Always note this address
> as well as the link date of the driver/image that contains this address.
> Some common problems are exception code 0x80000003. This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. This will let us see why this breakpoint is
> happening.
> An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
> that an unaligned data reference was encountered. The trap frame will
> supply additional information.
> Arguments:
> Arg1: c000001d, The exception code that was not handled
> Arg2: bf8e59bc, The address that the exception occurred at
> Arg3: ec251be0, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal
> Instruction An attempt was made to execute an illegal instruction.
>
> FAULTING_IP:
> win32k+e59bc
> bf8e59bc 8945e0 mov [ebp-0x20],eax
>
> TRAP_FRAME: ec251be0 – (.trap ffffffffec251be0)
> ErrCode = 00000000
> eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8
edi=00000000
> eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po
cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010287
> win32k+0xe59bc:
> bf8e59bc 8945e0 mov [ebp-0x20],eax
ss:0010:ec251c74=00000000
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from bf8e5db1 to bf8e59bc
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
wrong.
> ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
> ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
> ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> 0092fef8 77d06718 77d067e0 0092ff64 00000000
SharedUserData!SystemCallStub+0x4
> 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
>
>
>
> FAILED_INSTRUCTION_ADDRESS:
> win32k+e59bc
> bf8e59bc 8945e0 mov [ebp-0x20],eax
>
> FOLLOWUP_IP:
> win32k+e59bc
> bf8e59bc 8945e0 mov [ebp-0x20],eax
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: win32k+e59bc
>
> MODULE_NAME: win32k
>
> IMAGE_NAME: win32k.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3e801611
>
> STACK_COMMAND: .trap ffffffffec251be0 ; kb
>
> BUCKET_ID: 0x8E_BAD_IP_win32k+e59bc
>
> Followup: MachineOwner
> ---------
>
>
> 1: kd> .trap ffffffffec251be0
> ErrCode = 00000000
> eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8
edi=00000000
> eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po
cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010287
> win32k+0xe59bc:
> bf8e59bc 8945e0 mov [ebp-0x20],eax
ss:0010:ec251c74=00000000
> 1: kd> kb
> Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> WARNING: Stack unwind information not available. Following frames may be
wrong.
> ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
> ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
> ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> 0092fef8 77d06718 77d067e0 0092ff64 00000000
SharedUserData!SystemCallStub+0x4
> 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
>
> 1: kd> u bf8e5db1
> win32k+0xe5db1:
> bf8e5db1 85c0 test eax,eax
> bf8e5db3 0f84ee030000 je win32k+0xe61a7 (bf8e61a7)
> bf8e5db9 e9f1010000 jmp win32k+0xe5faf (bf8e5faf)
> bf8e5dbe e873ecffff call win32k+0xe4a36 (bf8e4a36)
> bf8e5dc3 e9f5020000 jmp win32k+0xe60bd (bf8e60bd)
> bf8e5dc8 83600400 and dword ptr [eax+0x4],0x0
> bf8e5dcc 8b464c mov eax,[esi+0x4c]
> bf8e5dcf 85c2 test edx,eax
>
> 1: kd> u win32k+e59bc
> win32k+0xe59bc:
> bf8e59bc 8945e0 mov [ebp-0x20],eax
> bf8e59bf e894eeffff call win32k+0xe4858 (bf8e4858)
> bf8e59c4 56 push esi
> bf8e59c5 e844000000 call win32k+0xe5a0e (bf8e5a0e)
> bf8e59ca e9b2feffff jmp win32k+0xe5881 (bf8e5881)
> bf8e59cf 8b4640 mov eax,[esi+0x40]
> bf8e59d2 8b400c mov eax,[eax+0xc]
> bf8e59d5 0b869c000000 or eax,[esi+0x9c]
>
> 1: kd> dds ec251c94 -40
> ec251c54 00000000
> ec251c58 bc1717c8
> ec251c5c 00000000
> ec251c60 00000100
> ec251c64 855dd020
> ec251c68 804f0000 nt!KiRetireDpcList+0x10
> ec251c6c bc1717c8
> ec251c70 00000000
> ec251c74 00000000
> ec251c78 00000000
> ec251c7c ec251c54
> ec251c80 ec2516e8
> ec251c84 ec251cdc
> ec251c88 bf980f8a win32k+0x180f8a
> ec251c8c bf994f60 win32k+0x194f60
> ec251c90 ffffffff
> ec251c94 ec251cec
> ec251c98 bf8e5db1 win32k+0xe5db1
> ec251c9c 000025ff
> ec251ca0 00000000
> ec251ca4 00000001
> ec251ca8 ec251d64
> ec251cac 0092ff14
> ec251cb0 bf8e66fa win32k+0xe66fa
> ec251cb4 00000000
>
> Seems valid memory is being accessed.
>
> CP F/M/S Manufacturer MHz
> 0 15,2,7 GenuineIntel 2392
> 1 15,2,7 GenuineIntel 2392
> 2 15,2,7 GenuineIntel 2392
> 3 15,2,7 GenuineIntel 2392
> 1: kd> !ready
> Processor 0: No threads in READY state
> Processor 1: Ready Threads at priority 8
> THREAD 85928570 Cid 0220.0820 Teb: 7ff8d000 Win32Thread: bc3bca20
READY
> Processor 2: No threads in READY state
> Processor 3: Ready Threads at priority 13
> THREAD 858a1020 Cid 0fac.23e0 Teb: 7ffdb000 Win32Thread: bc0109c0
READY
> Processor 3: Ready Threads at priority 11
> THREAD 85e28768 Cid 028c.02e4 Teb: 7ffad000 Win32Thread: 00000000
READY
> Processor 3: Ready Threads at priority 8
> THREAD 84e48020 Cid 2c60.29f4 Teb: 7ffde000 Win32Thread: bc4da770
READY
> 1: kd> !thread
> THREAD 855dd020 Cid 1428.2378 Teb: 7ffda000 Win32Thread: bc1717c8
RUNNING
> on processor 1
> Not impersonating
> DeviceMap e1001900
> Owning Process 8553f020
> Wait Start TickCount 5333443 Elapsed Ticks: 0
> Context Switch Count 280 LargeStack
> UserTime 00:00:00.0000
> KernelTime 00:00:00.0015
> Start Address kernel32!FlsSetValue (0x77e4a99b)
> Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
> Stack Init ec252000 Current ec251bc4 Base ec252000 Limit ec24d000 Call 0
> Priority 15 BasePriority 13 PriorityDecrement 0
> ChildEBP RetAddr Args to Child
> ec2517b4 80527624 0000008e c000001d bf8e59bc nt!KeBugCheckEx+0x19
> ec251b70 804e087a ec251b8c 00000000 ec251be0 nt!KiDispatchException+0x2f5
> ec251bd8 804e07fa 804ed800 855dd0c0 855dd020
> nt!CommonDispatchException+0x4a (FPO: [0,20,0])
> ec251c04 804eda20 00000000 00000000 00000023 nt!KiExceptionExit+0x16a
> ec251c38 00000000 ec251c94 00000000 bf8e59bc
nt!KeWaitForSingleObject+0x249
>
> 1: kd> !process -1 0
> PROCESS 8553f020 SessionId: 4 Cid: 1428 Peb: 7ffdf000 ParentCid:
01d8
> DirBase: 1fb9f000 ObjectTable: e287ad60 HandleCount: 221.
> Image: winlogon.exe
>
> 1: kd> !cpuinfo
> CP F/M/S Manufacturer MHz Update Signature Features
> 0 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> TargetInfo::ReadMsr is not available in the current debug session
> 1 15,2,7 GenuineIntel 2392>0000003400000000<00033fff
> 2 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> 3 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> 1: kd> !running
>
> System Processors f (affinity mask)
> Idle Processors 0
>
> Prcb Current Next
> 0 ffdff120 85533020 …
> 1 f772f120 855dd020 …
> 2 f773f120 85150020 …
> 3 f774f120 84ccd020 …
>
> 1: kd> !irql
> Debugger saved IRQL for processor 0x1 – 0 (LOW_LEVEL)
>
>
> c000001d == Invalid Instruction.
>
>
>
> So, is there something I am missing? Is this a hardware failure? I would
> say that the OS got into a bad state, but the processor is the one who
> generates the exceptions, the OS just handles them. Any ideas where I
> should look for this problem? Perhaps there is really a trap here
> somewhere but the bluescreen information is invalid somehow. I have a few
> of these traps, all in the same thread, in the context of GetMessage()
> pretty much but traps in different places, all valid. Sometimes it’s a
> CALL it trapped on, another time it was “DEC ESP” or EBP. Nothing makes
> much sense. I did get 1 trap that was really a trap in the same context,
> someone apparently did a ret (most likely) or jmp to the thread context
and
> trapped on accessing invalid memory there. Perhaps something simmilar
> happened with the rest, but the dumps are messed up.
>
> 2: kd> kb
> Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> ec4e0c94 bf8e5db1 000025ff 00000000 00000001 0xbc165018
> ec4e0cec bf8e6721 ec4e0d18 00000000 00000000 win32k+0xe5db1
> ec4e0d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> ec4e0d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> 0092fef8 77d06718 77d067e0 0092ff64 00000000
SharedUserData!SystemCallStub+0x4
> 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
> 0092ffb8 77e4a990 002546d8 00000000 00000000 msvcrt!_endthreadex+0x95
> 0092ffec 00000000 77bc917e 002546d8 00000000 kernel32!FlsSetValue+0x779
> 2: kd> dd bc165018
> bc165018 85524020 00000001 00000000 004c0740
> bc165028 00000000 00000000 00000000 00000000
> bc165038 bc165038 bc165038 00000000 bc0043b0
> bc165048 bc16b698 bc1a8ba0 be251920 85482338
> bc165058 be250650 bdd70000 7ffda6cc 03000000
> bc165068 00000000 00000000 00000000 bc1b1c50
> bc165078 04ebb876 00000001 00000000 00000104
> bc165088 00000000 00000000 00000000 00000000
> 2: kd> !thread 85524020
> THREAD 85524020 Cid 1520.1f2c Teb: 7ffda000 Win32Thread: bc165018
RUNNING
> on processor 2
> Not impersonating
> DeviceMap e1001900
> Owning Process 8549b968
> Wait Start TickCount 5283651 Elapsed Ticks: 0
> Context Switch Count 38 LargeStack
> UserTime 00:00:00.0015
> KernelTime 00:00:00.0000
> Start Address kernel32!FlsSetValue (0x77e4a99b)
> Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
> Stack Init ec4e1000 Current ec4e00a0 Base ec4e1000 Limit ec4dc000 Call 0
> Priority 15 BasePriority 13 PriorityDecrement 0
> ChildEBP RetAddr Args to Child
> ec4e07bc 80527624 0000008e c0000005 bc165018 nt!KeBugCheckEx+0x19
> ec4e0b78 804e087a ec4e0b94 00000000 ec4e0be8 nt!KiDispatchException+0x2f5
> ec4e0be0 804e0812 85524020 85421248 85465d40
> nt!CommonDispatchException+0x4a (FPO: [0,20,0])
> ec4e0c04 804eda20 00000000 bc165018 00000000 nt!KiExceptionExit+0x182
> ec4e0c38 00000000 bc165018 00000000 ec4e0c94
nt!KeWaitForSingleObject+0x249
>
> I started to look at other threads, perhaps the trap occured somewhere
else
> on another processor or on another thread that was previuosly active.
>
>
> Also, does anyone know where to get the symbols for WIN32K.SYS for Windows
> 2003. It appears that the symbol server attempts to search for win32k.sys
> as the symbol, but even renaming the win32k.pdb to win32k.sys it will not
> load it, invalid signature. The dates for the files are the same day but
> different times as well. Has anyone experienced this problem? I usually
> use the symbol server, but I even downloaded the symbols from MS.
>
> 0: kd> lm v mwin32k
> start end module name
> bf800000 bf9c6000 win32k (no symbols)
> Loaded symbol image file: win32k.sys
> Image path: \SystemRoot\System32\win32k.sys
> Timestamp: Tue Mar 25 03:40:49 2003 (3E801611) Checksum: 001CC3D7
> ImageSize : 001C6000
> Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
>
>
>
> Thanks
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · November 8, 2003, 7:06pm

Nop, that is not true what I just said …

-prokash
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 08, 2003 11:08 AM
Subject: [ntdev] Strange Traps?

> Hello Everyone,
>
> I am new to the list (I am not sure if NTDEV is right, but I also sent to
> WINDBG list), but I have been seeing some strange traps that I cannot seem
> to figure out what’s going on and would like some ideas. Basically, I
> have 2 traps on quad processor machines that are valid instructions,
> however, they caused a bluescreen.
>
> The trap occurs in the context of Winlogon. One of Winlogon’s threads is
> basically just making a GetMessage() call. The OS is Windows 2003.
>
> 1: kd> !analyze -v
>
************************************************************************

>

> * Bugcheck Analysis

>

>
*************************************************************************

>
> KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
> This is a very common bugcheck. Usually the exception address pinpoints
> the driver/function that caused the problem. Always note this address
> as well as the link date of the driver/image that contains this address.
> Some common problems are exception code 0x80000003. This means a hard
> coded breakpoint or assertion was hit, but this system was booted
> /NODEBUG. This is not supposed to happen as developers should never have
> hardcoded breakpoints in retail code, but …
> If this happens, make sure a debugger gets connected, and the
> system is booted /DEBUG. This will let us see why this breakpoint is
> happening.
> An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
> that an unaligned data reference was encountered. The trap frame will
> supply additional information.
> Arguments:
> Arg1: c000001d, The exception code that was not handled
> Arg2: bf8e59bc, The address that the exception occurred at
> Arg3: ec251be0, Trap Frame
> Arg4: 00000000
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal
> Instruction An attempt was made to execute an illegal instruction.
>
> FAULTING_IP:
> win32k+e59bc
> bf8e59bc 8945e0 mov [ebp-0x20],eax
>
> TRAP_FRAME: ec251be0 – (.trap ffffffffec251be0)
> ErrCode = 00000000
> eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8
edi=00000000
> eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po
cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010287
> win32k+0xe59bc:
> bf8e59bc 8945e0 mov [ebp-0x20],eax
ss:0010:ec251c74=00000000
> Resetting default scope
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x8E
>
> CURRENT_IRQL: 0
>
> LAST_CONTROL_TRANSFER: from bf8e5db1 to bf8e59bc
>
> STACK_TEXT:
> WARNING: Stack unwind information not available. Following frames may be
wrong.
> ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
> ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
> ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> 0092fef8 77d06718 77d067e0 0092ff64 00000000
SharedUserData!SystemCallStub+0x4
> 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
>
>
>
> FAILED_INSTRUCTION_ADDRESS:
> win32k+e59bc
> bf8e59bc 8945e0 mov [ebp-0x20],eax
>
> FOLLOWUP_IP:
> win32k+e59bc
> bf8e59bc 8945e0 mov [ebp-0x20],eax
>
> SYMBOL_STACK_INDEX: 0
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: win32k+e59bc
>
> MODULE_NAME: win32k
>
> IMAGE_NAME: win32k.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 3e801611
>
> STACK_COMMAND: .trap ffffffffec251be0 ; kb
>
> BUCKET_ID: 0x8E_BAD_IP_win32k+e59bc
>
> Followup: MachineOwner
> ---------
>
>
> 1: kd> .trap ffffffffec251be0
> ErrCode = 00000000
> eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8
edi=00000000
> eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po
cy
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010287
> win32k+0xe59bc:
> bf8e59bc 8945e0 mov [ebp-0x20],eax
ss:0010:ec251c74=00000000
> 1: kd> kb
> Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> WARNING: Stack unwind information not available. Following frames may be
wrong.
> ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
> ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
> ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> 0092fef8 77d06718 77d067e0 0092ff64 00000000
SharedUserData!SystemCallStub+0x4
> 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
>
> 1: kd> u bf8e5db1
> win32k+0xe5db1:
> bf8e5db1 85c0 test eax,eax
> bf8e5db3 0f84ee030000 je win32k+0xe61a7 (bf8e61a7)
> bf8e5db9 e9f1010000 jmp win32k+0xe5faf (bf8e5faf)
> bf8e5dbe e873ecffff call win32k+0xe4a36 (bf8e4a36)
> bf8e5dc3 e9f5020000 jmp win32k+0xe60bd (bf8e60bd)
> bf8e5dc8 83600400 and dword ptr [eax+0x4],0x0
> bf8e5dcc 8b464c mov eax,[esi+0x4c]
> bf8e5dcf 85c2 test edx,eax
>
> 1: kd> u win32k+e59bc
> win32k+0xe59bc:
> bf8e59bc 8945e0 mov [ebp-0x20],eax
> bf8e59bf e894eeffff call win32k+0xe4858 (bf8e4858)
> bf8e59c4 56 push esi
> bf8e59c5 e844000000 call win32k+0xe5a0e (bf8e5a0e)
> bf8e59ca e9b2feffff jmp win32k+0xe5881 (bf8e5881)
> bf8e59cf 8b4640 mov eax,[esi+0x40]
> bf8e59d2 8b400c mov eax,[eax+0xc]
> bf8e59d5 0b869c000000 or eax,[esi+0x9c]
>
> 1: kd> dds ec251c94 -40
> ec251c54 00000000
> ec251c58 bc1717c8
> ec251c5c 00000000
> ec251c60 00000100
> ec251c64 855dd020
> ec251c68 804f0000 nt!KiRetireDpcList+0x10
> ec251c6c bc1717c8
> ec251c70 00000000
> ec251c74 00000000
> ec251c78 00000000
> ec251c7c ec251c54
> ec251c80 ec2516e8
> ec251c84 ec251cdc
> ec251c88 bf980f8a win32k+0x180f8a
> ec251c8c bf994f60 win32k+0x194f60
> ec251c90 ffffffff
> ec251c94 ec251cec
> ec251c98 bf8e5db1 win32k+0xe5db1
> ec251c9c 000025ff
> ec251ca0 00000000
> ec251ca4 00000001
> ec251ca8 ec251d64
> ec251cac 0092ff14
> ec251cb0 bf8e66fa win32k+0xe66fa
> ec251cb4 00000000
>
> Seems valid memory is being accessed.
>
> CP F/M/S Manufacturer MHz
> 0 15,2,7 GenuineIntel 2392
> 1 15,2,7 GenuineIntel 2392
> 2 15,2,7 GenuineIntel 2392
> 3 15,2,7 GenuineIntel 2392
> 1: kd> !ready
> Processor 0: No threads in READY state
> Processor 1: Ready Threads at priority 8
> THREAD 85928570 Cid 0220.0820 Teb: 7ff8d000 Win32Thread: bc3bca20
READY
> Processor 2: No threads in READY state
> Processor 3: Ready Threads at priority 13
> THREAD 858a1020 Cid 0fac.23e0 Teb: 7ffdb000 Win32Thread: bc0109c0
READY
> Processor 3: Ready Threads at priority 11
> THREAD 85e28768 Cid 028c.02e4 Teb: 7ffad000 Win32Thread: 00000000
READY
> Processor 3: Ready Threads at priority 8
> THREAD 84e48020 Cid 2c60.29f4 Teb: 7ffde000 Win32Thread: bc4da770
READY
> 1: kd> !thread
> THREAD 855dd020 Cid 1428.2378 Teb: 7ffda000 Win32Thread: bc1717c8
RUNNING
> on processor 1
> Not impersonating
> DeviceMap e1001900
> Owning Process 8553f020
> Wait Start TickCount 5333443 Elapsed Ticks: 0
> Context Switch Count 280 LargeStack
> UserTime 00:00:00.0000
> KernelTime 00:00:00.0015
> Start Address kernel32!FlsSetValue (0x77e4a99b)
> Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
> Stack Init ec252000 Current ec251bc4 Base ec252000 Limit ec24d000 Call 0
> Priority 15 BasePriority 13 PriorityDecrement 0
> ChildEBP RetAddr Args to Child
> ec2517b4 80527624 0000008e c000001d bf8e59bc nt!KeBugCheckEx+0x19
> ec251b70 804e087a ec251b8c 00000000 ec251be0 nt!KiDispatchException+0x2f5
> ec251bd8 804e07fa 804ed800 855dd0c0 855dd020
> nt!CommonDispatchException+0x4a (FPO: [0,20,0])
> ec251c04 804eda20 00000000 00000000 00000023 nt!KiExceptionExit+0x16a
> ec251c38 00000000 ec251c94 00000000 bf8e59bc
nt!KeWaitForSingleObject+0x249
>
> 1: kd> !process -1 0
> PROCESS 8553f020 SessionId: 4 Cid: 1428 Peb: 7ffdf000 ParentCid:
01d8
> DirBase: 1fb9f000 ObjectTable: e287ad60 HandleCount: 221.
> Image: winlogon.exe
>
> 1: kd> !cpuinfo
> CP F/M/S Manufacturer MHz Update Signature Features
> 0 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> TargetInfo::ReadMsr is not available in the current debug session
> 1 15,2,7 GenuineIntel 2392>0000003400000000<00033fff
> 2 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> 3 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> 1: kd> !running
>
> System Processors f (affinity mask)
> Idle Processors 0
>
> Prcb Current Next
> 0 ffdff120 85533020 …
> 1 f772f120 855dd020 …
> 2 f773f120 85150020 …
> 3 f774f120 84ccd020 …
>
> 1: kd> !irql
> Debugger saved IRQL for processor 0x1 – 0 (LOW_LEVEL)
>
>
> c000001d == Invalid Instruction.
>
>
>
> So, is there something I am missing? Is this a hardware failure? I would
> say that the OS got into a bad state, but the processor is the one who
> generates the exceptions, the OS just handles them. Any ideas where I
> should look for this problem? Perhaps there is really a trap here
> somewhere but the bluescreen information is invalid somehow. I have a few
> of these traps, all in the same thread, in the context of GetMessage()
> pretty much but traps in different places, all valid. Sometimes it’s a
> CALL it trapped on, another time it was “DEC ESP” or EBP. Nothing makes
> much sense. I did get 1 trap that was really a trap in the same context,
> someone apparently did a ret (most likely) or jmp to the thread context
and
> trapped on accessing invalid memory there. Perhaps something simmilar
> happened with the rest, but the dumps are messed up.
>
> 2: kd> kb
> Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> ec4e0c94 bf8e5db1 000025ff 00000000 00000001 0xbc165018
> ec4e0cec bf8e6721 ec4e0d18 00000000 00000000 win32k+0xe5db1
> ec4e0d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> ec4e0d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> 0092fef8 77d06718 77d067e0 0092ff64 00000000
SharedUserData!SystemCallStub+0x4
> 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
> 0092ffb8 77e4a990 002546d8 00000000 00000000 msvcrt!_endthreadex+0x95
> 0092ffec 00000000 77bc917e 002546d8 00000000 kernel32!FlsSetValue+0x779
> 2: kd> dd bc165018
> bc165018 85524020 00000001 00000000 004c0740
> bc165028 00000000 00000000 00000000 00000000
> bc165038 bc165038 bc165038 00000000 bc0043b0
> bc165048 bc16b698 bc1a8ba0 be251920 85482338
> bc165058 be250650 bdd70000 7ffda6cc 03000000
> bc165068 00000000 00000000 00000000 bc1b1c50
> bc165078 04ebb876 00000001 00000000 00000104
> bc165088 00000000 00000000 00000000 00000000
> 2: kd> !thread 85524020
> THREAD 85524020 Cid 1520.1f2c Teb: 7ffda000 Win32Thread: bc165018
RUNNING
> on processor 2
> Not impersonating
> DeviceMap e1001900
> Owning Process 8549b968
> Wait Start TickCount 5283651 Elapsed Ticks: 0
> Context Switch Count 38 LargeStack
> UserTime 00:00:00.0015
> KernelTime 00:00:00.0000
> Start Address kernel32!FlsSetValue (0x77e4a99b)
> Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
> Stack Init ec4e1000 Current ec4e00a0 Base ec4e1000 Limit ec4dc000 Call 0
> Priority 15 BasePriority 13 PriorityDecrement 0
> ChildEBP RetAddr Args to Child
> ec4e07bc 80527624 0000008e c0000005 bc165018 nt!KeBugCheckEx+0x19
> ec4e0b78 804e087a ec4e0b94 00000000 ec4e0be8 nt!KiDispatchException+0x2f5
> ec4e0be0 804e0812 85524020 85421248 85465d40
> nt!CommonDispatchException+0x4a (FPO: [0,20,0])
> ec4e0c04 804eda20 00000000 bc165018 00000000 nt!KiExceptionExit+0x182
> ec4e0c38 00000000 bc165018 00000000 ec4e0c94
nt!KeWaitForSingleObject+0x249
>
> I started to look at other threads, perhaps the trap occured somewhere
else
> on another processor or on another thread that was previuosly active.
>
>
> Also, does anyone know where to get the symbols for WIN32K.SYS for Windows
> 2003. It appears that the symbol server attempts to search for win32k.sys
> as the symbol, but even renaming the win32k.pdb to win32k.sys it will not
> load it, invalid signature. The dates for the files are the same day but
> different times as well. Has anyone experienced this problem? I usually
> use the symbol server, but I even downloaded the symbols from MS.
>
> 0: kd> lm v mwin32k
> start end module name
> bf800000 bf9c6000 win32k (no symbols)
> Loaded symbol image file: win32k.sys
> Image path: \SystemRoot\System32\win32k.sys
> Timestamp: Tue Mar 25 03:40:49 2003 (3E801611) Checksum: 001CC3D7
> ImageSize : 001C6000
> Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
>
>
>
> Thanks
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@garlic.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>

OSR_Community_User · November 8, 2003, 7:18pm

I found out the machines had Hyper Threading enabled, so it’s actually a
dual processor machine not a quad processor. I have read that this can
cause some problems and these are new machines that we have not seen these
issues before so I’m hoping this could be a cause to the problem. I am
going to try to have this run again without hyperthreading enabled and
hopefully solve the problem. Anyone have any ideas if this could be the
case? Windows 2003 is supposed to support HT. The same machines used
WIndows 2000 without a problem though and according to some websites 2000
doesn’t support HT.

At 04:05 PM 11/8/2003 -0800, you wrote:

Nop, that is not true what I just said …

-prokash
----- Original Message -----
From:
>To: “Windows System Software Devs Interest List”
>Sent: Saturday, November 08, 2003 11:08 AM
>Subject: [ntdev] Strange Traps?
>
>
> > Hello Everyone,
> >
> > I am new to the list (I am not sure if NTDEV is right, but I also sent to
> > WINDBG list), but I have been seeing some strange traps that I cannot seem
> > to figure out what’s going on and would like some ideas. Basically, I
> > have 2 traps on quad processor machines that are valid instructions,
> > however, they caused a bluescreen.
> >
> > The trap occurs in the context of Winlogon. One of Winlogon’s threads is
> > basically just making a GetMessage() call. The OS is Windows 2003.
> >
> > 1: kd> !analyze -v
> >
> ************************************************************************
>
> >
>
> > * Bugcheck Analysis
>
> >
>
> >
> *************************************************************************
>
> >
> > KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
> > This is a very common bugcheck. Usually the exception address pinpoints
> > the driver/function that caused the problem. Always note this address
> > as well as the link date of the driver/image that contains this address.
> > Some common problems are exception code 0x80000003. This means a hard
> > coded breakpoint or assertion was hit, but this system was booted
> > /NODEBUG. This is not supposed to happen as developers should never have
> > hardcoded breakpoints in retail code, but …
> > If this happens, make sure a debugger gets connected, and the
> > system is booted /DEBUG. This will let us see why this breakpoint is
> > happening.
> > An exception code of 0x80000002 (STATUS_DATATYPE_MISALIGNMENT) indicates
> > that an unaligned data reference was encountered. The trap frame will
> > supply additional information.
> > Arguments:
> > Arg1: c000001d, The exception code that was not handled
> > Arg2: bf8e59bc, The address that the exception occurred at
> > Arg3: ec251be0, Trap Frame
> > Arg4: 00000000
> >
> > Debugging Details:
> > ------------------
> >
> >
> > EXCEPTION_CODE: (NTSTATUS) 0xc000001d - {EXCEPTION} Illegal
> > Instruction An attempt was made to execute an illegal instruction.
> >
> > FAULTING_IP:
> > win32k+e59bc
> > bf8e59bc 8945e0 mov [ebp-0x20],eax
> >
> > TRAP_FRAME: ec251be0 – (.trap ffffffffec251be0)
> > ErrCode = 00000000
> > eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8
>edi=00000000
> > eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po
>cy
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>efl=00010287
> > win32k+0xe59bc:
> > bf8e59bc 8945e0 mov [ebp-0x20],eax
>ss:0010:ec251c74=00000000
> > Resetting default scope
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0x8E
> >
> > CURRENT_IRQL: 0
> >
> > LAST_CONTROL_TRANSFER: from bf8e5db1 to bf8e59bc
> >
> > STACK_TEXT:
> > WARNING: Stack unwind information not available. Following frames may be
>wrong.
> > ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
> > ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
> > ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> > ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> > 0092fef8 77d06718 77d067e0 0092ff64 00000000
>SharedUserData!SystemCallStub+0x4
> > 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
> >
> >
> >
> > FAILED_INSTRUCTION_ADDRESS:
> > win32k+e59bc
> > bf8e59bc 8945e0 mov [ebp-0x20],eax
> >
> > FOLLOWUP_IP:
> > win32k+e59bc
> > bf8e59bc 8945e0 mov [ebp-0x20],eax
> >
> > SYMBOL_STACK_INDEX: 0
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: win32k+e59bc
> >
> > MODULE_NAME: win32k
> >
> > IMAGE_NAME: win32k.sys
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3e801611
> >
> > STACK_COMMAND: .trap ffffffffec251be0 ; kb
> >
> > BUCKET_ID: 0x8E_BAD_IP_win32k+e59bc
> >
> > Followup: MachineOwner
> > ---------
> >
> >
> > 1: kd> .trap ffffffffec251be0
> > ErrCode = 00000000
> > eax=00000000 ebx=00000000 ecx=00000000 edx=80010031 esi=bc1717c8
>edi=00000000
> > eip=bf8e59bc esp=ec251c54 ebp=ec251c94 iopl=0 nv up ei ng nz na po
>cy
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
>efl=00010287
> > win32k+0xe59bc:
> > bf8e59bc 8945e0 mov [ebp-0x20],eax
>ss:0010:ec251c74=00000000
> > 1: kd> kb
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > WARNING: Stack unwind information not available. Following frames may be
>wrong.
> > ec251c94 bf8e5db1 000025ff 00000000 00000001 win32k+0xe59bc
> > ec251cec bf8e6721 ec251d18 00000000 00000000 win32k+0xe5db1
> > ec251d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> > ec251d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> > 0092fef8 77d06718 77d067e0 0092ff64 00000000
>SharedUserData!SystemCallStub+0x4
> > 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
> >
> > 1: kd> u bf8e5db1
> > win32k+0xe5db1:
> > bf8e5db1 85c0 test eax,eax
> > bf8e5db3 0f84ee030000 je win32k+0xe61a7 (bf8e61a7)
> > bf8e5db9 e9f1010000 jmp win32k+0xe5faf (bf8e5faf)
> > bf8e5dbe e873ecffff call win32k+0xe4a36 (bf8e4a36)
> > bf8e5dc3 e9f5020000 jmp win32k+0xe60bd (bf8e60bd)
> > bf8e5dc8 83600400 and dword ptr [eax+0x4],0x0
> > bf8e5dcc 8b464c mov eax,[esi+0x4c]
> > bf8e5dcf 85c2 test edx,eax
> >
> > 1: kd> u win32k+e59bc
> > win32k+0xe59bc:
> > bf8e59bc 8945e0 mov [ebp-0x20],eax
> > bf8e59bf e894eeffff call win32k+0xe4858 (bf8e4858)
> > bf8e59c4 56 push esi
> > bf8e59c5 e844000000 call win32k+0xe5a0e (bf8e5a0e)
> > bf8e59ca e9b2feffff jmp win32k+0xe5881 (bf8e5881)
> > bf8e59cf 8b4640 mov eax,[esi+0x40]
> > bf8e59d2 8b400c mov eax,[eax+0xc]
> > bf8e59d5 0b869c000000 or eax,[esi+0x9c]
> >
> > 1: kd> dds ec251c94 -40
> > ec251c54 00000000
> > ec251c58 bc1717c8
> > ec251c5c 00000000
> > ec251c60 00000100
> > ec251c64 855dd020
> > ec251c68 804f0000 nt!KiRetireDpcList+0x10
> > ec251c6c bc1717c8
> > ec251c70 00000000
> > ec251c74 00000000
> > ec251c78 00000000
> > ec251c7c ec251c54
> > ec251c80 ec2516e8
> > ec251c84 ec251cdc
> > ec251c88 bf980f8a win32k+0x180f8a
> > ec251c8c bf994f60 win32k+0x194f60
> > ec251c90 ffffffff
> > ec251c94 ec251cec
> > ec251c98 bf8e5db1 win32k+0xe5db1
> > ec251c9c 000025ff
> > ec251ca0 00000000
> > ec251ca4 00000001
> > ec251ca8 ec251d64
> > ec251cac 0092ff14
> > ec251cb0 bf8e66fa win32k+0xe66fa
> > ec251cb4 00000000
> >
> > Seems valid memory is being accessed.
> >
> > CP F/M/S Manufacturer MHz
> > 0 15,2,7 GenuineIntel 2392
> > 1 15,2,7 GenuineIntel 2392
> > 2 15,2,7 GenuineIntel 2392
> > 3 15,2,7 GenuineIntel 2392
> > 1: kd> !ready
> > Processor 0: No threads in READY state
> > Processor 1: Ready Threads at priority 8
> > THREAD 85928570 Cid 0220.0820 Teb: 7ff8d000 Win32Thread: bc3bca20
>READY
> > Processor 2: No threads in READY state
> > Processor 3: Ready Threads at priority 13
> > THREAD 858a1020 Cid 0fac.23e0 Teb: 7ffdb000 Win32Thread: bc0109c0
>READY
> > Processor 3: Ready Threads at priority 11
> > THREAD 85e28768 Cid 028c.02e4 Teb: 7ffad000 Win32Thread: 00000000
>READY
> > Processor 3: Ready Threads at priority 8
> > THREAD 84e48020 Cid 2c60.29f4 Teb: 7ffde000 Win32Thread: bc4da770
>READY
> > 1: kd> !thread
> > THREAD 855dd020 Cid 1428.2378 Teb: 7ffda000 Win32Thread: bc1717c8
>RUNNING
> > on processor 1
> > Not impersonating
> > DeviceMap e1001900
> > Owning Process 8553f020
> > Wait Start TickCount 5333443 Elapsed Ticks: 0
> > Context Switch Count 280 LargeStack
> > UserTime 00:00:00.0000
> > KernelTime 00:00:00.0015
> > Start Address kernel32!FlsSetValue (0x77e4a99b)
> > Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
> > Stack Init ec252000 Current ec251bc4 Base ec252000 Limit ec24d000 Call 0
> > Priority 15 BasePriority 13 PriorityDecrement 0
> > ChildEBP RetAddr Args to Child
> > ec2517b4 80527624 0000008e c000001d bf8e59bc nt!KeBugCheckEx+0x19
> > ec251b70 804e087a ec251b8c 00000000 ec251be0 nt!KiDispatchException+0x2f5
> > ec251bd8 804e07fa 804ed800 855dd0c0 855dd020
> > nt!CommonDispatchException+0x4a (FPO: [0,20,0])
> > ec251c04 804eda20 00000000 00000000 00000023 nt!KiExceptionExit+0x16a
> > ec251c38 00000000 ec251c94 00000000 bf8e59bc
>nt!KeWaitForSingleObject+0x249
> >
> > 1: kd> !process -1 0
> > PROCESS 8553f020 SessionId: 4 Cid: 1428 Peb: 7ffdf000 ParentCid:
>01d8
> > DirBase: 1fb9f000 ObjectTable: e287ad60 HandleCount: 221.
> > Image: winlogon.exe
> >
> > 1: kd> !cpuinfo
> > CP F/M/S Manufacturer MHz Update Signature Features
> > 0 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> > TargetInfo::ReadMsr is not available in the current debug session
> > 1 15,2,7 GenuineIntel 2392>0000003400000000<00033fff
> > 2 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> > 3 15,2,7 GenuineIntel 2392 0000003400000000 00033fff
> > 1: kd> !running
> >
> > System Processors f (affinity mask)
> > Idle Processors 0
> >
> > Prcb Current Next
> > 0 ffdff120 85533020 …
> > 1 f772f120 855dd020 …
> > 2 f773f120 85150020 …
> > 3 f774f120 84ccd020 …
> >
> > 1: kd> !irql
> > Debugger saved IRQL for processor 0x1 – 0 (LOW_LEVEL)
> >
> >
> > c000001d == Invalid Instruction.
> >
> >
> >
> > So, is there something I am missing? Is this a hardware failure? I would
> > say that the OS got into a bad state, but the processor is the one who
> > generates the exceptions, the OS just handles them. Any ideas where I
> > should look for this problem? Perhaps there is really a trap here
> > somewhere but the bluescreen information is invalid somehow. I have a few
> > of these traps, all in the same thread, in the context of GetMessage()
> > pretty much but traps in different places, all valid. Sometimes it’s a
> > CALL it trapped on, another time it was “DEC ESP” or EBP. Nothing makes
> > much sense. I did get 1 trap that was really a trap in the same context,
> > someone apparently did a ret (most likely) or jmp to the thread context
>and
> > trapped on accessing invalid memory there. Perhaps something simmilar
> > happened with the rest, but the dumps are messed up.
> >
> > 2: kd> kb
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > WARNING: Frame IP not in any known module. Following frames may be wrong.
> > ec4e0c94 bf8e5db1 000025ff 00000000 00000001 0xbc165018
> > ec4e0cec bf8e6721 ec4e0d18 00000000 00000000 win32k+0xe5db1
> > ec4e0d4c 804dfd24 0092ff64 00000000 00000000 win32k+0xe6721
> > ec4e0d4c 7ffe0304 0092ff64 00000000 00000000 nt!KiSystemService+0xd0
> > 0092fef8 77d06718 77d067e0 0092ff64 00000000
>SharedUserData!SystemCallStub+0x4
> > 0092ff18 67481876 0092ff64 00000000 00000000 USER32!NtUserGetMessage+0xc
> > 0092ffb8 77e4a990 002546d8 00000000 00000000 msvcrt!_endthreadex+0x95
> > 0092ffec 00000000 77bc917e 002546d8 00000000 kernel32!FlsSetValue+0x779
> > 2: kd> dd bc165018
> > bc165018 85524020 00000001 00000000 004c0740
> > bc165028 00000000 00000000 00000000 00000000
> > bc165038 bc165038 bc165038 00000000 bc0043b0
> > bc165048 bc16b698 bc1a8ba0 be251920 85482338
> > bc165058 be250650 bdd70000 7ffda6cc 03000000
> > bc165068 00000000 00000000 00000000 bc1b1c50
> > bc165078 04ebb876 00000001 00000000 00000104
> > bc165088 00000000 00000000 00000000 00000000
> > 2: kd> !thread 85524020
> > THREAD 85524020 Cid 1520.1f2c Teb: 7ffda000 Win32Thread: bc165018
>RUNNING
> > on processor 2
> > Not impersonating
> > DeviceMap e1001900
> > Owning Process 8549b968
> > Wait Start TickCount 5283651 Elapsed Ticks: 0
> > Context Switch Count 38 LargeStack
> > UserTime 00:00:00.0015
> > KernelTime 00:00:00.0000
> > Start Address kernel32!FlsSetValue (0x77e4a99b)
> > Win32 Start Address msvcrt!_endthreadex (0x77bc917e)
> > Stack Init ec4e1000 Current ec4e00a0 Base ec4e1000 Limit ec4dc000 Call 0
> > Priority 15 BasePriority 13 PriorityDecrement 0
> > ChildEBP RetAddr Args to Child
> > ec4e07bc 80527624 0000008e c0000005 bc165018 nt!KeBugCheckEx+0x19
> > ec4e0b78 804e087a ec4e0b94 00000000 ec4e0be8 nt!KiDispatchException+0x2f5
> > ec4e0be0 804e0812 85524020 85421248 85465d40
> > nt!CommonDispatchException+0x4a (FPO: [0,20,0])
> > ec4e0c04 804eda20 00000000 bc165018 00000000 nt!KiExceptionExit+0x182
> > ec4e0c38 00000000 bc165018 00000000 ec4e0c94
>nt!KeWaitForSingleObject+0x249
> >
> > I started to look at other threads, perhaps the trap occured somewhere
>else
> > on another processor or on another thread that was previuosly active.
> >
> >
> > Also, does anyone know where to get the symbols for WIN32K.SYS for Windows
> > 2003. It appears that the symbol server attempts to search for win32k.sys
> > as the symbol, but even renaming the win32k.pdb to win32k.sys it will not
> > load it, invalid signature. The dates for the files are the same day but
> > different times as well. Has anyone experienced this problem? I usually
> > use the symbol server, but I even downloaded the symbols from MS.
> >
> > 0: kd> lm v mwin32k
> > start end module name
> > bf800000 bf9c6000 win32k (no symbols)
> > Loaded symbol image file: win32k.sys
> > Image path: \SystemRoot\System32\win32k.sys
> > Timestamp: Tue Mar 25 03:40:49 2003 (3E801611) Checksum: 001CC3D7
> > ImageSize : 001C6000
> > Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0
> >
> >
> >
> > Thanks
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@garlic.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@opferman.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

Loren_Wilton · November 8, 2003, 7:30pm

W2K doesn’t support HT as well as it could, but the code works.

I don’t immediately see this problem as an HT problem, but I’m not sure
exactly what it is. I would have liked to see the instruction before the
failing instruction, but I didn’t see that in your dump info.

Are these HT machines somrthing standard like Dell boxes? Or are you
running some prototype Intel chip? I doubt that you are, but I very vaguely
remember that very early chip revisions (that you probably would never have
seen) had some interesting errata.

Loren

OSR_Community_User · November 8, 2003, 8:03pm

Ya, I didn’t have any traps on Windows 2000, just 2003. I’m not 100% on
hyperthreading being the problem, but I know it does cause problems,
perhaps the bios needs updating. I’ve heard people say even with a new
machine they’ve needed to update thier bios as well as video cards causing
bs’s. I don’t know really anything about it, I’m just thinking of what
variables I can eliminate. The next step is probably to attempt driver
verifier.

These are new ibm @server machines, dual processor 2.4 Ghz

Here’s the information you asked about along with the currently running
threads.

1: kd> u
win32k+0xe59ae:
bf8e59ae 6a0d push 0xd
bf8e59b0 ffb6ac000000 push dword ptr [esi+0xac]
bf8e59b6 ff15a06198bf call dword ptr [win32k+0x1861a0 (bf9861a0)]
bf8e59bc 8945e0 mov [ebp-0x20],eax <– TRAP
bf8e59bf e894eeffff call win32k+0xe4858 (bf8e4858)
bf8e59c4 56 push esi
bf8e59c5 e844000000 call win32k+0xe5a0e (bf8e5a0e)
bf8e59ca e9b2feffff jmp win32k+0xe5881 (bf8e5881)
1: kd> u poi bf9861a0
nt!KeWaitForSingleObject:

1: kd> !running -t

System Processors f (affinity mask)
Idle Processors 0

Prcb Current Next
0 ffdff120 85533020 …

*** ERROR: Symbol file could not be found. Defaulted to export symbols for
ntdll.dll -
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 ntdll!RtlEnterCriticalSection+0x1a

1 f772f120 855dd020 …

*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
ec251c94 bf8e5db1 win32k+0xe59bc
ec251cec bf8e6721 win32k+0xe5db1
ec251d4c 804dfd24 win32k+0xe6721
ec251d4c 7ffe0304 nt!KiSystemService+0xd0
0092fef8 77d06718 SharedUserData!SystemCallStub+0x4
0092ff18 67481876 USER32!NtUserGetMessage+0xc
0092ffb8 77e4a990 msvcrt!_endthreadex+0x95
0092ffec 00000000 kernel32!FlsSetValue+0x779

2 f773f120 85150020 …

ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 ntdll!wcsnicmp

3 f774f120 84ccd020 …

ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0006e954 77f52042 ntdll!RtlFindMessage+0x23f
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
mfaphook.dll -
0006e994 679c11ed ntdll!LdrGetProcedureAddress+0x17
0006ea6c 70be5bfd MSGINA!_tailMerge_COMCTL32+0xd
0006eac4 77d0612f COMCTL32_70bc0000!MasterSubclassProc+0x51
0006eaf0 77d069a5 USER32!InternalCallWinProc+0x1b
0006eb68 77d080a0 USER32!UserCallWinProcCheckWow+0x151
0006ebc4 77d095b0 USER32!DispatchClientMessage+0xd9
0006ebec 77f43868 USER32!__fnINOUTLPSCROLLINFO+0x25
0006ec70 75849704 ntdll!KiUserCallbackDispatcher+0x13
0006eedc 75847d57 MSGINA!LogonDlgInit+0x332
0006f05c 77d0b191 MSGINA!LogonDlgProc+0x26e
*** ERROR: Module load completed but symbols could not be loaded for
winlogon.exe
0006f094 0103f507 USER32!NtUserSetWindowLong+0xc
0006f0b8 77d0612f winlogon+0x3f507
0006f0e4 77d10843 USER32!InternalCallWinProc+0x1b
0006f160 77d106b9 USER32!UserCallDlgProcCheckWow+0x147
0006f1a8 77d10b7d USER32!DefDlgProcWorker+0xa6
0006f1d8 77d122df USER32!SendMessageWorker+0x43c
0006f290 77d11094 USER32!InternalCreateDialog+0x9c9
0006f2c4 77d110e7 USER32!InternalDialogBox+0xa7

1: kd> ~2s
2: kd> kb
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
00000000 00000000 00000000 00000000 00000000 ntdll!wcsnicmp
2: kd> dds esp
0006ed6c 679c272f
0006ed70 00172980
0006ed74 00084444
0006ed78 00000016
0006ed7c 0000008f
0006ed80 67cf11e4*** ERROR: Module load completed but symbols could not be
loaded for cxinjime.dll
cxinjime+0x11e4
0006ed84 00084440
0006ed88 0006edb4
0006ed8c 679c2aab
0006ed90 00084444
0006ed94 71b20000 mswsock!_imp__GetUserNameA (mswsock+0x0)
0006ed98 00084430
0006ed9c 0008d4a8
0006eda0 71b21000 mswsock!_imp _MapViewOfFile
0006eda4 77fc23ac ntdll!NlsMbOemCodePageTag+0x39c
0006eda8 00000418
0006edac 00000000
0006edb0 71b211d8 mswsock!imp strncmp
0006edb4 0006edc8
0006edb8 679c2e04
0006edbc 71b20000 mswsock!_imp__GetUserNameA (mswsock+0x0)
0006edc0 00085100
0006edc4 00000000
0006edc8 0006ee78
0006edcc 679c1896
0006edd0 71b20000 mswsock!_imp__GetUserNameA (mswsock+0x0)
0006edd4 00085100
0006edd8 00000000
0006eddc 679c1864
0006ede0 00000000
0006ede4 77c82c06 RPCRT4!RPC_WSAStartup+0x36
0006ede8 77c82db4 RPCRT4!`string’
2: kd> r
eax=00000016 ebx=001729a0 ecx=00000077 edx=00000069 esi=00172a40 edi=77fc23ac
eip=77f7c02f esp=0006ed6c ebp=00000000 iopl=0 nv up ei ng nz ac pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000293
ntdll!wcsnicmp:
001b:77f7c02f 33c0 xor eax,eax
2: kd> ~0s
0: kd> r
eax=7ffdf000 ebx=00000046 ecx=7ffde000 edx=77fc2340 esi=00085100 edi=67cf1260
eip=77f4201a esp=0006fddc ebp=00000000 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!RtlEnterCriticalSection+0x1a:
001b:77f4201a 7512 jnz ntdll!RtlEnterCriticalSection+0x2e (77f4202e) [br=1]
0: kd> ~3s
3: kd> r
eax=001751b0 ebx=00000000 ecx=70be5b5e edx=00000000 esi=00000001 edi=00000000
eip=77f51b16 esp=0006e8cc ebp=0006e954 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!RtlFindMessage+0x23f:
001b:77f51b16 0f8514010000 jne ntdll!RtlFindMessage+0x359 (77f51c30) [br=1]
3: kd> r
eax=001751b0 ebx=00000000 ecx=70be5b5e edx=00000000 esi=00000001 edi=00000000
eip=77f51b16 esp=0006e8cc ebp=0006e954 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!RtlFindMessage+0x23f:
001b:77f51b16 0f8514010000 jne ntdll!RtlFindMessage+0x359 (77f51c30) [br=1]
3: kd> ~1s
1: kd> r
eax=f772f13c ebx=0000008e ecx=855dd020 edx=804e9fa0 esi=f772f120 edi=00000000
eip=805435b9 esp=ec25179c ebp=ec2517b4 iopl=0 nv up ei ng nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286
nt!KeBugCheckEx+0x19:
805435b9 5d pop ebp
1: kd> u 001b:77f51b16 - 20
ntdll!RtlFindMessage+0x21f:
001b:77f51af6 5f pop edi
001b:77f51af7 5e pop esi
001b:77f51af8 5b pop ebx
001b:77f51af9 c9 leave
001b:77f51afa c22000 ret 0x20
001b:77f51afd 1bc9 sbb ecx,ecx
001b:77f51aff 83d9ff sbb ecx,0xffffffff
001b:77f51b02 eba0 jmp ntdll!RtlFindMessage+0x1cd (77f51aa4)
1: kd> u
ntdll!RtlFindMessage+0x22d:
001b:77f51b04 a1c023fc77 mov eax,[ntdll!NlsMbOemCodePageTag+0x3b0 (77fc23c0)]
001b:77f51b09 8945c8 mov [ebp-0x38],eax
001b:77f51b0c 83c0f0 add eax,0xfffffff0
001b:77f51b0f 8945c4 mov [ebp-0x3c],eax
001b:77f51b12 f6403540 test byte ptr [eax+0x35],0x40
001b:77f51b16 0f8514010000 jne ntdll!RtlFindMessage+0x359 (77f51c30)
001b:77f51b1c 8975fc mov [ebp-0x4],esi
001b:77f51b1f 6a00 push 0x0
1: kd> dd 001751b0 + 35
001751e5 02000c40 94000000 44001752 a3001751
001751f5 003e8024 00000000 0a000000 61000b00
00175205 43000e01 5c003a00 49005700 44004e00
00175215 57004f00 5c005300 79007300 74007300
00175225 6d006500 32003300 57005c00 6e006900
00175235 43005300 72006100 2e006400 6c006400
00175245 00006c00 00000000 0b000000 6b000a00
00175255 f0000801 b0001752 f8001751 b8001752

At 04:30 PM 11/8/2003 -0800, you wrote:
>W2K doesn’t support HT as well as it could, but the code works.
>
>I don’t immediately see this problem as an HT problem, but I’m not sure
>exactly what it is. I would have liked to see the instruction before the
>failing instruction, but I didn’t see that in your dump info.
>
>Are these HT machines somrthing standard like Dell boxes? Or are you
>running some prototype Intel chip? I doubt that you are, but I very vaguely
>remember that very early chip revisions (that you probably would never have
>seen) had some interesting errata.
>
> Loren
>
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@opferman.com
>To unsubscribe send a blank email to xxxxx@lists.osr.com

Loren_Wilton · November 8, 2003, 8:24pm

1: kd> u
win32k+0xe59ae:
bf8e59ae 6a0d push 0xd
bf8e59b0 ffb6ac000000 push dword ptr [esi+0xac]
bf8e59b6 ff15a06198bf call dword ptr [win32k+0x1861a0 (bf9861a0)]
bf8e59bc 8945e0 mov [ebp-0x20],eax <– TRAP

Interesting. You probably just returned from a procedure call, from the looks of it into another DLL.

I have something very vague scratching at the back of my memory that I remember seeing this sort of occurance once, but I’m darned if I can remember the circumstances. Something about doing the return with some strange machine or register state would actually fail on the return, but the address was already pointing at the return address by the time the trap was taken. I can’t for the life of me remember if this had anythinng to do with HT or not. Maybe it did, maybe it didn’t.

Loren

OSR_Community_User · November 9, 2003, 12:14am

Yes, that function is KeWaitForSingleObject. The other traps, however,
have not done any return, one trapped on DEC ESP. I found something
interesting with that dump now though.

0: kd> dds esp - 40
ed136e74 00000023
ed136e78 00000023
ed136e7c 80010031
ed136e80 00000000
ed136e84 80fba001
ed136e88 804f7e46 nt!ExAcquireResourceExclusiveLite+0x8b <– Perhaps this
happened
ed136e8c ed136f74
ed136e90 00000030
ed136e94 ed136eec
ed136e98 81b907b8
ed136e9c bc01ee90
ed136ea0 ed136eec
ed136ea4 00000002
ed136ea8 bf8e505f win32k+0xe505f <– EIP
ed136eac 00000008 <– 4
ed136eb0 00010206 <– 8
ed136eb4 ed136f20 <– Current ESP
ed136eb8 bf8fff12 win32k+0xfff12

0: kd> u 804f7e46
nt!ExAcquireResourceExclusiveLite+0x8b:
804f7e46 64a124010000 mov eax,fs:[00000124]
804f7e4c 894618 mov [esi+0x18],eax
804f7e4f b001 mov al,0x1
804f7e51 e99362ffff jmp nt!ExAcquireResourceExclusiveLite+0x66 (804ee0e9)
804f7e56 8908 mov [eax],ecx
804f7e58 e9c5baffff jmp nt!KeSetEventBoostPriority+0x7d (804f3922)
804f7e5d c6417b00 mov byte ptr [ecx+0x7b],0x0
804f7e61 8d8190000000 lea eax,[ecx+0x90]
0: kd> u 804ee0e9
nt!ExAcquireResourceExclusiveLite+0x66:
804ee0e9 5f pop edi
804ee0ea 5e pop esi
804ee0eb 5b pop ebx
804ee0ec c9 leave
804ee0ed c20800 ret 0x8 <– then this

0: kd> r
Last set context:
eax=80fba001 ebx=bc01ee90 ecx=00000000 edx=80010031 esi=81b907b8 edi=ed136eec
eip=bf8e505f esp=ed136eb4 ebp=ed136eec iopl=0 nv up ei pl nz na po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
win32k+0xe505f:
bf8e505f 4c dec esp <– to here, the trap.

Since it went to address bf8e505f and there are 8 bytes between the stack,
it was most likely a RET 8 (if this is from a RET and not a JMP/J* type
instruction to get here).

The interesting thing is that there is no call before this instruction and
infact, this could be a different instruction.

win32k+0xe505f:
bf8e505f 4c dec esp
bf8e5060 2404 and al,0x4
bf8e5062 668b4104 mov ax,[ecx+0x4] <– would trap anyway, ECX
is 0.
bf8e5066 ff4114 inc dword ptr [ecx+0x14]
bf8e5069 663b4108 cmp ax,[ecx+0x8]
bf8e506d 730d jnb win32k+0xe507c (bf8e507c)
bf8e506f 8b542408 mov edx,[esp+0x8]
bf8e5073 ff15786198bf call dword ptr [win32k+0x186178 (bf986178)]
0: kd> u poi bf986178
nt!InterlockedPushEntrySList:

But, if you unassemble back, it’s almost as if the stack got incremented to
the wrong address:

0: kd> u eip - 20
win32k+0xe505d:
bf8e505d 90 nop
bf8e505e 8b4c2404 mov ecx,[esp+0x4]
bf8e5062 668b4104 mov ax,[ecx+0x4]
bf8e5066 ff4114 inc dword ptr [ecx+0x14]
bf8e5069 663b4108 cmp ax,[ecx+0x8]
bf8e506d 730d jnb win32k+0xe507c (bf8e507c)
bf8e506f 8b542408 mov edx,[esp+0x8]
bf8e5073 ff15786198bf call dword ptr [win32k+0x186178 (bf986178)]

Perhaps it is because the instruction isn’t on some boundry that it trapped
or this code address isn’t execute priv and it’s all invalid even though it
looks valid, doubtful though and probably could check that easily.

0: kd> dd esp + 4
ed136eb8 bf8fff12

0: kd> dw bf8fff12 + 4
bf8fff16 bf98

This would give ecx a valid address, it’s off by 1 byte to align the
instruction to populate ECX. I don’t know how the return address got to be
here as there’s no call before it, but it’s on the stack as if it was a
return address (unless it really was just a jmp here and that’s just
coquincidence it’s there).

So, though it’s a valid instruction perhaps it’s the address bf8e505f is
not aligned, even though the x86 has variable instruction lengths and all
that this should do is cause a pre-fetch delay I guess, I don’t remember
those details anymore.

Anyone have symbols for Window 2003 win32k.sys?

At 05:23 PM 11/8/2003 -0800, you wrote:

1: kd> u
win32k+0xe59ae:
bf8e59ae 6a0d push 0xd
bf8e59b0 ffb6ac000000 push dword ptr [esi+0xac]
bf8e59b6 ff15a06198bf call dword ptr [win32k+0x1861a0 (bf9861a0)]
bf8e59bc 8945e0 mov [ebp-0x20],eax <– TRAP

Interesting. You probably just returned from a procedure call, from the
looks of it into another DLL.

I have something very vague scratching at the back of my memory that I
remember seeing this sort of occurance once, but I’m darned if I can
remember the circumstances. Something about doing the return with some
strange machine or register state would actually fail on the return, but
the address was already pointing at the return address by the time the
trap was taken. I can’t for the life of me remember if this had anythinng
to do with HT or not. Maybe it did, maybe it didn’t.

Loren

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

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

OSR_Community_User · November 9, 2003, 12:19am

The NOPs are very strange as well, but perhaps someone is supposed to JMP
there, or something attempted to remove code, theres 5

bf8e5050 56 push esi
bf8e5051 ff15886098bf call dword ptr [win32k+0x186088 (bf986088)]
bf8e5057 5e pop esi
bf8e5058 c3 ret
bf8e5059 90 nop
bf8e505a 90 nop
bf8e505b 90 nop
bf8e505c 90 nop
0: kd>
win32k+0xe505d:
bf8e505d 90 nop
bf8e505e 8b4c2404 mov ecx,[esp+0x4]

There’s the call to nt!ExAcquireResourceExclusiveLite. At least one of the
dumps is looking more suspicious, still not sure what could cause the
processor to trap on a valid instruction even if the rest is invalid but
perhaps that’s not what I should focus on anymore with this particular
dump, maybe if I search some more I can find something simmilar with the
other one I showed.

At 05:23 PM 11/8/2003 -0800, you wrote:

1: kd> u
win32k+0xe59ae:
bf8e59ae 6a0d push 0xd
bf8e59b0 ffb6ac000000 push dword ptr [esi+0xac]
bf8e59b6 ff15a06198bf call dword ptr [win32k+0x1861a0 (bf9861a0)]
bf8e59bc 8945e0 mov [ebp-0x20],eax <– TRAP

Interesting. You probably just returned from a procedure call, from the
looks of it into another DLL.

I have something very vague scratching at the back of my memory that I
remember seeing this sort of occurance once, but I’m darned if I can
remember the circumstances. Something about doing the return with some
strange machine or register state would actually fail on the return, but
the address was already pointing at the return address by the time the
trap was taken. I can’t for the life of me remember if this had anythinng
to do with HT or not. Maybe it did, maybe it didn’t.

Loren

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

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

Loren_Wilton · November 9, 2003, 1:34am

Nops following a ret is almost always the sign of either cache line sync
filler or perhaps local data declared between procedures. Usually the cache
line sync filler would be nops up to a 16 byte boundry. This curiously
stops 2 bytes before that. Possibly this indicates a 2 byte variable before
a procedure starting at bf8e5060?

Loren

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, November 08, 2003 9:18 PM
Subject: [ntdev] Re: Strange Traps?

> The NOPs are very strange as well, but perhaps someone is supposed to JMP
> there, or something attempted to remove code, theres 5
>
>
> bf8e5050 56 push esi
> bf8e5051 ff15886098bf call dword ptr [win32k+0x186088 (bf986088)]
> bf8e5057 5e pop esi
> bf8e5058 c3 ret
> bf8e5059 90 nop
> bf8e505a 90 nop
> bf8e505b 90 nop
> bf8e505c 90 nop
> 0: kd>
> win32k+0xe505d:
> bf8e505d 90 nop
> bf8e505e 8b4c2404 mov ecx,[esp+0x4]
>