Endpoint Protection

Hello,

One of our DC's is crashing with BSOD, it currently has SEP 11 on it and we understand that SEP 12 should fix the issue, hence we are moving towards upgrading to the latest release of SEP.  However, looking at the below bugcheck analysis, it looks like its the teefer driver, why would the teefer driver cause this even with SEP 11?

kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

BAD_POOL_CALLER (c2)

The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.

Arguments:

Arg1: 0000000000000007, Attempt to free pool which was already freed

Arg2: 0000000000001097, (reserved)

Arg3: 00000000044f000d, Memory contents of the pool block

Arg4: fffffa80130284d0, Address of the block of pool being deallocated

Debugging Details:

------------------

GetUlongFromAddress: unable to read from fffff80001e37210

POOL_ADDRESS:  fffffa80130284d0

BUGCHECK_STR:  0xc2_7

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff80001dc3be9 to fffff80001c99640

STACK_TEXT: 

fffff880`029245c8 fffff800`01dc3be9 : 00000000`000000c2 00000000`00000007 00000000`00001097 00000000`044f000d : nt!KeBugCheckEx

fffff880`029245d0 fffff880`010e1195 : fffffa80`1302a010 fffffa80`13028600 fffff880`01e64180 fffffa80`1302a010 : nt!ExDeferredFreePool+0x1201

fffff880`02924680 fffff880`0426479b : fffffa80`130284d0 fffffa80`296b01a0 fffff880`02924710 fffffa80`130284d0 : NDIS!NdisFreeMemory+0x15

fffff880`029246b0 fffffa80`130284d0 : fffffa80`296b01a0 fffff880`02924710 fffffa80`130284d0 fffffa80`297f2cf0 : teefer2+0x379b

fffff880`029246b8 fffffa80`296b01a0 : fffff880`02924710 fffffa80`130284d0 fffffa80`297f2cf0 fffff880`0118273b : 0xfffffa80`130284d0

fffff880`029246c0 fffff880`02924710 : fffffa80`130284d0 fffffa80`297f2cf0 fffff880`0118273b fffffa80`1302a010 : 0xfffffa80`296b01a0

fffff880`029246c8 fffffa80`130284d0 : fffffa80`297f2cf0 fffff880`0118273b fffffa80`1302a010 fffffa80`296b01a0 : 0xfffff880`02924710

fffff880`029246d0 fffffa80`297f2cf0 : fffff880`0118273b fffffa80`1302a010 fffffa80`296b01a0 fffffa80`297f2cf0 : 0xfffffa80`130284d0

fffff880`029246d8 fffff880`0118273b : fffffa80`1302a010 fffffa80`296b01a0 fffffa80`297f2cf0 fffffa80`1302a010 : 0xfffffa80`297f2cf0

fffff880`029246e0 fffff880`01181c82 : fffffa80`1302a010 00000000`00000000 00000000`00000008 00000000`00000000 : NDIS!ndisUnbindProtocol+0x21b

fffff880`029247f0 fffff880`010f9aaf : fffffa80`00000000 00000000`00000000 fffffa80`296b0f00 fffff880`0117a401 : NDIS! ?? ::LNCPHCLB::`string'+0x631c

fffff880`02924960 fffff880`010eb825 : fffffa80`296b01a0 fffffa80`296b01a0 fffffa80`296ac1a0 fffffa80`296b01a0 : NDIS! ?? ::FNODOBFM::`string'+0xb474

fffff880`02924bb0 fffff880`0117b089 : fffffa80`296b0101 fffffa80`2963a9b0 fffff880`0113c110 fffffa80`296b41a0 : NDIS!ndisCheckMiniportFilters+0x125

fffff880`02924bf0 fffff880`010e9a2a : 00000000`00000080 fffff880`0113c110 fffffa80`297f2e30 00000000`00000000 : NDIS!ndisCheckProtocolBindings+0x12e

fffff880`02924d10 fffff800`01f36cce : fffffa80`12b55b60 fffffa80`127e4040 fffffa80`127e4040 00000000`00000000 : NDIS!ndisWorkerThread+0xba

fffff880`02924d40 fffff800`01c8afe6 : fffff880`01e64180 fffffa80`12b55b60 fffff880`01e6f2c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a

fffff880`02924d80 00000000`00000000 : fffff880`02925000 fffff880`0291f000 fffff880`029241f0 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND:  kb

FOLLOWUP_IP:

teefer2+379b

fffff880`0426479b ??              ???

SYMBOL_STACK_INDEX:  3

SYMBOL_NAME:  teefer2+379b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: teefer2

IMAGE_NAME:  teefer2.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a0b1ec0

FAILURE_BUCKET_ID:  X64_0xc2_7_teefer2+379b

BUCKET_ID:  X64_0xc2_7_teefer2+379b

Followup: MachineOwner

---------

2: kd> lmvm teefer2

start             end                 module name

fffff880`04261000 fffff880`04287000   teefer2  T (no symbols)          

    Loaded symbol image file: teefer2.sys

    Image path: teefer2.sys

    Image name: teefer2.sys

    Timestamp:        Wed May 13 14:25:52 2009 (4A0B1EC0)

    CheckSum:         00018CF0

    ImageSize:        00026000

    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

What version of 11.x is this? There may have been a bug in that version.

Did you add the necessary exclusions since it is a DC?

Your best bet is to get a full dump and submit to Symantec support for full analysis. Also, you don't necessarily need to go to SEP 12.1 but Symantec will recommend to go to the latest version of 11.x (RU7 MP3) if you are not already on it.

For reference, check this KB article out:

Best Practices for Installing Symantec Endpoint Protection (SEP) on Windows Servers

About the automatic exclusion of Active Directory files and folders

Its version 11.0.5002.333, I will take a look at those articles.  Thank you for your quick response.

I do know this version did have issues related to the teefer driver. I bet upgrading to 11.0.6 would fix it but your best bet is to either go to latest version of 11.x or 12.1 if you can.

It wouldn't even be worth opening a case because they will tell you to upgrade. You can remove NTP as a workaround until you can get it upgraded.

There was a know issue for teefer causing blue screens fixed in RU6 MP2:

Hi

Which components are installed in SEP client

Regards