Version
Cb Response 4.x, 5.x, 6.x
Topic
This document describes how to collect Cb Response sensor diagnostics when a Blue Screen of Death (BSOD) or a kernel panic occurs on Windows, OS X or Linux.
Check here if one of these solutions fit your issue better:
- Collecting logs for Performance Issues [Sensor - Cb Response]
- Collecting logs for System Hang Issues [Sensor - Cb Response]
- Collecting logs for General Troubleshooting [Sensor - Cb Response]
Steps
Follow steps below for a given OS platform to collect sensor diagnostics to diagnose BSOD/kernel panic issues.
Windows
Note: If a Cb Protection Agent is installed, you may need to disable the Cb Tamper Protect Updater to gain read access to the Diagnostics folder on the Windows platform.
- Answer the following questions in your case:
1. Is this a reproducible scenario and if so, what are the steps to reproduce the BSOD/kernel panic?
a. Was the host performing any special actions when the BSOD/kernel panic occurred? For example, were any backups, or large file transfers being performed?
2. How many systems are affected?
3. If this is affecting multiple systems is there anything in common between them such as OS, sensor version, function (ex. Web Server, Database Server,NFS)?
4. Are there any other security applications/real-time scanners installed?
a. If so, can you verify that sensor exclusions in place? Anti-Virus Exclusions for Cb Response Sensor
b. Is the Cb Protection (bit9) Agent installed, and if so, what version?
c. Is the Cb Defense (confer) Sensor installed, and if so, what version? - Follow the Operating System vendor's Instructions to configure a memory dump:
Note: By default, a Windows system is configured to only save a mini-dump memory file when a BSOD occurs. This may not be enough to diagnose and resolve the issue. Either a kernel (minimal) or a complete (preferred) memory dump is requested
- Enable Enable verbose logging of the Cb Response sensor service
Warning: Be careful the additional logging does not fill up disk - If the BSOD is random or its trigger is unknown, you will have to wait for the BSOD to occur. If you're able to readily reproduce, go through appropriate steps to cause the BSOD
- Once the system reboots, compress the c:\Windows\memory.dmp file (default location for memory dump files)
- Diagnostic utility to collect Carbon Black endpoint logs
IMPORTANT: when complete, don't forget to remove verbose logging
- Export the Application and System logs from Windows Event Viewer (in .evt or .evtx format): How to Export Windows Event Logs
- Send the compressed memory.dmp, sensor diagnostics (tgz archive), Application and System Windows Event logs using instructions in the Uploading Files section below
MacOS
- Answer the following questions in your case:
1. Is this a reproducible scenario and if so, what are the steps to reproduce the BSOD/kernel panic?
a. Was the host performing any special actions when the BSOD/kernel panic occurred? For example, were any backups, or large file transfers being performed?
2. How many systems are affected?
3. If this is affecting multiple systems is there anything in common between them such as OS, sensor version, function (ex. Web Server, Database Server,NFS)?
4. Are there any other security applications/real-time scanners installed?
a. If so, can you verify that sensor exclusions in place? Anti-Virus Exclusions for Cb Response Sensor
b. Is the Cb Protection (bit9) Agent installed, and if so, what version?
c. Is the Cb Defense (confer) Sensor installed, and if so, what version? - Run the following command in a terminal session:
sudo /Applications/CarbonBlack/sensordiag.sh - This will create an archive of logs in the current working directory with the sensordiag_(hostname)_(date).tgz filename format
- Send the sensordiag_(hostname)_(date).tgz file using instructions in the Uploading Files section below
Linux
- Answer the following questions in your case:
1. Is this a reproducible scenario and if so, what are the steps to reproduce the BSOD/kernel panic?
a. Was the host performing any special actions when the BSOD/kernel panic occurred? For example, were any backups, or large file transfers being performed?
2. How many systems are affected?
3. If this is affecting multiple systems is there anything in common between them such as OS, sensor version, function (ex. Web Server, Database Server,NFS)?
4. Are there any other security applications/real-time scanners installed?
a. If so, can you verify that sensor exclusions in place? Anti-Virus Exclusions for Cb Response Sensor
b. Is the Cb Protection (bit9) Agent installed, and if so, what version?
c. Is the Cb Defense (confer) Sensor installed, and if so, what version? - If the /var/crash directory does not have the recent crash dump, you will need to prepare your system for collecting a crash dump prior to reproducing the kernel panic.
Note: Please refer to the Operating System vendor's instructions. For example, Chapter 30 of the Red Hat Deployment Guide has the instructions on installing and configuring the kdump service for RHEL 6
- Once kdump is configured, reproduce the kernel panic or wait for one to occur before proceeding
- Run the following command in a terminal session as root:
/opt/cbsensor/sensordiag.sh - This will create an archive of logs in the current working directory with the sensordiag_(hostname)_(date).tgz filename format and will include the /var/crash directory
- If possible, take a VM Snapshot while it is running and collect the .vmsn file
Note: if the .vmsn file is small (~1.5MB), this means the VM is configured to store the memory in a separate file. If so, please also send the .vmem file
- Send the sensordiag_(hostname)_(date).tgz and .vmsn/.vmem file(s) using instructions in the Uploading Files section below
Uploading Files
If under 25 MB, files can be attached to your case. Otherwise upload the collected data at Cb Vault
Thank you for your feedback.
Your feedback has been submitted and will be reviewed.