A reported performance issue is apparently resolved when Symantec Endpoint Protection's (SEP) AutoProtect is disabled. A Process Monitor (ProcMon) log is gathered as part of the troubleshooting, but AutoProtect events are not captured. Can this be overcome?
Microsoft Windows operating systems
Because both ProcMon and AutoProtect are minifilters, the configuration for AutoProtect will need to change slightly to ensure that ProcMon sees all of AutoProtect’s input/output events. By default AutoProtect is loaded below ProcMon so it doesn't see the AutoProtect scan I/O.
If disabling AutoProtect resolves a performance-based issue, then gather a ProcMon log when AutoProtect is disabled and a second log when AutoProtect is enabled.
Please note that very large amounts of data will be collected: if possible capture only the events that occur during the slow-down. Also note that Tamper Protection may need to be disabled to make registry changes.
To load AutoProtect above ProcMon:
1. In regedit, change the following value Key :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SRTSP\Instances\SRTSP
Value name: Altitude
New value : 385300
2. Reboot. You can verify that the SRTSP altitude has been changed by running the FLTMC command--
e.g:
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
FSLX 429998.99 <Legacy>
symsnap 429998.99 <Legacy>
Pgpwdefs 2 370400 1
BHDrvx64 2 365100 1
eeCtrl 2 329010 1
SRTSP 3 385300 1
vfsmfd 4 263410 1
SymEFA 3 260600 1
pgpfs 149998.99 <Legacy>
luafv 1 135000 0
FileInfo 3 45000 0
3. Start ProcMon
4. Reproduce the issue
5. Save the Log as Native Process Monitor Format (PML)
To restore AutoProtect to its normal altitude:
1. In regedit, change the following value Key :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SRTSP\Instances\SRTSP
Value name: Altitude
New value : 329000
2. Reboot
When examining the ProcMon logs, what to look for?
AutoProtect queries file information frequently to get file attributes, size, and times. It is usually a very quick operation. Look for queries that take a long time to complete; that will mean a thread is stuck, occupied or tied up.
To see these long events in the procmon log do the following:
Note: It may also be necessary to gather logs from remote computers with which the computer being analyzed was communicating, if the cause of delay is suspected to be network-related.
References
Sysinternals / Microsoft page on Process Monitor: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Sysinternals / Microsoft page on Process Explorer: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx