BugCheck 0xC2 on a 32-bit system with a pre-12.1 RU5 version of Endpoint Protection

book

Article ID: 170026

calendar_today

Updated On:

Products

Endpoint Protection

Issue/Introduction

You experienced a Bug Check 0xC2 (BAD_POOL_CALLER) on a 32-bit Windows system with Symantec Endpoint Protection (SEP) 12.1 (pre-RU5) with the "Virus, Spyware and Basic Download Protection" feature only (Advanced Download Protection is not enabled).

An analysis of the resulting dump using the Windows Debugger (WinDBG) shows that the issue occured when it was attempted to free pool memory that had already been freed. You further determine the following in WinDBG:

  • Dereferencing the address of the block of pool being deallocated (argument 4) using the !pool command shows it is related to pool tag HTab. which belongs to NETIO.SYS (Microsoft's Network I/O Subsystem driver). lmvm netio shows the version of NETIO.SYS currently installed on the server is several years old.
  • The virtual memory usage overview (!vm 1) shows a large amount of pool failures. 
  • Using the command dd nt!MmPoolFailures l?9 you determine that these are non-paged pool failures (i.e. the output of the command shows a large amount of failures in the first three bytes, with no or very little failures in the next two three byte blocks).
  • The top 5 of non-paged pool consumers (!poolused /t 5 2) shows a similarly large amount of allocations for pool tag SNDc.
  • Using the command !for_each_module s -a @#Base @#End "SNDc" and then lma with one of the resulting addresses as a parameter you find that the pool tag belongs to SymTDIv (our Symantec Network Dispatch driver).

*******************************************************************************
*                                                                             *
*                        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: 00000007, Attempt to free pool which was already freed
Arg2: 0000110b, (reserved)
Arg3: a0e6cdb8, Memory contents of the pool block
Arg4: 88e64760, Address of the block of pool being deallocated

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

[...]

STACK_TEXT:  
81d3df5c 81d36184 000000c2 00000007 0000110b nt!KeBugCheckEx+0x1e
81d3dfd4 9b2c6991 88e64760 00000000 81d3dffc nt!ExFreePoolWithTag+0x17f
WARNING: Stack unwind information not available. Following frames may be wrong.
81d3dfe4 9b2c8e31 88e64760 d903a88f d903a7f8 SYMTDIV+0x1a991
81d3dffc 81cf021b 00000000 d903a7f8 a3c5477c SYMTDIV+0x1ce31
81d3e034 9b2a0f38 d903a850 bd5ec434 00000103 nt!IopfCompleteRequest+0x11d
81d3e0f8 9b2a12e2 d903a838 00000000 00000010 tdx!TdxQueryAddressComplete+0x1ba
81d3e158 9b29cdfb 015ec340 d903a838 00000000 tdx!TdxIssueQueryAddressRequest+0x250
81d3e178 9b2a1b01 bd5ec302 d903a7f8 d903a88c tdx!TdxQueryInformationConnection+0x6d
81d3e194 81c8d976 8c0c4440 d903a7f8 d903a7f8 tdx!TdxTdiDispatchInternalDeviceControl+0x10b
81d3e1ac 9b2c92d0 00000000 a3c5477c 8d3e2220 nt!IofCallDriver+0x63
81d3e1c4 9b2ade2b 8e143028 8c0c4440 00000000 SYMTDIV+0x1d2d0
81d3e1e4 81cf021b 8c0fb438 c8a76e00 8d3e2220 SYMTDIV+0x1e2b
81d3e218 9b29c0db 81d3e29c 8e2c2de0 8e2c2de0 nt!IopfCompleteRequest+0x11d
81d3e23c 9b299932 005ec340 8e2c2d00 81d3e29c tdx!TdxEventConnectConnection+0x301
81d3e264 9128b41c 8e2c2de0 81d3e202 17e16d9e tdx!TdxEventConnectTransportAddress+0x11a
81d3e304 9124ddc2 f37ec7f0 81d3e370 912504ef tcpip!TcpCreateAndAcceptTcbComplete+0x13e
81d3e310 912504ef f37ec7f0 81d3e464 f37ec7f0 tcpip!TcpSynchronizeTcbDelivery+0x36
81d3e370 9126990c 89521d00 f37ec7f0 81d3e394 tcpip!TcpTcbCarefulDatagram+0x986
81d3e3d4 9129cc14 89521d00 017ec7f0 81d3e464 tcpip!TcpTcbReceive+0x1bb
81d3e404 91267e3a 89521d00 10010748 81d3e464 tcpip!TcpSynTcbReceive+0x251
81d3e458 91269695 89521d00 89545000 00000000 tcpip!TcpMatchReceive+0x3ba
81d3e4a0 912696fb 89521d00 89545000 89545010 tcpip!TcpPreValidatedReceive+0x22d
81d3e4bc 91268086 89521d00 89545000 81d3e4f8 tcpip!TcpReceive+0x2d
81d3e4cc 91280328 81d3e4e0 c000023e 00000000 tcpip!TcpNlClientReceiveDatagrams+0x12
81d3e4f8 9127fd10 912d8ebc 81d3e54c c000023e tcpip!IppDeliverListToProtocol+0x49
81d3e518 91280199 912d8cd0 00000006 81d3e54c tcpip!IppProcessDeliverList+0x2a
81d3e570 912819c9 912d8cd0 00000006 912d8cd0 tcpip!IppReceiveHeaderBatch+0x1eb
81d3e600 912ada83 8c1a0230 00000000 00000001 tcpip!IpFlcReceivePackets+0xbe1
81d3e680 9127d76a 8c1a0230 89fae0a8 81d2c86f tcpip!IpFlcReceivePreValidatedPackets+0x487
81d3e69c 822d60b0 8c17ecf8 00000000 00000000 tcpip!FlReceiveNetBufferListChain+0xe1
81d3e6d0 822c8d25 001a2c50 89fae0a8 00000000 NDIS!ndisMIndicateNetBufferListsToOpen+0xab
81d3e6f8 822c8c9c 00000000 8bfc4528 8c194918 NDIS!ndisIndicateSortedNetBufferLists+0x4a
81d3e874 8220957f 897220e8 00000000 00000000 NDIS!ndisMDispatchReceiveNetBufferLists+0x129
81d3e890 82234ccd 897220e8 89fae0a8 00000000 NDIS!ndisMTopReceiveNetBufferLists+0x2c
81d3e8ac 82234ca4 8c169c10 89fae0a8 00000000 NDIS!ndisFilterIndicateReceiveNetBufferLists+0x20
81d3e8c8 9b3db553 8c169c10 89fae0a8 00000000 NDIS!NdisFIndicateReceiveNetBufferLists+0x1b
81d3e934 822c88f9 8c194918 89fae0a8 00000000 nm3!NetmonReceiveNetBufferLists+0x1b3
81d3e950 8220954a 897220e8 89fae0a8 00000000 NDIS!ndisMIndicateReceiveNetBufferListsInternal+0x27
81d3e96c 90fccf57 897220e8 89fae0a8 00000000 NDIS!NdisMIndicateReceiveNetBufferLists+0x20
81d3e9e4 822d60b0 8c04d008 89fae0a8 00000000 cpqteam+0x7f57
81d3ea18 822c8bef 0004ca48 89fae0a8 00000000 NDIS!ndisMIndicateNetBufferListsToOpen+0xab
81d3eba4 8220957f 896bb0e8 8c04ca48 00000000 NDIS!ndisMDispatchReceiveNetBufferLists+0x7c
81d3ebc0 822c88f9 896bb0e8 89fae0a8 00000000 NDIS!ndisMTopReceiveNetBufferLists+0x2c
81d3ebdc 8220954a 896bb0e8 89fae0a8 00000000 NDIS!ndisMIndicateReceiveNetBufferListsInternal+0x27
81d3ebf8 9133b252 896bb0e8 89fae0a8 00000000 NDIS!NdisMIndicateReceiveNetBufferLists+0x20
81d3ec40 9133582d 01d8a000 00000000 00000000 e1e6032+0x7252
81d3ec74 91335acf 00d8a000 89d8e000 81d3ec9c e1e6032+0x182d
81d3ec84 91335b6a 89d8a000 00000000 00000000 e1e6032+0x1acf
81d3ec9c 822c81fd 89d8a000 00000000 00000000 e1e6032+0x1b6a
81d3ecc4 82209468 89d8ee18 91335b50 00000000 NDIS!ndisMiniportDpc+0x7a
81d3ece8 81cf36e2 89d8ee18 896bb0e8 00000000 NDIS!ndisInterruptDpc+0xc4
81d3ed50 81cf189d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x147
81d3ed54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x49

[...]

Environment

SEP 12.1 (pre-RU5)

Resolution

As SYMTDIv is not required when using the "Virus, Spyware and Basic Download Protection" feature only, it can be disabled using the command sc config symtdiv start= disabled, followed by a reboot of the server.

If this should not resolve the issue, it is recommended to update NETIO.SYS to the latest ((June 5, 2017) version, by first installing the hotfix provided by https://support.microsoft.com/en-ie/help/2664888/computer-stops-responding-when-you-run-an-application-that-uses-the-wi and then Windows Security Update https://support.microsoft.com/en-ie/help/4022748/windows-kernel-information-disclosure-vulnerability. Only installing the security update might cause the GDR version of the same to be installed, which only contains select fixes.