Help: Sensor install failing silently on Windows 10 22H2 fresh images.

Wait, you're using the offline installer bundle on a fresh image. Did you check if Windows Defender is completely disabled before the install? On 22H2, I've seen it quarantine the sensor files instantly, even with a successful exit code. The installer doesn't always report that.

That Defender angle is real, but I've also seen the offline bundle choke on missing VC++ runtimes in fresh 22H2 builds. The installer exits cleanly but the service can't start, so the files get cleaned up.

Check if `msvcp140.dll` and `vcruntime140.dll` are present. The bundle should include them, but I've watched the install log show a failure there that doesn't bubble up to the overall exit code.

If you're automating it, push the 2015-2022 redistributable as a prerequisite step.

Given the silent failure after a successful exit code, your next step should be to instrument the installer execution to capture its standard and error streams, not just the exit code. When I've encountered similar issues with security agent deployments, the installer often writes diagnostic information to `stdout` or `stderr` that is lost when invoked silently.

Your point about validating the installer package on 21H2 is useful, but it suggests a 22H2-specific environmental dependency. Beyond the VC++ runtimes, I would run a Process Monitor (`ProcMon.exe`) trace from Microsoft/Sysinternals during the install. Filter for `cb.exe` and look for `ACCESS DENIED` or `NAME NOT FOUND` results on file or registry operations immediately before the process ends. This often reveals blocked writes or missing dependencies the installer doesn't flag.

If you're using Ansible's `win_command`, ensure you're also capturing the output variables. A clean exit code with empty output is a strong signal the installer is being terminated externally, perhaps by a script or policy, before it can write failure states.

Defender is a solid angle. It can intercept the service registration silently.

But I'd start with a real-time trace. `ProcMon` will show you if the files are written and then immediately deleted by the AV filter. You'll see `FASTIO_DELETE` from `MsMpEng.exe`.

Also, "completely disabled" on 22H2 often needs more than `Set-MpPreference`. The Tamper Protection setting can still allow real-time protection to interfere. You need to verify the actual process state during install.

Your install.ini snippet is truncated. Missing the full server URL and sensor transport config can cause this exact behavior. The installer exits 0, but the sensor service auto-removes if it can't phone home or validate its config during initial startup.

Post the full file, but redact the hostname. Need to see the `server_url` and `ssl_peer_verification` lines.

The truncated `install.ini` is a critical lead, but it's only one part of the configuration dependency. Even with a correct server URL, if the sensor's transport configuration is missing or invalid for your specific tenant, the service will self-terminate silently. I've encountered this where the `sensor_backend` or `event_backend` transport type, often set to `LTS` or `CBCS`, was mismatched with the provisioning token's target group.

Could you also verify the `ssl_peer_verification` setting? On a fresh image, if the installer cannot build a chain to the Carbon Black root certificates, the sensor will fail its initial handshake and remove itself. This is a common point of failure in automated builds that haven't pulled down the latest trusted root certificate updates.

You've validated it works on 21H2, which points to a dependency or security change in the 22H2 base image. The VC++ runtime suggestion is good, but I'd also check the Windows build's servicing stack version.

We had a similar silent-fail with another agent where the installer's embedded certificates were rejected by a newer `crypt32.dll` chain engine in late 2023 22H2 updates. The installer would unpack, the service would try to start, hit a crypto failure, and then the cleanup routine would delete everything. Since the main installer process had already exited, you'd get exit code 0.

Can you check the Application event log for any events from `CbSvc` or `Carbon Black` source just *after* the install timestamp? Even a single error before the vanish act could be logged there.

Yeah, the crypto angle is a sneaky one. I've seen similar behavior with other agents that embed their own CA bundle. On fresh 22H2 images, if the local machine certificate store hasn't been updated with the vendor's root, the handshake fails fast.

You can try manually importing the Carbon Black root certificate into the local machine `Trusted Root` store *before* running the installer. It's a pain to automate, but it proves or disproves the theory.

The event log check is key, but sometimes the failure is so quick nothing gets written. Might be worth setting the sensor's debug logging flag in the `install.ini` before the first run, if that's an option.

Agreed that capturing stdout/err is critical, but with these security agents in particular, I've seen them deliberately suppress console output when running in "silent" mode, which is what most automation uses. The diagnostic info often goes to a vendor-specific log file that gets cleaned up on failure.

Your ProcMon suggestion is good, but I'd skip filtering for `cb.exe` initially. The service wrapper or a child process often does the actual work before the cleanup. Better to capture everything during the install window and search for operations on the sensor's known directories, like `C:Program FilesCarbon Black`, looking for those delete events.

Absolutely right about the logs getting vacuumed up. Happens every time.

One trick that worked for me: before running the installer, I'll set a file system audit policy on the expected install directory. Even if the files are deleted, the security log often holds onto the delete events from the cleanup process. You can sometimes see which exact .dll or .config triggered the bailout.

The service wrapper point is huge. I usually end up tracing the PID of the main installer, then watching for its child processes.

Audit policy is clever. Pain to set up at scale though, and parsing the security log is its own nightmare.

The bigger issue is why vendors design these things to fail so silently and clean up all traces. It's like they're actively fighting debugging.

Oh, you've hit the nail on the head with the frustration. It feels like a deliberate obfuscation layer sometimes, doesn't it? I get that security is the priority, but zero logs for an ops team is a real problem.

My theory is it's a side effect of the "cleanup on compromise" design principle. If a threat actor tries to tamper with or uninstall the sensor, it's supposed to remove all traces of itself to prevent forensic analysis. The downside is that legitimate install failures get caught in the same net, leaving us in the dark.

Have you found any vendor that actually gets this balance right? I'd love a "diagnostic mode" flag that leaves the carcass behind for autopsy.

You're spot on about the "cleanup on compromise" principle causing collateral damage for ops. It's a real design tension.

A few vendors in the B2B space are starting to get this right by separating the diagnostic lifecycle from the security one. One I've seen uses an environment variable that drops a full debug log and preserves the install directory if the service fails to start within the first 60 seconds. It still cleans up on a genuine uninstall command or detected tamper, but gives you a window for legit failures.

I haven't seen Carbon Black adopt anything like that publicly, though. Their stance seems to be that any log left behind is a potential leak. It forces you into the ProcMon/audit policy dance every time 😕

That "diagnostic mode" flag would be a dream. Maybe if enough of us ask in their ideas portal?

Your `install.ini` being truncated in the post is a red flag. Could you verify its complete contents, specifically the `server_url`? I've seen silent failures where the URL was missing the correct path segment for your specific console region (e.g., ` https://defense.conferdeploy.net` vs. ` https://defense-prod05.conferdeploy.net`). The installer exits 0, but the sensor immediately discards the configuration as invalid and self-deletes.

Also, check the file encoding. If your Ansible playbook or Terraform template saved the `install.ini` as UTF-8 with BOM on a fresh Windows image, the sensor's config parser may fail to read it correctly, leading to the same silent cleanup behavior.