Question

Locked

Analyzing Windows 2008 x64 crash dump

By schetty ·
I am running a Windows 2008 SP2 installation - hosting Exchange 2007 on a Dell 2950 PowerEdge server.

Recently I have had irregular BSOD crashes on this server.

I updated the NIC drivers - as this was the most likely cause of the BSOD - according to the dump analysis from WinDbg.

I am still plagued with these BSODs - approximately twice a week.

I would appreciate any help -Thanks.

Here is my Dump Analysis...........


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


Loading Dump File [C:\Windows\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 Server 2008/Windows Vista Kernel Version 6002 (Service Pack 2) MP (8 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 6002.18005.amd64fre.lh_sp2rtm.090410-1830
Machine Name:
Kernel base = 0xfffff800`0185e000 PsLoadedModuleList = 0xfffff800`01a22dd0
Debug session time: Thu Aug 6 11:09:18.847 2009 (GMT+2)
System Uptime: 1 days 18:19:58.026
Loading Kernel Symbols
...............................................................
................................................................
.....
Loading User Symbols

Loading unloaded module list
..
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {8576fd53, 2, 8, 8576fd53}

*** ERROR: Module load completed but symbols could not be loaded for bxnd60a.sys
*** ERROR: Module load completed but symbols could not be loaded for bxvbda.sys
Probably caused by : bxnd60a.sys ( bxnd60a+ba5a )

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


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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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 kernel debugger is available get stack backtrace.
Arguments:
Arg1: 000000008576fd53, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000008, value 0 = read operation, 1 = write operation
Arg4: 000000008576fd53, address which referenced memory

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


READ_ADDRESS: 000000008576fd53

CURRENT_IRQL: 2

FAULTING_IP:
+0
00000000`8576fd53 ?? ???

PROCESS_NAME: System

DEFAULT_BUCKET_I VISTA_DRIVER_FAULT

BUGCHECK_STR: 0xD1

TRAP_FRAME: fffffa60019feea0 -- (.trap 0xfffffa60019feea0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000000008576fd53 rbx=0000000000000000 rcx=000000000001ad08
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=000000008576fd53 rsp=fffffa60019ff038 rbp=fffffa6001156400
r8=fffffa801f0d1840 r9=0000000000000001 r10=fffffa801a2edb10
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
00000000`8576fd53 ?? ???
Resetting default scope

LAST_CONTROL_TRANSFER: from fffff800018b81ee to fffff800018b8450

FAILED_INSTRUCTION_ADDRESS:
+0
00000000`8576fd53 ?? ???

STACK_TEXT:
fffffa60`019fed58 fffff800`018b81ee : 00000000`0000000a 00000000`8576fd53 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx
fffffa60`019fed60 fffff800`018b70cb : 00000000`00000008 fffffa80`1c05c010 00000000`00000004 fffffa80`1c05c010 : nt!KiBugCheckDispatch+0x6e
fffffa60`019feea0 00000000`8576fd53 : fffffa60`0106fc76 fffffa80`1c05c010 fffffa60`01156400 00000000`00000000 : nt!KiPageFault+0x20b
fffffa60`019ff038 fffffa60`0106fc76 : fffffa80`1c05c010 fffffa60`01156400 00000000`00000000 fffffa80`1f52f010 : 0x8576fd53
fffffa60`019ff040 fffffa60`0106ee0a : fffffa80`1c05c010 fffffa80`1a427008 fffffa80`1a30c7c0 fffffa60`019ff120 : tcpip!TcpCleanupTcbWorkQueueRoutine+0xd6
fffffa60`019ff080 fffffa60`01069d1a : fffffa80`1a40cf00 00000000`00000001 fffffa80`1a427008 00000000`00000000 : tcpip!TcpTcbReceive+0x6da
fffffa60`019ff230 fffffa60`0106883f : fffffa80`1aa67cec 00000000`00000000 00000000`00000000 fffffa60`019f8f00 : tcpip!TcpMatchReceive+0x1ba
fffffa60`019ff330 fffffa60`01067e23 : 00000000`00000001 00000000`00da7a64 fffffa80`20054506 fffffa80`1d02b960 : tcpip!TcpPreValidatedReceive+0x2ef
fffffa60`019ff3c0 fffffa60`010674cb : fffffa80`1b4c00c0 00000000`00000000 fffffa80`1b0c0006 fffffa80`1a4270f0 : tcpip!IpFlcReceivePreValidatedPackets+0x533
fffffa60`019ff520 fffffa60`009b10bc : fffffa80`1bd4b010 00000000`00000000 fffffa60`019ff600 fffffa80`1a6cc1a0 : tcpip!FlReceiveNetBufferListChain+0x9b
fffffa60`019ff570 fffffa60`009798c9 : fffffa60`019ff6d0 00000000`00000000 fffffa80`1b14b010 00000000`00000001 : NDIS!ndisMIndicateNetBufferListsToOpen+0xac
fffffa60`019ff5c0 fffffa60`0080e6f7 : fffffa80`1a6cc1a0 00000000`00000002 fffffa80`1b0c82a0 fffffa60`00e135c8 : NDIS!ndisMDispatchReceiveNetBufferLists+0x1d9
fffffa60`019ffa40 fffffa60`00f5ba5a : 00000000`00000000 fffffa60`019ffb70 00000000`00000000 fffffa80`1eddb0c0 : NDIS!NdisMIndicateReceiveNetBufferLists+0x67
fffffa60`019ffa80 fffffa60`00f5bc2e : fffffa80`1a774010 00000000`00000000 fffffa80`1a7744e8 fffffa80`19f84308 : bxnd60a+0xba5a
fffffa60`019ffae0 fffffa60`00e0c9a7 : fffffa80`1a196010 fffffa80`1a786000 00000000`00000000 00000000`0000000c : bxnd60a+0xbc2e
fffffa60`019ffb50 fffffa60`00e0cc42 : fffffa80`1a196010 00000000`ffffffff 00000000`00000000 00000000`00000000 : bxvbda+0x69a7
fffffa60`019ffbb0 fffffa60`00e13c16 : fffffa80`1a196990 00000000`00000007 fffffa80`1a199890 fffffa80`1a372a10 : bxvbda+0x6c42
fffffa60`019ffc30 fffffa60`00e13de0 : fffffa80`1a196010 fffff780`00000003 00000000`00000007 fffffa60`00f367a2 : bxvbda+0xdc16
fffffa60`019ffc90 fffffa60`00e143e1 : fffffa80`1a196010 fffff780`00000008 00000000`00000001 fffffa60`019d8180 : bxvbda+0xdde0
fffffa60`019ffce0 fffff800`018bc667 : fffffa80`1a198398 00000000`00000000 fffffa60`019db580 00000000`00000000 : bxvbda+0xe3e1
fffffa60`019ffd10 fffff800`018bc8e2 : fffffa60`00e14334 fffffa60`019d8180 00000000`00000000 fffffa60`019e1d40 : nt!KiRetireDpcList+0x117
fffffa60`019ffd80 fffff800`01a89860 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x62
fffffa60`019ffdb0 00000000`fffffa60 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!zzz_AsmCodeRange_End+0x4
fffffa60`019dbd00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00680000`00000000 : 0xfffffa60


STACK_COMMAN kb

FOLLOWUP_IP:
bxnd60a+ba5a
fffffa60`00f5ba5a 488b5c2460 mov rbx,qword ptr [rsp+60h]

SYMBOL_STACK_INDEX: d

SYMBOL_NAME: bxnd60a+ba5a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: bxnd60a

IMAGE_NAME: bxnd60a.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4980e0ae

FAILURE_BUCKET_I X64_0xD1_CODE_AV_BAD_IP_bxnd60a+ba5a

BUCKET_I X64_0xD1_CODE_AV_BAD_IP_bxnd60a+ba5a

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


3: kd> !thread
THREAD fffffa60019e1d40 Cid 0000.0000 Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 3
Not impersonating
DeviceMap fffff88000007450
Owning Process fffff800019d70c0 Image: Idle
Attached Process fffffa80199fec10 Image: System
Wait Start TickCount 9663615 Ticks: 105426 (0:00:27:24.656)
Context Switch Count 20571280
UserTime 00:00:00.000
KernelTime 1 Day 17:47:05.212
Win32 Start Address nt!KiIdleLoop (0xfffff800018bc880)
Stack Init fffffa60019ffdb0 Current fffffa60019ffd40
Base fffffa6001a00000 Limit fffffa60019fa000 Call 0
Priority 16 BasePriority 0 PriorityDecrement 0 IoPriority 0 PagePriority 0
Child-SP RetAddr : Args to Child : Call Site
fffffa60`019fed58 fffff800`018b81ee : 00000000`0000000a 00000000`8576fd53 00000000`00000002 00000000`00000008 : nt!KeBugCheckEx
fffffa60`019fed60 fffff800`018b70cb : 00000000`00000008 fffffa80`1c05c010 00000000`00000004 fffffa80`1c05c010 : nt!KiBugCheckDispatch+0x6e
fffffa60`019feea0 00000000`8576fd53 : fffffa60`0106fc76 fffffa80`1c05c010 fffffa60`01156400 00000000`00000000 : nt!KiPageFault+0x20b (TrapFrame @ fffffa60`019feea0)
fffffa60`019ff038 fffffa60`0106fc76 : fffffa80`1c05c010 fffffa60`01156400 00000000`00000000 fffffa80`1f52f010 : 0x8576fd53
fffffa60`019ff040 fffffa60`0106ee0a : fffffa80`1c05c010 fffffa80`1a427008 fffffa80`1a30c7c0 fffffa60`019ff120 : tcpip!TcpCleanupTcbWorkQueueRoutine+0xd6
fffffa60`019ff080 fffffa60`01069d1a : fffffa80`1a40cf00 00000000`00000001 fffffa80`1a427008 00000000`00000000 : tcpip!TcpTcbReceive+0x6da
fffffa60`019ff230 fffffa60`0106883f : fffffa80`1aa67cec 00000000`00000000 00000000`00000000 fffffa60`019f8f00 : tcpip!TcpMatchReceive+0x1ba
fffffa60`019ff330 fffffa60`01067e23 : 00000000`00000001 00000000`00da7a64 fffffa80`20054506 fffffa80`1d02b960 : tcpip!TcpPreValidatedReceive+0x2ef
fffffa60`019ff3c0 fffffa60`010674cb : fffffa80`1b4c00c0 00000000`00000000 fffffa80`1b0c0006 fffffa80`1a4270f0 : tcpip!IpFlcReceivePreValidatedPackets+0x533
fffffa60`019ff520 fffffa60`009b10bc : fffffa80`1bd4b010 00000000`00000000 fffffa60`019ff600 fffffa80`1a6cc1a0 : tcpip!FlReceiveNetBufferListChain+0x9b
fffffa60`019ff570 fffffa60`009798c9 : fffffa60`019ff6d0 00000000`00000000 fffffa80`1b14b010 00000000`00000001 : NDIS!ndisMIndicateNetBufferListsToOpen+0xac
fffffa60`019ff5c0 fffffa60`0080e6f7 : fffffa80`1a6cc1a0 00000000`00000002 fffffa80`1b0c82a0 fffffa60`00e135c8 : NDIS!ndisMDispatchReceiveNetBufferLists+0x1d9
fffffa60`019ffa40 fffffa60`00f5ba5a : 00000000`00000000 fffffa60`019ffb70 00000000`00000000 fffffa80`1eddb0c0 : NDIS!NdisMIndicateReceiveNetBufferLists+0x67
fffffa60`019ffa80 fffffa60`00f5bc2e : fffffa80`1a774010 00000000`00000000 fffffa80`1a7744e8 fffffa80`19f84308 : bxnd60a+0xba5a
fffffa60`019ffae0 fffffa60`00e0c9a7 : fffffa80`1a196010 fffffa80`1a786000 00000000`00000000 00000000`0000000c : bxnd60a+0xbc2e
fffffa60`019ffb50 fffffa60`00e0cc42 : fffffa80`1a196010 00000000`ffffffff 00000000`00000000 00000000`00000000 : bxvbda+0x69a7
fffffa60`019ffbb0 fffffa60`00e13c16 : fffffa80`1a196990 00000000`00000007 fffffa80`1a199890 fffffa80`1a372a10 : bxvbda+0x6c42
fffffa60`019ffc30 fffffa60`00e13de0 : fffffa80`1a196010 fffff780`00000003 00000000`00000007 fffffa60`00f367a2 : bxvbda+0xdc16
fffffa60`019ffc90 fffffa60`00e143e1 : fffffa80`1a196010 fffff780`00000008 00000000`00000001 fffffa60`019d8180 : bxvbda+0xdde0
fffffa60`019ffce0 fffff800`018bc667 : fffffa80`1a198398 00000000`00000000 fffffa60`019db580 00000000`00000000 : bxvbda+0xe3e1
fffffa60`019ffd10 fffff800`018bc8e2 : fffffa60`00e14334 fffffa60`019d8180 00000000`00000000 fffffa60`019e1d40 : nt!KiRetireDpcList+0x117
fffffa60`019ffd80 fffff800`01a89860 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x62
fffffa60`019ffdb0 00000000`fffffa60 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!zzz_AsmCodeRange_End+0x4
fffffa60`019dbd00 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00680000`00000000 : 0xfffffa60


3: kd> !process fffff800019d70c0 0
PROCESS fffff800019d70c0
SessionId: none Cid: 0000 Peb: 00000000 ParentCid: 0000
DirBase: 00124000 ObjectTable: fffff88000002010 HandleCount: 4419.
Image: Idle

This conversation is currently closed to new comments.

3 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

See if this will help

by Jacky Howe In reply to Analyzing Windows 2008 x6 ...

It is obviously being caused by bxnd60a.sys. Have a look at this and determine the correct drivers.

http://www.broadcom.com/support/ethernet_nic/determine_driver.php

Collapse -

I have installed the latest version of the drivers

by schetty In reply to See if this will help

Thank you for replying.

I did previously install the latest version of the drivers and the system still crashed as per the enclosed dump.

I did find that other users on TechRepublic have posted similar symptoms with Broadcom NICs.

http://techrepublic.com.com/5208-1035-0.html?forumID=101&threadID=309360&messageID=3079004

I seems that you cannot use the two NICs pointing to different gateways/subnets.

As in the post above and this post....

http://techrepublic.com.com/5208-6230-0.html?forumID=101&threadID=240729&messageID=2336321


....the route needs to be static.

Since I run a critical services server, I have disabled my second NIC and using just one NIC for the two Exchange services that are hosted on the server.

The server has been stable since disabling one NIC.

I will certainly try adding static routes to the NICs at a later stage when my environment becomes less busy.
At present I am satisfied that the system appears to be stable - and the cause of the BSODs is the routing issue.

Any further thoughts are welcome.

Kind regards to all of you.

Back to Networks Forum
3 total posts (Page 1 of 1)  

Related Discussions

Related Forums