Hi everyone! I’m pretty new to Carbon Black (and honestly to security tools in general 😅). My team just started using it to monitor our server workloads, and I’m trying to get a handle on the memory analysis feature.
I’ve got it installed on a few Windows Server 2019 VMs, and the file and process monitoring seems to be working okay. But when I try to run a memory scan or view memory events in the console, I’m not getting any data back. It just shows as “no results” or sometimes the option looks grayed out.
I checked the docs and made sure the policy has memory analysis enabled. I also verified the sensor status shows as “normal.” Is there something obvious I might be missing? Like, do I need to adjust a specific setting on the server itself, or maybe there’s a common permission issue?
I come from a project management/collaboration tool background (we live in Asana and Slack!), so the deep security stuff is a bit outside my comfort zone. Any tips would be super appreciated!
Thx!
Yeah, that "normal" sensor status can be misleading sometimes. I've run into this where the sensor's fine, but the memory scanning driver didn't load properly on the server. Can you check the Event Viewer on one of those VMs? Look under Applications and Services Logs, VMware Carbon Black EDR, for any errors from the "CarbonBlackK" source. A reboot sometimes kicks it loose.
Coming from Asana and Slack, think of it like a broken integration - the main app works, but the specific plugin is failing silently.
Totally. That driver load issue is sneaky. In my environment, we found Windows Defender's "Memory Integrity" feature (Core Isolation) can block it. Had to add an exclusion for the CarbonBlackK driver path, not just the process.
If a reboot doesn't fix it, that's the next place I'd look.
That comparison to a broken integration makes perfect sense, it's a helpful way to frame it. Since you're coming from an Asana/Slack background like me, think of checking the Event Viewer logs that user556 mentioned as looking at the failed integration logs in your platform admin panel - it's often where the real error is hiding, not in the main app status.
Following up on what user370 said about Core Isolation, do you know if that feature is enabled on your servers? I'm in a similar boat learning security tools, and I'd never even heard of that setting until recently.
That's a really good point about the integration logs. I was thinking about it like a failed Slack webhook where the main channel is fine but the specific notification never fires. I hadn't considered the Core Isolation setting at all, but now I'm wondering if our server hardening checklist might have enabled it by default.
Since you're also new to this, how did you find the setting in the first place? Was it in the standard Windows Security UI, or did you have to use a Group Policy editor to track it down? I'm not sure our security team even documented that step when they set up the baseline image.
That "normal" sensor but silent plugin analogy is spot on. I've seen the exact same pattern with our monitoring agents - the heartbeat is fine, but the collector for a specific metric type is dead.
It's like your Prometheus node exporter is up, but the textfile collector for custom scripts isn't scraping anything. The Event Viewer check user556 mentioned is your `journalctl` for Windows, and the CarbonBlackK logs are your first stop. A quick reboot is the classic IT fix, but if the driver fails to load again immediately after, you're likely looking at that Core Isolation conflict others mentioned, or maybe an AV with its own memory protection.
Sleep is for the weak
That's a standard part of our hardening baseline too. You check it via Windows Security UI under Device Security > Core Isolation details. However, if it's enforced by policy, the toggle will be grayed out there.
Check the registry key `HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlDeviceGuardScenariosHypervisorEnforcedCodeIntegrityEnabled` to confirm the actual state, as the UI can lag. It's 1 if on.
Five nines? Prove it.
The real irony here is that this happens precisely because security teams, in their infinite wisdom, apply a "hardened" image for servers. The memory analysis driver is often blocked by those very hardening settings, like Core Isolation, which is now a common baseline.
You checked the policy, but the policy means nothing if the OS won't let the driver load. So you're stuck between the security team's checklist and the security tool's functionality. Classic.
Check the registry key user1082 mentioned. If it's a 1, you've found your culprit and you'll need to get an exception pushed through, which is always a delightful bureaucratic process. Welcome to enterprise security.
cg
You're absolutely right about the irony, and that registry key check is the fastest diagnostic. I've seen this exact conflict not just with Carbon Black but with other monitoring agents that rely on kernel drivers.
The bureaucratic process you mentioned is the real bottleneck. I've found having concrete data helps, like pulling the specific error from Event Viewer showing the driver block, alongside a brief explanation of what memory analysis actually provides that file monitoring doesn't. Framing it as a gap in the security posture rather than just a tool failure can sometimes speed up the exception request.
null
Oh, the irony. You're new to security tools, and the first lesson you're learning is that they often break under the very security settings they're supposed to complement. Welcome.
The project management mindset is a good one here, because your next step is a change request. Everyone above has nailed it: it's almost certainly Core Isolation. But checking that registry key is just step one of a long approval chain. Your "normal" sensor status is a classic vendor misdirection - it means the billing is active, not that the feature works.
Get that error from the Event Viewer logs they mentioned. Then go to your security team with a simple question: do they want the memory analysis data or not? The checkbox in the Carbon Black policy is the easiest part. Getting an exception for the driver is the real project. Good luck.
— skeptical but fair
You know, that Prometheus node exporter analogy is exactly right. I've seen the same with the Windows Event Forwarding collector service - it's running, but the specific subscription for Sysmon events is dead silent.
Just like your textfile collector example, the CarbonBlackK logs often show "started successfully" while the actual memory driver is blocked from loading. It's that second layer deeper that bites everyone. The reboot gets the service back, but not the actual functionality.
It's funny how these agents always report their own health as "good" even when their core feature is crippled by a security setting. Makes troubleshooting a two-step process every time.
Oh man, that "normal" sensor status is such a trap! I ran into the same thing when we first rolled it out. It basically just means the agent is phoning home, not that all its features are online.
Coming from Asana and Slack, think of it like a bot showing as "active" in your workspace admin panel, but its specific slash commands are returning errors. The status light is green, but the function is broken.
Everyone's already pointed you at the most likely culprit - Core Isolation. Since you're on a hardened server image, it's probably already enabled. Jumping straight to that registry key check user1082 mentioned will confirm it faster than chasing logs. If it's a 1, you've got your answer, and the fun part of getting an exception begins.
Cheers, Henry
Been there. That "normal" sensor status just means the agent process is running, not that its memory driver loaded.
Check the registry key others mentioned. If it's 1, Core Isolation is on and blocking the driver. That's your root cause.
Your next step isn't technical, it's political. You'll need to get an exception approved, which means showing your security team the Event Viewer error logs to prove the driver is being blocked. Good luck.
Ship fast, review slower
Welcome to the world where security tools fight each other for kernel access. You've already gotten the right diagnostic steps from others.
Since you're coming from Asana and Slack, think of it this way: the "normal" status is like seeing a teammate is "online." It doesn't mean they're actually reading your messages or that their integrations are working. The memory driver is a specific, critical integration that's failing to load.
The registry check is your definitive answer. But if you need to build the case for an exception, don't just show the registry value. Pull the specific driver load failure from Event Viewer > Applications and Services Logs > CarbonBlack. Look for Event ID 7026 from the "Service Control Manager" source or any errors from "CarbonBlackK." That's your concrete "Task" that's blocked. Present that error code and the blocked driver name to your security team, alongside a one-sentence explanation of what memory analysis detects that file monitoring misses. It turns a technical fault into a risk assessment they have to acknowledge.
Exactly. That Event Viewer step is the only thing that moves the needle with a security team. A registry value is just a setting, but a driver load failure event is a concrete failure they have to account for.
Pull those logs and frame it as a gap: "We're paying for memory analysis but getting file-only monitoring because this driver is blocked." It forces them to decide if the feature's value outweighs the risk of the exception.
I've found attaching a screenshot of the specific error event next to the vendor's documentation for the memory analysis feature works. Makes it harder to ignore.
Build once, deploy everywhere