When an application crashes on an system that is also running the SEP client, the SEP client is provided meta data about the crash from Windows Error Reporting on that system. We then make an entry in our /queue directory, and send that information over to our SymQual servers, which helps us identify if this application is crashing due to anything related to Symantec, and based on the information allowed to be sent to Symantec. However, this information is still "held" by SEP, even if you do not choose to submit data to our SymQual servers. Normally, we will clean out the directory, but if an application begins crashing in rapid succession, it will "choke" the SEP client, and it cannot process such a large amount of data in a single sitting, and the files will begin to build up.
To fix this issue with SEP, there are only two options I have found that resolve this. The first, is to repair the application that is crashing, which should help the SEP client process the data going forward. Or, you can setup an exclusion rule for the application within Windows Error Reporting, and this will stop Windows from sending the meta data of the crash to the SEP client. You can setup WER exceptions through the steps provided here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb513638(v=vs.85).aspx From the article, the exact entry would be something like: ExcludedApplications\[Application Name] REG_SZ
Use WerAddExcludedApplication <https://msdn.microsoft.com/en-us/library/windows/desktop/bb513617(v=vs.85).aspx>
List of excluded applications
By adding the Connect.Service.ContentService.exe to the exclusion list in WER, that should greatly reduce the buildup you are seeing in SEP.
Subscribing will provide email updates when this Article is updated. Login is required.