Prev: Unable to add USB printer through command line
Next: CreateProcessAsUser and delete ACL
From: Dirk Zabel on 29 May 2007 06:18
Hi,
on a Windows 2000 machine I had cooparating programs running (one is
communicating with an external device via the rs232 port and exchanges data
with the other using udp/ip). The computer was running for some weeks without
problems, but now a blue screen occured. I had configured it to generate a
full memory dump in such case. When analyzing the dump using windbg, I see
this:
kd> !analyze -v
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
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.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: a000266b, The address that the exception occurred at
Arg3: 00000001, Parameter 0 of the exception
Arg4: 6bb0160c, Parameter 1 of the exception

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx" verweist
auf Speicher in "0x%08lx". Der Vorgang "%s" konnte nicht auf dem Speicher
durchgef hrt werden.

FAULTING_IP:
win32k!LeaveCrit+4
a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 6bb0160c

WRITE_ADDRESS: 6bb0160c

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x1E

PROCESS_NAME: csrss.exe

EXCEPTION_RECORD: bfd6fa78 -- (.exr ffffffffbfd6fa78)
ExceptionAddress: a000266b (win32k!LeaveCrit+0x00000004)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 6bb0160c
Attempt to write to address 6bb0160c

CONTEXT: bfd6f6d0 -- (.cxr ffffffffbfd6f6d0)
eax=0000000d ebx=00000008 ecx=ffffffff edx=00000000 esi=00000000 edi=00000014
eip=a000266b esp=bfd6fb40 ebp=bfd6fb5c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!LeaveCrit+0x4:
a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
ds:0023:6bb0160c=??
Resetting default scope

LAST_CONTROL_TRANSFER: from a00029fd to a000266b

MISALIGNED_IP:
win32k!LeaveCrit+4
a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah

STACK_TEXT:
bfd6fb3c a00029fd 80400bc6 00000001 00000000 win32k!LeaveCrit+0x4
bfd6fb5c a00ad527 00000000 00000000 00000000 win32k!TimersProc+0x133
bfd6fda8 80455a16 00000002 00000000 00000000 win32k!RawInputThread+0x4bd
bfd6fddc 80469bb2 a00ad1aa f718f7d0 00000000 nt!PspSystemThreadStartup+0x69
00000000 f000ef6f f000e2c3 f000ef6f f000ef6f nt!KiThreadStartup+0x16
WARNING: Frame IP not in any known module. Following frames may be wrong.
00000000 00000000 f000e2c3 f000ef6f f000ef6f 0xf000ef6f


FOLLOWUP_IP:
win32k!LeaveCrit+4
a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: win32k!LeaveCrit+4

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

STACK_COMMAND: .cxr 0xffffffffbfd6f6d0 ; kb

MODULE_NAME: hardware

FAILURE_BUCKET_ID: IP_MISALIGNED

BUCKET_ID: IP_MISALIGNED

Followup: MachineOwner
---------

Now, what can I learn from this? What does this
MISALIGNED_IP:
mean here? And what about:
IMAGE_NAME: hardware

Any help would be welcome.

Yours
Dirk





As far as I know, my programs cannot be responsible for any blue screen, as
they are running on ring 3 (user mode). So I expected some driver to be
listet in the dump. But
From: annav on 29 May 2007 12:54
It looks like a kernel call failed to address some variable in address
space of your process (address 0x6bb0160c) . Since this kernel
function is LeaveCrit, I suppose that an user-space synchronization
object couldn't be accessed. So you've corrupted some data critical
for low-level process management. This may be caused by memory leaks
\invalid pointers in your application



From: Ivan Brugiolo [MSFT] on 29 May 2007 13:04
The instruction being executed `18 a0 ff 15 b0 6b` looks suspicious.
Can you compare the code stream with a known good binary ?
I'd supect some form of code corruption, one example of which
(that I debugged recently from a crashdump) is reported below.
The code you are crashing at is know to not take external input,
and, to have been resonably stable,

//----------------------------- begin example debugging

Location of the context record

0:001> dc 0033f868-1c
0033f84c c0000005 00000000 00000000 715e1648 ............H.^q
0033f85c 00000002 00000001 00000000 0001003f ............?...
0033f86c 00000000 00000000 00000000 00000000 ................
0033f87c 00000000 00000000 ffff027f ffff0130 ............0...
0033f88c ffffffff 71204855 0118001b 0044c3ac ....UH q......D.
0033f89c ffff0023 00000000 80000000 00003fff #............?..
0033f8ac 00000000 00000000 00000000 b8956d00 .............m..
0033f8bc 00003ffc 00000000 40028000 00000000 .?.........@....

Exception record

0:001> .exr 0033f84c
ExceptionAddress: 715e1648
(dwmredir!DwmProcessKernelOnlyAsyncMessage+0x00000029)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000000
Attempt to write to address 00000000

registers saved at the crash site.
Notice the @eip register, and compare with the code-stream

0:001> .cxr 0033f868
eax=00000000 ebx=40000004 ecx=00393e10 edx=80070018 esi=00393e28
edi=80004001
eip=715e1648 esp=0033fb34 ebp=0033fb58 iopl=0 nv up ei pl nz na po
nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
efl=00010202
dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29:
715e1648 1100 adc dword ptr [eax],eax
ds:0023:00000000=????????

stack trace

0:001> k
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr
0033fb3c 715e15ed dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29
0033fb58 005e1801 dwmredir!DwmRedirectionManagerDispatchMessage+0x74
0033fb6c 005e17ca dwm!CRedirectionState::DispatchMilMessage+0x1b
0033fb8c 005e1558 dwm!CRedirectionState::ProcessCommand+0x276
0033fbb4 005e1738 dwm!CSessionPort::ProcessCommand+0xfb
0033fbd4 005e16a0 dwm!CPortBase::InternalProcessCommand+0x56
0033fbf0 005e1647 dwm!CPortBase::RoutePacket+0x52
0033fc1c 005e53bd dwm!CPortBase::PortThreadInternal+0xa9
0033fc28 773f3833 dwm!CPortBase::PortThread+0xe
0033fc34 77ada9bd kernel32!BaseThreadInitThunk+0xe
0033fc74 00000000 ntdll!_RtlUserThreadStart+0x23

unassemble code from a trusted source binary

0:001> u dwmredir!DwmProcessKernelOnlyAsyncMessage 715e164c
dwmredir!DwmProcessKernelOnlyAsyncMessage:
715e1628 f60508315f7101 test byte ptr [dwmredir!$S2 (715f3108)],1
715e162f 53 push ebx
715e1630 56 push esi
715e1631 57 push edi
715e1632 bf01400080 mov edi,80004001h
715e1637 ba18000780 mov edx,80070018h
715e163c 0f844e5f0000 je
dwmredir!DwmProcessKernelOnlyAsyncMessage+0x16 (715e7590)
715e1642 8d7118 lea esi,[ecx+18h]
715e1645 8b1e mov ebx,dword ptr [esi]
715e1647 b811000040 mov eax,40000011h <<<<<<< instruction
stream start 1 byte later
0:001>


/// moving the instruction pointer a little bit down, we have the actual
fault

0:001> u 715e1648
dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29:
715e1648 1100 adc dword ptr [eax],eax
715e164a 00403b add byte ptr [eax+3Bh],al
715e164d d80f fmul dword ptr [edi]
715e164f 8600 xchg al,byte ptr [eax]
715e1651 0400 add al,0
715e1653 00b83b000040 add byte ptr [eax+4000003Bh],bh
715e1659 3bd8 cmp ebx,eax
715e165b 0f877e090000 ja
dwmredir!DwmProcessKernelOnlyAsyncMessage+0x2bb (715e1fdf)

This can be explained by a single bit error in the opcode that changes it
from `b8` to `98`
Let's simulate that, bu recreating the code pattern that would have existed
at address 715e1647.
Change `715e1647 : b8 11 00 00 40 ` to `715e1647 : 98 11 00 00 40`

0:001> eb 0033fa54 98 11 00 00 40; u 0033fa54
0033fa54 98 cwde
0033fa55 1100 adc dword ptr [eax],eax
0033fa57 004000 add byte ptr [eax],al
0033fa5a 0000 add byte ptr [eax],al
0033fa5c 0000 add byte ptr [eax],al
0033fa5e 0000 add byte ptr [eax],al
0033fa60 0000 add byte ptr [eax],al
0033fa62 0000 add byte ptr [eax],al

here is the changed bit

0:001> ?000011b8^00001198
Evaluate expression: 32 = 00000020

the `cwde` prefix applied to the next instruction (it works like a nop in
this case),
and, the next instruction is `randomly` fetched from the byte stream in
memory.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Dirk Zabel" <dzabel(a)community.nospam> wrote in message
news:BCBED70E-F1C4-455F-BBE9-F742A77AEC9A(a)microsoft.com...
> Hi,
> on a Windows 2000 machine I had cooparating programs running (one is
> communicating with an external device via the rs232 port and exchanges
> data
> with the other using udp/ip). The computer was running for some weeks
> without
> problems, but now a blue screen occured. I had configured it to generate a
> full memory dump in such case. When analyzing the dump using windbg, I see
> this:
> kd> !analyze -v
> *******************************************************************************
> *
> *
> * Bugcheck Analysis
> *
> *
> *
> *******************************************************************************
>
> KMODE_EXCEPTION_NOT_HANDLED (1e)
> 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.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: a000266b, The address that the exception occurred at
> Arg3: 00000001, Parameter 0 of the exception
> Arg4: 6bb0160c, Parameter 1 of the exception
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx"
> verweist
> auf Speicher in "0x%08lx". Der Vorgang "%s" konnte nicht auf dem Speicher
> durchgef hrt werden.
>
> FAULTING_IP:
> win32k!LeaveCrit+4
> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>
> EXCEPTION_PARAMETER1: 00000001
>
> EXCEPTION_PARAMETER2: 6bb0160c
>
> WRITE_ADDRESS: 6bb0160c
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0x1E
>
> PROCESS_NAME: csrss.exe
>
> EXCEPTION_RECORD: bfd6fa78 -- (.exr ffffffffbfd6fa78)
> ExceptionAddress: a000266b (win32k!LeaveCrit+0x00000004)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000001
> Parameter[1]: 6bb0160c
> Attempt to write to address 6bb0160c
>
> CONTEXT: bfd6f6d0 -- (.cxr ffffffffbfd6f6d0)
> eax=0000000d ebx=00000008 ecx=ffffffff edx=00000000 esi=00000000
> edi=00000014
> eip=a000266b esp=bfd6fb40 ebp=bfd6fb5c iopl=0 nv up ei pl zr na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00010246
> win32k!LeaveCrit+0x4:
> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
> ds:0023:6bb0160c=??
> Resetting default scope
>
> LAST_CONTROL_TRANSFER: from a00029fd to a000266b
>
> MISALIGNED_IP:
> win32k!LeaveCrit+4
> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>
> STACK_TEXT:
> bfd6fb3c a00029fd 80400bc6 00000001 00000000 win32k!LeaveCrit+0x4
> bfd6fb5c a00ad527 00000000 00000000 00000000 win32k!TimersProc+0x133
> bfd6fda8 80455a16 00000002 00000000 00000000 win32k!RawInputThread+0x4bd
> bfd6fddc 80469bb2 a00ad1aa f718f7d0 00000000
> nt!PspSystemThreadStartup+0x69
> 00000000 f000ef6f f000e2c3 f000ef6f f000ef6f nt!KiThreadStartup+0x16
> WARNING: Frame IP not in any known module. Following frames may be wrong.
> 00000000 00000000 f000e2c3 f000ef6f f000ef6f 0xf000ef6f
>
>
> FOLLOWUP_IP:
> win32k!LeaveCrit+4
> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>
> SYMBOL_STACK_INDEX: 0
>
> SYMBOL_NAME: win32k!LeaveCrit+4
>
> FOLLOWUP_NAME: MachineOwner
>
> IMAGE_NAME: hardware
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> STACK_COMMAND: .cxr 0xffffffffbfd6f6d0 ; kb
>
> MODULE_NAME: hardware
>
> FAILURE_BUCKET_ID: IP_MISALIGNED
>
> BUCKET_ID: IP_MISALIGNED
>
> Followup: MachineOwner
> ---------
>
> Now, what can I learn from this? What does this
> MISALIGNED_IP:
> mean here? And what about:
> IMAGE_NAME: hardware
>
> Any help would be welcome.
>
> Yours
> Dirk
>
>
>
>
>
> As far as I know, my programs cannot be responsible for any blue screen,
> as
> they are running on ring 3 (user mode). So I expected some driver to be
> listet in the dump. But


From: Jeffrey Walton on 29 May 2007 15:55
Hi Dirk,

Perhaps the following can assist in the code corruption... It allows
one to add instumentation to detect and correct .text section
modifications.

Jeff

http://www.codeproject.com/useritems/SelfHealing.asp

On May 29, 1:04 pm, "Ivan Brugiolo [MSFT]"
<ivanb...(a)online.microsoft.com> wrote:
> The instruction being executed `18 a0 ff 15 b0 6b` looks suspicious.
> Can you compare the code stream with a known good binary ?
> I'd supect some form of code corruption, one example of which
> (that I debugged recently from a crashdump) is reported below.
> The code you are crashing at is know to not take external input,
> and, to have been resonably stable,
>
> //----------------------------- begin example debugging
>
> Location of the context record
>
> 0:001> dc 0033f868-1c
> 0033f84c c0000005 00000000 00000000 715e1648 ............H.^q
> 0033f85c 00000002 00000001 00000000 0001003f ............?...
> 0033f86c 00000000 00000000 00000000 00000000 ................
> 0033f87c 00000000 00000000 ffff027f ffff0130 ............0...
> 0033f88c ffffffff 71204855 0118001b 0044c3ac ....UH q......D.
> 0033f89c ffff0023 00000000 80000000 00003fff #............?..
> 0033f8ac 00000000 00000000 00000000 b8956d00 .............m..
> 0033f8bc 00003ffc 00000000 40028000 00000000 .?.........@....
>
> Exception record
>
> 0:001> .exr 0033f84c
> ExceptionAddress: 715e1648
> (dwmredir!DwmProcessKernelOnlyAsyncMessage+0x00000029)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000001
> Parameter[1]: 00000000
> Attempt to write to address 00000000
>
> registers saved at the crash site.
> Notice the @eip register, and compare with the code-stream
>
> 0:001> .cxr 0033f868
> eax=00000000 ebx=40000004 ecx=00393e10 edx=80070018 esi=00393e28
> edi=80004001
> eip=715e1648 esp=0033fb34 ebp=0033fb58 iopl=0 nv up ei pl nz na po
> nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000
> efl=00010202
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29:
> 715e1648 1100 adc dword ptr [eax],eax
> ds:0023:00000000=????????
>
> stack trace
>
> 0:001> k
> *** Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr
> 0033fb3c 715e15ed dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29
> 0033fb58 005e1801 dwmredir!DwmRedirectionManagerDispatchMessage+0x74
> 0033fb6c 005e17ca dwm!CRedirectionState::DispatchMilMessage+0x1b
> 0033fb8c 005e1558 dwm!CRedirectionState::ProcessCommand+0x276
> 0033fbb4 005e1738 dwm!CSessionPort::ProcessCommand+0xfb
> 0033fbd4 005e16a0 dwm!CPortBase::InternalProcessCommand+0x56
> 0033fbf0 005e1647 dwm!CPortBase::RoutePacket+0x52
> 0033fc1c 005e53bd dwm!CPortBase::PortThreadInternal+0xa9
> 0033fc28 773f3833 dwm!CPortBase::PortThread+0xe
> 0033fc34 77ada9bd kernel32!BaseThreadInitThunk+0xe
> 0033fc74 00000000 ntdll!_RtlUserThreadStart+0x23
>
> unassemble code from a trusted source binary
>
> 0:001> u dwmredir!DwmProcessKernelOnlyAsyncMessage 715e164c
> dwmredir!DwmProcessKernelOnlyAsyncMessage:
> 715e1628 f60508315f7101 test byte ptr [dwmredir!$S2 (715f3108)],1
> 715e162f 53 push ebx
> 715e1630 56 push esi
> 715e1631 57 push edi
> 715e1632 bf01400080 mov edi,80004001h
> 715e1637 ba18000780 mov edx,80070018h
> 715e163c 0f844e5f0000 je
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x16 (715e7590)
> 715e1642 8d7118 lea esi,[ecx+18h]
> 715e1645 8b1e mov ebx,dword ptr [esi]
> 715e1647 b811000040 mov eax,40000011h <<<<<<< instruction
> stream start 1 byte later
> 0:001>
>
> /// moving the instruction pointer a little bit down, we have the actual
> fault
>
> 0:001> u 715e1648
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29:
> 715e1648 1100 adc dword ptr [eax],eax
> 715e164a 00403b add byte ptr [eax+3Bh],al
> 715e164d d80f fmul dword ptr [edi]
> 715e164f 8600 xchg al,byte ptr [eax]
> 715e1651 0400 add al,0
> 715e1653 00b83b000040 add byte ptr [eax+4000003Bh],bh
> 715e1659 3bd8 cmp ebx,eax
> 715e165b 0f877e090000 ja
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x2bb (715e1fdf)
>
> This can be explained by a single bit error in the opcode that changes it
> from `b8` to `98`
> Let's simulate that, bu recreating the code pattern that would have existed
> at address 715e1647.
> Change `715e1647 : b8 11 00 00 40 ` to `715e1647 : 98 11 00 00 40`
>
> 0:001> eb 0033fa54 98 11 00 00 40; u 0033fa54
> 0033fa54 98 cwde
> 0033fa55 1100 adc dword ptr [eax],eax
> 0033fa57 004000 add byte ptr [eax],al
> 0033fa5a 0000 add byte ptr [eax],al
> 0033fa5c 0000 add byte ptr [eax],al
> 0033fa5e 0000 add byte ptr [eax],al
> 0033fa60 0000 add byte ptr [eax],al
> 0033fa62 0000 add byte ptr [eax],al
>
> here is the changed bit
>
> 0:001> ?000011b8^00001198
> Evaluate expression: 32 = 00000020
>
> the `cwde` prefix applied to the next instruction (it works like a nop in
> this case),
> and, the next instruction is `randomly` fetched from the byte stream in
> memory.
>
> --
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of any included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
>
> "Dirk Zabel" <dza...(a)community.nospam> wrote in message
>
> news:BCBED70E-F1C4-455F-BBE9-F742A77AEC9A(a)microsoft.com...
>
>
>
> > Hi,
> > on a Windows 2000 machine I had cooparating programs running (one is
> > communicating with an external device via the rs232 port and exchanges
> > data
> > with the other using udp/ip). The computer was running for some weeks
> > without
> > problems, but now a blue screen occured. I had configured it to generate a
> > full memory dump in such case. When analyzing the dump using windbg, I see
> > this:
> > kd> !analyze -v
> > ***************************************************************************­****
> > *
> > *
> > * Bugcheck Analysis
> > *
> > *
> > *
> > ***************************************************************************­****
>
> > KMODE_EXCEPTION_NOT_HANDLED (1e)
> > 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.
> > Arguments:
> > Arg1: c0000005, The exception code that was not handled
> > Arg2: a000266b, The address that the exception occurred at
> > Arg3: 00000001, Parameter 0 of the exception
> > Arg4: 6bb0160c, Parameter 1 of the exception
>
> > Debugging Details:
> > ------------------
>
> > EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx"
> > verweist
> > auf Speicher in "0x%08lx". Der Vorgang "%s" konnte nicht auf dem Speicher
> > durchgef hrt werden.
>
> > FAULTING_IP:
> > win32k!LeaveCrit+4
> > a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>
> > EXCEPTION_PARAMETER1: 00000001
>
> > EXCEPTION_PARAMETER2: 6bb0160c
>
> > WRITE_ADDRESS: 6bb0160c
>
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> > BUGCHECK_STR: 0x1E
>
> > PROCESS_NAME: csrss.exe
>
> > EXCEPTION_RECORD: bfd6fa78 -- (.exr ffffffffbfd6fa78)
> > ExceptionAddress: a000266b (win32k!LeaveCrit+0x00000004)
> > ExceptionCode: c0000005 (Access violation)
> > ExceptionFlags: 00000000
> > NumberParameters: 2
> > Parameter[0]: 00000001
> > Parameter[1]: 6bb0160c
> > Attempt to write to address 6bb0160c
>
> > CONTEXT: bfd6f6d0 -- (.cxr ffffffffbfd6f6d0)
> > eax=0000000d ebx=00000008 ecx=ffffffff edx=00000000 esi=00000000
> > edi=00000014
> > eip=a000266b esp=bfd6fb40 ebp=bfd6fb5c iopl=0 nv up ei pl zr na pe
> > nc
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > efl=00010246
> > win32k!LeaveCrit+0x4:
> > a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
> > ds:0023:6bb0160c=??
> > Resetting default scope
>
> > LAST_CONTROL_TRANSFER: from a00029fd to a000266b
>
> > MISALIGNED_IP:
> > win32k!LeaveCrit+4
> > a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>
> > STACK_TEXT:
> > bfd6fb3c a00029fd 80400bc6 00000001 00000000 win32k!LeaveCrit+0x4
> > bfd6fb5c a00ad527 00000000 00000000 00000000 win32k!TimersProc+0x133
> > bfd6fda8 80455a16 00000002 00000000 00000000 win32k!RawInputThread+0x4bd
> > bfd6fddc 80469bb2 a00ad1aa f718f7d0 00000000
> > nt!PspSystemThreadStartup+0x69
> > 00000000 f000ef6f f000e2c3 f000ef6f f000ef6f nt!KiThreadStartup+0x16
> > WARNING: Frame IP not in any known module. Following frames may be wrong.
> > 00000000 00000000 f000e2c3 f000ef6f f000ef6f 0xf000ef6f
>
> > FOLLOWUP_IP:
> > win32k!LeaveCrit+4
> > a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>
> > SYMBOL_STACK_INDEX: 0
>
> > SYMBOL_NAME: win32k!LeaveCrit+4
>
> > FOLLOWUP_NAME: MachineOwner
>
> > IMAGE_NAME: hardware
>
> > DEBUG_FLR_IMAGE_TIMESTAMP: 0
>
> > STACK_COMMAND: .cxr 0xffffffffbfd6f6d0 ; kb
>
> > MODULE_NAME: hardware
>
> > FAILURE_BUCKET_ID: IP_MISALIGNED
>
> > BUCKET_ID: IP_MISALIGNED
>
> > Followup: MachineOwner
> > ---------
>
> > Now, what can I learn from this? What does this
> > MISALIGNED_IP:
> > mean here? And what about:
> > IMAGE_NAME: hardware
>
> > Any help would be welcome.
>
> > Yours
> > Dirk
>
> > As far as I know, my programs cannot be responsible for any blue screen,
> > as
> > they are running on ring 3 (user mode). So I expected some driver to be
> > listet in the dump. But- Hide quoted text -
>
> - Show quoted text -


From: Alexander Grigoriev on 29 May 2007 23:52
If a single byte is corrupted, it looks like memory fault. The OP needs to
run memory diagnostics.

I dare to suggest my test from
http://home.earthlink.net/~alegr/download/memtest.htm


"Ivan Brugiolo [MSFT]" <ivanbrug(a)online.microsoft.com> wrote in message
news:uNuwwNhoHHA.1240(a)TK2MSFTNGP04.phx.gbl...
> The instruction being executed `18 a0 ff 15 b0 6b` looks suspicious.
> Can you compare the code stream with a known good binary ?
> I'd supect some form of code corruption, one example of which
> (that I debugged recently from a crashdump) is reported below.
> The code you are crashing at is know to not take external input,
> and, to have been resonably stable,
>
> //----------------------------- begin example debugging
>
> Location of the context record
>
> 0:001> dc 0033f868-1c
> 0033f84c c0000005 00000000 00000000 715e1648 ............H.^q
> 0033f85c 00000002 00000001 00000000 0001003f ............?...
> 0033f86c 00000000 00000000 00000000 00000000 ................
> 0033f87c 00000000 00000000 ffff027f ffff0130 ............0...
> 0033f88c ffffffff 71204855 0118001b 0044c3ac ....UH q......D.
> 0033f89c ffff0023 00000000 80000000 00003fff #............?..
> 0033f8ac 00000000 00000000 00000000 b8956d00 .............m..
> 0033f8bc 00003ffc 00000000 40028000 00000000 .?.........@....
>
> Exception record
>
> 0:001> .exr 0033f84c
> ExceptionAddress: 715e1648
> (dwmredir!DwmProcessKernelOnlyAsyncMessage+0x00000029)
> ExceptionCode: c0000005 (Access violation)
> ExceptionFlags: 00000000
> NumberParameters: 2
> Parameter[0]: 00000001
> Parameter[1]: 00000000
> Attempt to write to address 00000000
>
> registers saved at the crash site.
> Notice the @eip register, and compare with the code-stream
>
> 0:001> .cxr 0033f868
> eax=00000000 ebx=40000004 ecx=00393e10 edx=80070018 esi=00393e28
> edi=80004001
> eip=715e1648 esp=0033fb34 ebp=0033fb58 iopl=0 nv up ei pl nz na po
> nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29:
> 715e1648 1100 adc dword ptr [eax],eax
> ds:0023:00000000=????????
>
> stack trace
>
> 0:001> k
> *** Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr
> 0033fb3c 715e15ed dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29
> 0033fb58 005e1801 dwmredir!DwmRedirectionManagerDispatchMessage+0x74
> 0033fb6c 005e17ca dwm!CRedirectionState::DispatchMilMessage+0x1b
> 0033fb8c 005e1558 dwm!CRedirectionState::ProcessCommand+0x276
> 0033fbb4 005e1738 dwm!CSessionPort::ProcessCommand+0xfb
> 0033fbd4 005e16a0 dwm!CPortBase::InternalProcessCommand+0x56
> 0033fbf0 005e1647 dwm!CPortBase::RoutePacket+0x52
> 0033fc1c 005e53bd dwm!CPortBase::PortThreadInternal+0xa9
> 0033fc28 773f3833 dwm!CPortBase::PortThread+0xe
> 0033fc34 77ada9bd kernel32!BaseThreadInitThunk+0xe
> 0033fc74 00000000 ntdll!_RtlUserThreadStart+0x23
>
> unassemble code from a trusted source binary
>
> 0:001> u dwmredir!DwmProcessKernelOnlyAsyncMessage 715e164c
> dwmredir!DwmProcessKernelOnlyAsyncMessage:
> 715e1628 f60508315f7101 test byte ptr [dwmredir!$S2 (715f3108)],1
> 715e162f 53 push ebx
> 715e1630 56 push esi
> 715e1631 57 push edi
> 715e1632 bf01400080 mov edi,80004001h
> 715e1637 ba18000780 mov edx,80070018h
> 715e163c 0f844e5f0000 je dwmredir!DwmProcessKernelOnlyAsyncMessage+0x16
> (715e7590)
> 715e1642 8d7118 lea esi,[ecx+18h]
> 715e1645 8b1e mov ebx,dword ptr [esi]
> 715e1647 b811000040 mov eax,40000011h <<<<<<< instruction
> stream start 1 byte later
> 0:001>
>
>
> /// moving the instruction pointer a little bit down, we have the actual
> fault
>
> 0:001> u 715e1648
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x29:
> 715e1648 1100 adc dword ptr [eax],eax
> 715e164a 00403b add byte ptr [eax+3Bh],al
> 715e164d d80f fmul dword ptr [edi]
> 715e164f 8600 xchg al,byte ptr [eax]
> 715e1651 0400 add al,0
> 715e1653 00b83b000040 add byte ptr [eax+4000003Bh],bh
> 715e1659 3bd8 cmp ebx,eax
> 715e165b 0f877e090000 ja
> dwmredir!DwmProcessKernelOnlyAsyncMessage+0x2bb (715e1fdf)
>
> This can be explained by a single bit error in the opcode that changes it
> from `b8` to `98`
> Let's simulate that, bu recreating the code pattern that would have
> existed at address 715e1647.
> Change `715e1647 : b8 11 00 00 40 ` to `715e1647 : 98 11 00 00 40`
>
> 0:001> eb 0033fa54 98 11 00 00 40; u 0033fa54
> 0033fa54 98 cwde
> 0033fa55 1100 adc dword ptr [eax],eax
> 0033fa57 004000 add byte ptr [eax],al
> 0033fa5a 0000 add byte ptr [eax],al
> 0033fa5c 0000 add byte ptr [eax],al
> 0033fa5e 0000 add byte ptr [eax],al
> 0033fa60 0000 add byte ptr [eax],al
> 0033fa62 0000 add byte ptr [eax],al
>
> here is the changed bit
>
> 0:001> ?000011b8^00001198
> Evaluate expression: 32 = 00000020
>
> the `cwde` prefix applied to the next instruction (it works like a nop in
> this case),
> and, the next instruction is `randomly` fetched from the byte stream in
> memory.
>
> --
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> Use of any included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Dirk Zabel" <dzabel(a)community.nospam> wrote in message
> news:BCBED70E-F1C4-455F-BBE9-F742A77AEC9A(a)microsoft.com...
>> Hi,
>> on a Windows 2000 machine I had cooparating programs running (one is
>> communicating with an external device via the rs232 port and exchanges
>> data
>> with the other using udp/ip). The computer was running for some weeks
>> without
>> problems, but now a blue screen occured. I had configured it to generate
>> a
>> full memory dump in such case. When analyzing the dump using windbg, I
>> see
>> this:
>> kd> !analyze -v
>> *******************************************************************************
>> *
>> *
>> * Bugcheck Analysis
>> *
>> *
>> *
>> *******************************************************************************
>>
>> KMODE_EXCEPTION_NOT_HANDLED (1e)
>> 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.
>> Arguments:
>> Arg1: c0000005, The exception code that was not handled
>> Arg2: a000266b, The address that the exception occurred at
>> Arg3: 00000001, Parameter 0 of the exception
>> Arg4: 6bb0160c, Parameter 1 of the exception
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in "0x%08lx"
>> verweist
>> auf Speicher in "0x%08lx". Der Vorgang "%s" konnte nicht auf dem
>> Speicher
>> durchgef hrt werden.
>>
>> FAULTING_IP:
>> win32k!LeaveCrit+4
>> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>>
>> EXCEPTION_PARAMETER1: 00000001
>>
>> EXCEPTION_PARAMETER2: 6bb0160c
>>
>> WRITE_ADDRESS: 6bb0160c
>>
>> DEFAULT_BUCKET_ID: DRIVER_FAULT
>>
>> BUGCHECK_STR: 0x1E
>>
>> PROCESS_NAME: csrss.exe
>>
>> EXCEPTION_RECORD: bfd6fa78 -- (.exr ffffffffbfd6fa78)
>> ExceptionAddress: a000266b (win32k!LeaveCrit+0x00000004)
>> ExceptionCode: c0000005 (Access violation)
>> ExceptionFlags: 00000000
>> NumberParameters: 2
>> Parameter[0]: 00000001
>> Parameter[1]: 6bb0160c
>> Attempt to write to address 6bb0160c
>>
>> CONTEXT: bfd6f6d0 -- (.cxr ffffffffbfd6f6d0)
>> eax=0000000d ebx=00000008 ecx=ffffffff edx=00000000 esi=00000000
>> edi=00000014
>> eip=a000266b esp=bfd6fb40 ebp=bfd6fb5c iopl=0 nv up ei pl zr na
>> pe nc
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
>> win32k!LeaveCrit+0x4:
>> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>> ds:0023:6bb0160c=??
>> Resetting default scope
>>
>> LAST_CONTROL_TRANSFER: from a00029fd to a000266b
>>
>> MISALIGNED_IP:
>> win32k!LeaveCrit+4
>> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>>
>> STACK_TEXT:
>> bfd6fb3c a00029fd 80400bc6 00000001 00000000 win32k!LeaveCrit+0x4
>> bfd6fb5c a00ad527 00000000 00000000 00000000 win32k!TimersProc+0x133
>> bfd6fda8 80455a16 00000002 00000000 00000000 win32k!RawInputThread+0x4bd
>> bfd6fddc 80469bb2 a00ad1aa f718f7d0 00000000
>> nt!PspSystemThreadStartup+0x69
>> 00000000 f000ef6f f000e2c3 f000ef6f f000ef6f nt!KiThreadStartup+0x16
>> WARNING: Frame IP not in any known module. Following frames may be wrong.
>> 00000000 00000000 f000e2c3 f000ef6f f000ef6f 0xf000ef6f
>>
>>
>> FOLLOWUP_IP:
>> win32k!LeaveCrit+4
>> a000266b 18a0ff15b06b sbb byte ptr [eax+6BB015FFh],ah
>>
>> SYMBOL_STACK_INDEX: 0
>>
>> SYMBOL_NAME: win32k!LeaveCrit+4
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> IMAGE_NAME: hardware
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 0
>>
>> STACK_COMMAND: .cxr 0xffffffffbfd6f6d0 ; kb
>>
>> MODULE_NAME: hardware
>>
>> FAILURE_BUCKET_ID: IP_MISALIGNED
>>
>> BUCKET_ID: IP_MISALIGNED
>>
>> Followup: MachineOwner
>> ---------
>>
>> Now, what can I learn from this? What does this
>> MISALIGNED_IP:
>> mean here? And what about:
>> IMAGE_NAME: hardware
>>
>> Any help would be welcome.
>>
>> Yours
>> Dirk
>>
>>
>>
>>
>>
>> As far as I know, my programs cannot be responsible for any blue screen,
>> as
>> they are running on ring 3 (user mode). So I expected some driver to be
>> listet in the dump. But
>
>


 |  Next  |  Last
Pages: 1 2
Prev: Unable to add USB printer through command line
Next: CreateProcessAsUser and delete ACL