Dear Sir We are using Windows 2008 std SP1 server with exchange 2007 SP1 installed on IBM x3650M2 with 4 GB RAM. The server got restarted with minidump. When analyzed the dump with windbg.exe in debugging tools I get> Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [D:\TempStorageDrive\it\Mini020911-01.dmp] Mini Kernel Dump File: Only registers and stack trace are 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 (4 procs) Free x64 Product: Server, suite: Enterprise TerminalServer SingleUserTS Built by: 6002.18005.amd64fre.lh_sp2rtm.090410-1830 Machine Name: Kernel base = 0xfffff800`01818000 PsLoadedModuleList = 0xfffff800`019dcdd0 Debug session time: Wed Feb 9 12:26:41.945 2011 (GMT+6) System Uptime: 6 days 19:02:11.080 Loading Kernel Symbols . Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long. Run !sym noisy before .reload to track down problems loading symbols. .............................................................. ................................................................ ................ Loading User Symbols Loading unloaded module list ............. ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck D1, {817c5599, 2, 0, 817c5599} Unable to load image \SystemRoot\system32\DRIVERS\teefer2.sys, Win32 error 0n2 *** WARNING: Unable to verify timestamp for teefer2.sys *** ERROR: Module load completed but symbols could not be loaded for teefer2.sys Probably caused by : teefer2.sys ( teefer2+602a ) Followup: MachineOwner --------- 1: 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: 00000000817c5599, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000000, value 0 = read operation, 1 = write operation Arg4: 00000000817c5599, address which referenced memory Debugging Details: ------------------ READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80001a3f080 00000000817c5599 CURRENT_IRQL: 2 FAULTING_IP: +0 00000000`817c5599 ?? ??? PROCESS_NAME: System CUSTOMER_CRASH_COUNT: 1 DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP BUGCHECK_STR: 0xD1 TRAP_FRAME: fffffa6006b35c10 -- (.trap 0xfffffa6006b35c10) NOTE: The trap frame does not contain all registers. Some register values may be zeroed or incorrect. rax=00000000817c5599 rbx=0000000000000000 rcx=00000000000183d3 rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000 rip=00000000817c5599 rsp=fffffa6006b35da8 rbp=fffffa6001155400 r8=00000000000025a8 r9=ffffffffffda8600 r10=00000000000000f1 r11=0000000000000000 r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 iopl=0 nv up ei pl zr na po nc 00000000`817c5599 ?? ??? Resetting default scope LAST_CONTROL_TRANSFER: from fffff800018721ee to fffff80001872450 FAILED_INSTRUCTION_ADDRESS: +0 00000000`817c5599 ?? ??? STACK_TEXT: fffffa60`06b35ac8 fffff800`018721ee : 00000000`0000000a 00000000`817c5599 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx fffffa60`06b35ad0 fffff800`018710cb : 00000000`00000000 fffffa80`0935b5a0 00000000`00000014 fffffa80`0935b5a0 : nt!KiBugCheckDispatch+0x6e fffffa60`06b35c10 00000000`817c5599 : fffffa60`0106ec76 fffffa80`0935b5a0 fffffa60`01155400 00000000`00000000 : nt!KiPageFault+0x20b fffffa60`06b35da8 fffffa60`0106ec76 : fffffa80`0935b5a0 fffffa60`01155400 00000000`00000000 fffffa80`074364b0 : 0x817c5599 fffffa60`06b35db0 fffffa60`0106de0a : fffffa80`0935b5a0 fffffa80`04379000 fffffa80`0427fe40 fffffa60`06b35e90 : tcpip!TcpCleanupTcbWorkQueueRoutine+0xd6 fffffa60`06b35df0 fffffa60`01068d1a : fffffa80`04378f00 fffffa60`00a08801 fffffa80`04379000 00000000`00000000 : tcpip!TcpTcbReceive+0x6da fffffa60`06b35fa0 fffffa60`0106783f : fffffa80`04548312 00000000`00000000 fffffa80`0632e130 fffffa80`04371900 : tcpip!TcpMatchReceive+0x1ba fffffa60`06b360a0 fffffa60`01062b9d : fffffa80`04371900 00000000`00da7a64 fffffa80`0437dc92 00000000`00000000 : tcpip!TcpPreValidatedReceive+0x2ef fffffa60`06b36130 fffffa60`0105877d : fffffa80`04382e30 fffffa80`05ac8080 fffffa60`06b362f0 fffffa60`010665aa : tcpip!TcpNlClientReceiveDatagrams+0x6d fffffa60`06b36160 fffffa60`01058829 : 00000000`00000000 00000000`00000001 00000000`00000002 fffffa60`06b36318 : tcpip!IppDeliverListToProtocol+0x4d fffffa60`06b36220 fffffa60`01057edb : fffffa60`01143050 fffffa80`0454830a 00000000`00000000 fffffa60`06b362e0 : tcpip!IppProcessDeliverList+0x59 fffffa60`06b36290 fffffa60`0105722c : fffffa80`06383bb0 00000000`00000020 fffffa80`05ac8080 fffffa80`045456fc : tcpip!IppReceiveHeaderBatch+0x22b fffffa60`06b36380 fffffa60`01056814 : fffffa80`0588c440 00000000`00000000 fffffa80`05ab8c01 fffffa60`00000001 : tcpip!IpFlcReceivePackets+0x8dc fffffa60`06b36580 fffffa60`01066503 : fffffa80`05ab8c40 fffffa60`06b366b8 fffffa80`05ab8c40 fffffa60`00970000 : tcpip!FlpReceiveNonPreValidatedNetBufferListChain+0x264 fffffa60`06b36660 fffffa60`009a90bc : fffffa80`05ab94e0 fffffa80`0632e030 fffffa60`06b36800 fffffa80`045aa1a0 : tcpip!FlReceiveNetBufferListChain+0xd3 fffffa60`06b366b0 fffffa60`009718c9 : fffffa60`06b36810 00000000`00000000 fffffa80`05ab9a50 00000000`00000001 : NDIS!ndisMIndicateNetBufferListsToOpen+0xac fffffa60`06b36700 fffffa60`0080e5c4 : fffffa80`045aa1a0 00000000`00000002 00000000`00000001 00000000`00000001 : NDIS!ndisMDispatchReceiveNetBufferLists+0x1d9 fffffa60`06b36b80 fffffa60`009a98a6 : fffffa80`00000001 00000000`00000000 fffffa80`0632e030 fffffa60`06b36ce8 : NDIS!ndisMTopReceiveNetBufferLists+0x24 fffffa60`06b36bc0 fffffa60`036dc02a : fffffa80`03cbe110 fffffa60`036e3684 fffffa60`00000001 fffffa80`044ea000 : NDIS!ndisMIndicatePacketsToNetBufferLists+0x106 fffffa60`06b36c60 fffffa80`03cbe110 : fffffa60`036e3684 fffffa60`00000001 fffffa80`044ea000 fffffa80`044ea000 : teefer2+0x602a fffffa60`06b36c68 fffffa60`036e3684 : fffffa60`00000001 fffffa80`044ea000 fffffa80`044ea000 00000000`00000080 : 0xfffffa80`03cbe110 fffffa60`06b36c70 fffffa60`00000001 : fffffa80`044ea000 fffffa80`044ea000 00000000`00000080 00000000`00000000 : teefer2+0xd684 fffffa60`06b36c78 fffffa80`044ea000 : fffffa80`044ea000 00000000`00000080 00000000`00000000 fffffa60`0080d31f : 0xfffffa60`00000001 fffffa60`06b36c80 fffffa80`044ea000 : 00000000`00000080 00000000`00000000 fffffa60`0080d31f fffffa60`01966cc0 : 0xfffffa80`044ea000 fffffa60`06b36c88 00000000`00000080 : 00000000`00000000 fffffa60`0080d31f fffffa60`01966cc0 00000000`00000000 : 0xfffffa80`044ea000 fffffa60`06b36c90 00000000`00000000 : fffffa60`0080d31f fffffa60`01966cc0 00000000`00000000 fffffa60`036dc290 : 0x80 STACK_COMMAND: kb FOLLOWUP_IP: teefer2+602a fffffa60`036dc02a ?? ??? SYMBOL_STACK_INDEX: 13 SYMBOL_NAME: teefer2+602a FOLLOWUP_NAME: MachineOwner MODULE_NAME: teefer2 IMAGE_NAME: teefer2.sys DEBUG_FLR_IMAGE_TIMESTAMP: 4b390a1d FAILURE_BUCKET_ID: X64_0xD1_CODE_AV_BAD_IP_teefer2+602a BUCKET_ID: X64_0xD1_CODE_AV_BAD_IP_teefer2+602a Followup: MachineOwner --------- What should I understand seems to be problem with teefer2.sys how to solve it. I think it is related to symantec Antivirus but not sure. Should I upgrade the version Symantec ?

the problem is from Symantec Endpoint please remove it comlpetely and monitor the server for some days or else contact symantec for more help on the presisting issue. See the same issue with windows 7 clients as well http://www.symantec.com/business/support/index?page=content&id=TECH93491&locale=en_UShttp://www.virmansec.com/blogs/skhairuddin