Q149015: Kernel Debugging: "Parity Error: Bad Instruction Pointer"
Article: Q149015
Product(s): Microsoft Windows NT
Version(s): 3.5,3.51
Operating System(s):
Keyword(s):
Last Modified: 19-FEB-2002
-------------------------------------------------------------------------------
The information in this article applies to:
- Microsoft Windows NT Workstation versions 3.5, 3.51
- Microsoft Windows NT Server versions 3.5, 3.51
-------------------------------------------------------------------------------
SUMMARY
=======
This article describes a parity error that is caused by a bad processor cache or
by a faulty processor.
MORE INFORMATION
================
Article Contents:
- Stack Trace
- Trap Frame
- Unassemble of IoAllocateMdl function and EIP
- Parity Error
- Bad Instruction Pointer
- Breakdown of the instruction at 801144dd and Opcode
- Breakdown of the instruction at 801144dc and Opcode
Stack Trace:
The following is the stack trace from the failed system:
kv
ChildEBP RetAddr Args to Child
8014068c 801144dc ff067010 ff06705c 00000103
NT!_KiTrap0E+0x252 (FPO: [0,0] TrapFrame @ 8014068c)
80140710 fc903dc3 ff177358 00000002 00000000
NT!_IoAllocateMdl+0x44 (FPO: [EBP 0xff177358] [5,1,4])
80140738 fc93102c 80140768 8014076c 00000000
NDIS!_NdisCopyBuffer+0x26 (FPO: [EBP 0xff067010] [6,0,4])
8014076c fc932071 ff07300c ff066028 fc9320ba
sfmatalk!_AtalkNdisSendPacket+0xa4 (FPO: [EBP 0x801407e8] [4,2,4])
801407e8 fc931950 ff07300c 80140838 ff9f673c
sfmatalk!_AtalkDdpTransmit+0x60b
8014083c 801144fc ff191800 fc942a80 ff11960c
sfmatalk!_AtalkDdpSend+0x71 (FPO: [EBP 0x00000000] [9,7,4])
80140884 fc94299f ff9f6720 ff065c20 00000246
NT!_IoAllocateMdl+0x64 (FPO: [EBP 0x0000001b] [5,1,4])
801408c0 fc943f5e ff11966c ff982390 ff17732a
sfmatalk!atalkAtpSendReqComplete (FPO: [0,0,1])
80140910 fc943e8b 00000000 ff11799c ff068854
sfmatalk!atalkAspPostWriteContinue+0x9c (FPO: [EBP 0x80140930] [0,1,4])
80140930 fc9421db 00000000 ff1199cc ff11799c
sfmatalk!_atalkAspSssXHandler+0x1f5
80140990 fc930c64 ff07300c
ff11960c ff066cf0 sfmatalk!_AtalkAtpPacketIn+0x5a9
801409dc fc90068b ff07300c ffdff420 ff070007
sfmatalk!_AtalkReceiveComplete+0xdc
801409f4 fc910f88 ff07c508 ff07c628 00000001
NDIS!_EthFilterDprIndicateReceiveComplete+0x33
(FPO: [EBP 0xffdff420] [1,0,4])
80140a04 fc8f04eb ff07c508 ff07c654 8013e820
NDIS!_EthFilterIndicateReceiveComplete+0x21
(FPO: [1,0,2])
In this TrapFrame, note that the instruction pointer is running what is at memory
address 801144dc. The unassemble shows that the instruction that should have
been called is 801144dd, rather than what is currently in EIP.
Trap Frame:
kd> !trap 8014068c
!trap 8014068c
eax=ff0f6488 ebx=00000020 ecx=801440e0 edx=ff971b50 esi=00000000
edi=00000358
eip=801144dc esp=80140700 ebp=ff177358 iopl=0 nv up ei ng nz na pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010283
ErrCode = 00000002
801144dc 0083f810760b add [ebx+0xb7610f8],al
Unassemble of IoAllocateMdl Function and EIP
--------------------------------------------
Correct Unassemble of IoAlloateMdl from the Beginning of the Function::
kd> u NT!_IoAllocateMdl NT!_IoAllocateMdl+0x50
u NT!_IoAllocateMdl NT!_IoAllocateMdl+0x50
NT!_IoAllocateMdl:
80114498 83ec04 sub esp,0x4
8011449b f644240f80 test byte ptr [esp+0xf],0x80
801144a0 53 push ebx
801144a1 56 push esi
801144a2 57 push edi
801144a3 55 push ebp
801144a4 7407 jz NT!_IoAllocateMdl+0x15 (801144ad)
801144a6 33c0 xor eax,eax
801144a8 e99e010000 jmp NT!_IoAllocateMdl+0x1b3 (8011464b)
801144ad 8b7c2418 mov edi,[esp+0x18]
801144b1 8b44241c mov eax,[esp+0x1c]
801144b5 81e7ff0f0000 and edi,0xfff
801144bb 33f6 xor esi,esi
801144bd 03c7 add eax,edi
801144bf 05ff0f0000 add eax,0xfff
801144c4 c1e80c shr eax,0xc
801144c7 8d1c851c000000 lea ebx,[0000001c+eax*4]
801144ce 81fbffff0000 cmp ebx,0xffff
801144d4 7607 jbe NT!_IoAllocateMdl+0x45 (801144dd)
801144d6 33c0 xor eax,eax
801144d8 e96e010000 jmp NT!_IoAllocateMdl+0x1b3 (8011464b)
801144dd 83f810 cmp eax,0x10 <----------------- Position 1 **
801144e0 760b jbe NT!_IoAllocateMdl+0x55 (801144ed)
801144e2 ff0514411480 inc dword ptr [NT!_IopMdlSizeMiss(80144114)]
Unassemble of the Function Using the Current Instruction Pointer That is the
Offset Into the Function When the Trap
Occurred:
kd> u NT!_IoAllocateMdl+0x44
u NT!_IoAllocateMdl+0x44
NT!_IoAllocateMdl+0x44:
801144dc 0083f810760b add [ebx+0xb7610f8],al <---------- Position 2**
801144e2 ff0514411480 inc dword ptr [NT!_IopMdlSizeMiss (80144114)]
801144e8 e99d000000 jmp NT!_IoAllocateMdl+0xf2 (8011458a)
801144ed ba30e21380 mov edx,0x8013e230
801144f2 b9e0401480 mov ecx,0x801440e0
801144f7 e804370200 call NT!ExfInterlockedPopEntryList (80137c00)
801144fc 8bf0 mov esi,eax
801144fe 85f6 test esi,esi
The function is unassembled from the beginning, in order to show which
instructions should have been run. The unassemble of the function starting at
Position 2 should match the unassemble of the function at Position 1.
Parity Error:
The difference between 801144dc (what was in EIP) and 801144dd (what should have
been in EIP) is one bit, as illustrated below.
801144dc = 10000000000100010100010011011100
801144dd = 10000000000100010100010011011101
This difference of one bit is a parity error that could have been caused by a
faulty cache or by faulty memory.
Bad Instruction Pointer:
If you break down the Opcode, you will notice that the instruction at address
801144dd is 83f810. The operand is an instruction to compare the sign extended
byte to a dword. The processor should have completed a compare of the EAX
register to 0X10.
The instruction pointer in EIP was altered by one bit. The system now carries out
instructions beginning at 801144dd, which causes the system to fail. The new
instruction 0083f810760b is an add-byte register to memory byte.
Breakdown of the Instruction at 801144dd and Opcode:
Opcode
|
|
Instruction = 801144dd 83f810 cmp eax,0x10
Opcode breakdown
83 = CMP,m32,imm8
f8 = EAX
10 = 0x10
Breakdown of the Instruction at 801144dc and Opcode:
Opcode
|
|
Instruction = 801144dc 0083f810760b add [ebx+0xb7610f8],al
Opcode breakdown
00 = ADD,m32,imm8
83 = disp32(displace 32 bits)
b7610f8 = address used in ADD
REFERENCES
==========
The computer in this example failed because the invalid instruction accessed
memory that had not been initialized. Once the motherboard was replaced, the
computer functioned normally.
For more information about how to debug the kernel, query on the following word
here in the Microsoft Knowledge Base:
debugref
Additional query words: prodnt debugref
======================================================================
Keywords :
Technology : kbWinNTsearch kbWinNTWsearch kbWinNT351search kbWinNT350search kbWinNTW350 kbWinNTW350search kbWinNTW351search kbWinNTW351 kbWinNTSsearch kbWinNTS351 kbWinNTS350 kbWinNTS351search kbWinNTS350search
Version : :3.5,3.51
=============================================================================
THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.
Copyright Microsoft Corporation 1986-2002.