Server 2008 R2 BSOD Bugcheck Analysis

I had one of my Windows Server 2008 R2 Remote Desktop server BSOD this morning. I have the full DMP file & have pasted the results from WinDbg analysis. Any help or nudge in the right direction would be appreciated. Thanks.


Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Dump\Server1\201309120918\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (24 procs) Free x64
Product: Server, suite: Enterprise TerminalServer
Built by: 7601.18205.amd64fre.win7sp1_gdr.130708-1532
Machine Name:
Kernel base = 0xfffff800`0160a000 PsLoadedModuleList = 0xfffff800`0184d6d0
Debug session time: Thu Sep 12 09:15:09.451 2013 (UTC - 5:00)
System Uptime: 0 days 7:05:51.417
Loading Kernel Symbols
...............................................................
................................................................
....................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`7efdf018).  Type ".hh dbgerr001" for details
Loading unloaded module list
.............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {0, 2, 1, fffff800016423ae}

Page 80da06 not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : tcpip.sys ( tcpip!WfpAlepEndpointCleanup+55 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, bitfield :
 bit 0 : value 0 = read operation, 1 = write operation
 bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff800016423ae, address which referenced memory

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

Page 80da06 not present in the dump file. Type ".hh dbgerr004" for details

WRITE_ADDRESS:  0000000000000000

CURRENT_IRQL:  2

FAULTING_IP:
nt!RtlRemoveEntryHashTable+3e
fffff800`016423ae 488908          mov     qword ptr [rax],rcx

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

BUGCHECK_STR:  0xA

PROCESS_NAME:  iexplore.exe

TRAP_FRAME:  fffff8800c6d64d0 -- (.trap 0xfffff8800c6d64d0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=fffffa803a44a660 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800016423ae rsp=fffff8800c6d6660 rbp=0000000000000000
 r8=0000000000005651  r9=0000000000000000 r10=fffff8800198b120
r11=0000000000000040 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz ac pe nc
nt!RtlRemoveEntryHashTable+0x3e:
fffff800`016423ae 488908          mov     qword ptr [rax],rcx ds:0001:00000000`00000000=????????????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff8000167f129 to fffff8000167fb80

STACK_TEXT: 
fffff880`0c6d6388 fffff800`0167f129 : 00000000`0000000a 00000000`00000000 00000000`00000002 00000000`00000001 : nt!KeBugCheckEx
fffff880`0c6d6390 fffff800`0167dda0 : 00000000`00000000 fffff880`046ae9e5 fffffa80`39000000 fffffa80`3a44a520 : nt!KiBugCheckDispatch+0x69
fffff880`0c6d64d0 fffff800`016423ae : fffff880`0c6d66f0 fffffa80`3a44a501 00000000`00000001 00000000`00000000 : nt!KiPageFault+0x260
fffff880`0c6d6660 fffff880`01868225 : fffffa80`3a44a520 00000000`00000000 fffffa80`3a44a578 fffffa80`3a44a520 : nt!RtlRemoveEntryHashTable+0x3e
fffff880`0c6d6690 fffff880`018684af : fffffa80`3a000004 00000000`00000002 fffffa80`3a44a578 fffffa80`3a44a520 : tcpip!WfpAlepEndpointCleanup+0x55
fffff880`0c6d66f0 fffff880`0187b765 : fffffa80`3a44a578 fffff8a0`1cdac510 fffffa80`1a127000 fffffa80`39db8210 : tcpip!WfpAleEndpointTeardownHandler+0x6f
fffff880`0c6d6720 fffff880`0187b602 : fffff880`0c6d68b8 fffffa80`1a6b2bc0 00000000`00000000 fffffa80`1a6b2bc0 : tcpip!TcpCleanupEndpointWorkQueueRoutine+0x105
fffff880`0c6d67c0 fffff880`0187b649 : 00000000`00000001 00000000`00000000 00000000`00000000 fffffa80`39db8310 : tcpip!TcpCloseEndpoint+0x92
fffff880`0c6d6830 fffff880`046eda30 : 00000000`00000000 00000000`ffffffff 00000000`00000000 fffffa80`39db8310 : tcpip!TcpTlEndpointCloseEndpoint+0x9
fffff880`0c6d6860 fffff880`046edef2 : 00000000`00000000 fffffa80`39d4d070 fffffa80`39db8210 fffff800`01693cb6 : afd!AfdCleanupCore+0x410
fffff880`0c6d69e0 fffff800`0198a28f : fffffa80`1ea34b20 fffffa80`1eb0f060 00000000`00000000 fffffa80`39d4d070 : afd!AfdDispatch+0x42
fffff880`0c6d6a30 fffff800`01978284 : 00000000`00000000 fffffa80`1eb0f060 fffffa80`1ec42d20 fffffa80`3a1b5d40 : nt!IopCloseFile+0x11f
fffff880`0c6d6ac0 fffff800`01978041 : fffffa80`1eb0f060 fffffa80`00000001 fffff8a0`1cdac510 00000000`00000002 : nt!ObpDecrementHandleCount+0xb4
fffff880`0c6d6b40 fffff800`01978604 : 00000000`00000e98 fffffa80`1eb0f060 fffff8a0`1cdac510 00000000`00000e98 : nt!ObpCloseHandleTableEntry+0xb1
fffff880`0c6d6bd0 fffff800`0167ee13 : fffffa80`1e59db00 fffff880`0c6d6ca0 00000000`7ef92000 00000000`7ef92000 : nt!ObpCloseHandle+0x94
fffff880`0c6d6c20 00000000`77ab13aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0412e178 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77ab13aa


STACK_COMMAND:  kb

FOLLOWUP_IP:
tcpip!WfpAlepEndpointCleanup+55
fffff880`01868225 488d0df42e1200  lea     rcx,[tcpip!endpointHandleTable (fffff880`0198b120)]

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  tcpip!WfpAlepEndpointCleanup+55

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: tcpip

IMAGE_NAME:  tcpip.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  51d78b2c

FAILURE_BUCKET_ID:  X64_0xA_tcpip!WfpAlepEndpointCleanup+55

BUCKET_ID:  X64_0xA_tcpip!WfpAlepEndpointCleanup+55

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

22: kd> lmvm tcpip
start             end                 module name
fffff880`01800000 fffff880`01a00000   tcpip      (pdb symbols)          c:\symbols\tcpip.pdb\40964B6C02D8460A97FC69F4ED4CFF452\tcpip.pdb
    Loaded symbol image file: tcpip.sys
    Image path: \SystemRoot\System32\drivers\tcpip.sys
    Image name: tcpip.sys
    Timestamp:        Fri Jul 05 22:12:44 2013 (51D78B2C)
    CheckSum:         001D58C0
    ImageSize:        00200000
    Translations:     0000.04b0 0000.04e4 0409.04b0 040

September 12th, 2013 7:30pm

Hi,

Thanks for the question.

The error that generates this bug check usually occurs after the installation of a faulty device driver, system service, or BIOS.

For more details, you can follow this article.

Bug Check 0xA: IRQL_NOT_LESS_OR_EQUAL

http://msdn.microsoft.com/en-us/library/windows/hardware/ff560129(v=vs.85).aspx

Hope this helps.

Free Windows Admin Tool Kit Click here and download it now
September 14th, 2013 11:21am

Please start with the following:

  • Run memtest86+ to check your RAM. If an error was detected then replace the faulty RAM or contact your manufacturer Technical Support for assistance
  • Update all possible drivers (Especially your NIC ones), firmware and BIOS
  • Uninstall all unused programs
  • Do a clean boot: http://support.microsoft.com/kb/929135
  • Run chkdsk /r /f and sfc /scannow
  • Disable temporary each security software in use

September 15th, 2013 9:31pm

Looks like there is a fairly recent NIC driver update. I'll try that. Any other thoughts on additional things to try in WinDbg?
Free Windows Admin Tool Kit Click here and download it now
September 16th, 2013 11:47pm

Hi,

Is there any update after updating the driver?

If issue persists, I recommend you to contact Microsoft Customer Support Service (CSS) for detailed debugging.

Thanks.

September 18th, 2013 1:25pm

ALE is performed at kernel mode .the crash is at application enforcement layer . There are some opened ALE sockets established on your system which are unable to close down with TCPIP driver.

From the trace the ALE endpoint is closed  

fffffa80`39db8310 : tcpip!TcpTlEndpointCloseEndpoint+0x9
fffff880`0c6d6860 fffff880`046edef2 : 00000000`00000000 fffffa80`39d4d070 fffffa80`39db8210 fffff800`01693cb6 : afd!AfdCleanupCore+0x410

Later the clean up starts which is expected ( that is the default behavior )

fffff880`0c6d6720 fffff880`0187b602 : fffff880`0c6d68b8 fffffa80`1a6b2bc0 00000000`00000000 fffffa80`1a6b2bc0 : tcpip!TcpCleanupEndpointWorkQueueRoutine+0x105

and tcpip!WfpAlepEndpointCleanup errors out.

THe reason might be the driver is not able to support the stateful filtering or not compatible with driver.

Free Windows Admin Tool Kit Click here and download it now
September 18th, 2013 2:10pm

ALE is performed at kernel mode .the crash is at application enforcement layer . There are some opened ALE sockets established on your system which are unable to close down with TCPIP driver.

From the trace the ALE endpoint is closed  

fffffa80`39db8310 : tcpip!TcpTlEndpointCloseEndpoint+0x9
fffff880`0c6d6860 fffff880`046edef2 : 00000000`00000000 fffffa80`39d4d070 fffffa80`39db8210 fffff800`01693cb6 : afd!AfdCleanupCore+0x410

Later the clean up starts which is expected ( that is the default behavior )

fffff880`0c6d6720 fffff880`0187b602 : fffff880`0c6d68b8 fffffa80`1a6b2bc0 00000000`00000000 fffffa80`1a6b2bc0 : tcpip!TcpCleanupEndpointWorkQueueRoutine+0x105

and tcpip!WfpAlepEndpointCleanup errors out.

THe reason might be the driver is not able to support the stateful filtering or not compatible with driver.

September 18th, 2013 2:10pm

Hi Patrick,

I would like to check if you need further assistance.

Thanks.

Free Windows Admin Tool Kit Click here and download it now
September 22nd, 2013 1:32am

I have updated the NIC driver & firmware. (Knock on wood) I haven't got a BSOD in a while.

October 19th, 2013 2:32pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics