A system randomly hangs after an upgrade to 14 MP2


Article ID: 170013


Updated On:


Endpoint Protection


To resolve the SEP 14 MP1 causes random hangs on servers and desktops issue, you upgrade Symantec Endpoint Protection (SEP) 14 or 14 MP1 to 14 MP2, only to find that the issue continues to occur.
You generate a complete memory dump and open it in the Windows Debugger. After issuing the !locks command, you find there are resource locks for symefasi (our Extended File Attributes driver), SYMEVENT64x86 (our Symantec Event Library driver) and SRTSP64 (our AutoProtect driver). Using !locks -v to dump the threads of the SRTSP64 resource, you find a number of threads that start with srv2 (Microsoft's SMB 2.0 Server driver) and end with several SRTSP64 function calls.

Child-SP          RetAddr           Call Site
fff802`b1d18419 nt!KiSwapContext+0x76
fff802`b1d15a1d nt!KiCommitThreadWait+0x229
fff880`01cb6312 nt!KeWaitForMultipleObjects+0x25d
fff880`01cb3bd0 SRTSP64
fff880`01c5eccc SRTSP64
fff880`01c54c2d SRTSP64
fff880`01c67c5b SRTSP64
fff880`01c685ff SRTSP64
fff880`01c33a22 SRTSP64
fff880`01402ed3 SRTSP64
fff880`0140465e fltmgr!FltpPerformPostCallbacks+0x2b3
fff880`0140361b fltmgr!FltpPassThroughCompletionWorker+0x7e
fff880`0142d35d fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x38b
fff802`b20c1d58 fltmgr!FltpCreate+0x34d
fff802`b20e231a nt!IopParseDevice+0x173c
fff802`b20be2af nt!IopParseFile+0xb6
fff802`b20c34a8 nt!ObpLookupObjectName+0x6e4
fff802`b20d526e nt!ObOpenObjectByName+0x258
fff802`b209f697 nt!IopCreateFile+0x37c
fff880`0793cd26 nt!IoCreateFileEx+0x107
fff880`0793c59d srv2+0x47d26
fff880`0794006c srv2+0x4759d
fff880`0793a360 srv2+0x4b06c
fff880`07938180 srv2+0x45360
fff802`b1cea3a7 srv2+0x43180
fff802`b1cea36d nt!KxSwitchKernelStackCallout+0x27 (TrapFrame @ fffff880`0bafae40)
fff802`b1d3171e nt!KiSwitchKernelStackContinue     
fff802`b1d32405 nt!KeExpandKernelStackAndCalloutInternal+0x20e
fff880`078f6d35 nt!KeExpandKernelStackAndCalloutEx+0x25
fff802`b1d28c81 srv2+0x1d35
fff802`b1c98f05 nt!ExpWorkerThread+0x142
fff802`b1cd6516 nt!PspSystemThreadStartup+0x59
fff880`12130da0 00000000`00000000 nt!KiStartSystemThread+0x16


A thread acquires a scan shim lock for read access, while at the same time a definitions update thread asks for write access. When it is attempted to get read access again through a different scan shim function, it causes that access to be blocked due to the pending write lock acquisition, resulting in a hang.


SEP 14 MP2


This issue has been resolved in SymScan, in SEP 14 RU1.