RepMgr causing high CPU usage on few virtual machines running both 3.9.1.2464 and 4.0.2.1540 sensor version.
The error in sensor logs are as follows:
2024-09-05 06:05:51.173000 2208 INFO CCurlWrapper::SetupHttpLegacyPostForm: set scaled timeout: filename = C:\ProgramData\CarbonBlack\Logs\temp\crash_dumps.zip, size = 2813196508, timeout: 3600000 ms 2024-09-05 06:05:51.206000 2208 INFO CCurlWrapper::DiscoverConnectionInfo: Connection context attributes: Protocol[0x800 : TLS1.2] Cipher[AES_128] CipherStrength[128] Hash[SHA256] HashStrength[0] Exchange[ECDH_EPHEM] ExchangeStrength[255] 2024-09-05 06:05:51.221000 2208 ERROR CCurlWrapper::ProcessHttpStatusCode: handle id: CloudWeightedTask_1522, http err 400 2024-09-05 06:05:51.222000 2208 ERROR RepUtilUploadConferFile: failed to send C:\ProgramData\CarbonBlack\Logs\temp\crash_dumps.zip
Carbon Black Windows Sensor prior to version 4.1
The CPU spike is observed when sensor keeps trying to "zip up" the memory dump (CPU intensive task) and then upload. If upload fails, the zip file is discarded and in its next attempt sensor zips again, which causes CPU spike again. This pre-4.1 is an "infinite try" at certain cadence.
The core issue will be fixed in sensor version 4.2
Changes in Sensor version 4.1:
In 4.1, The upload attempts will be limited to 3 after which this upload will be discarded.
(This upload only takes place when explicitly requested via CSR to pull sensor logs and if endpoint has any memory dump generated in c:\windows).
Version 4.1 will take away infinite retries if memory dump cannot be uploaded.
Workaround:
Workaround is to delete MEMORY.DMP file present under C:\Windows directory.
Note: High CPU usage is only seen if "sensor diagnostic" is pulled from CSR console access. Even if MEMORY.DMP is created but sensor diagnostics are not requested from CSR-Console, the issue will not show up.