Windows - Configuration - Start CrowdStrike Falcon Sensor Service

What the CrowdStrike Falcon sensor verifier does

This Automox Worklet™ verifies that the CrowdStrike Falcon Sensor service is running on Windows endpoints and restarts it when the service has stopped. The Worklet supports both workstation and server SKUs, and it exits cleanly on endpoints where CrowdStrike Windows Sensor is not installed so the policy is safe to run against a mixed fleet.

The evaluation script reads the Uninstall registry hive to confirm CrowdStrike Windows Sensor is present. On 64-bit endpoints it opens HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall through the 64-bit view, then iterates each subkey and matches DisplayName against the product. The script also walks the 32-bit hive to cover legacy installers. If no install is detected, the Worklet writes a clear message and exits 0.

Once the sensor is confirmed, the Worklet calls Get-Service -DisplayName "CrowdStrike Falcon Sensor Service" and inspects the Status property. A Running status returns exit 0 and no action. Any other state, including Stopped, StartPending, or Paused, flags the endpoint and schedules remediation. The remediation script then wraps Start-Service in a try/catch and reports success or failure back through Automox activity logs.

Why restart the CrowdStrike Falcon sensor on every endpoint

A stopped Falcon sensor is the worst kind of failure because the endpoint still reports as healthy in the asset inventory while it sits with no behavioral monitoring, no telemetry upload, and no prevention. Service stops are most common after cumulative Windows updates, after resume from sleep on laptops, in VDI pools where image refreshes drop services, and on servers under heavy memory pressure. Stale last-seen timestamps in the CrowdStrike console look identical for offline endpoints and endpoints with stopped services, so your security team burns hours triaging which is which during an incident response.

A stopped CrowdStrike Falcon sensor is an EDR gap, and a manually maintained spreadsheet of which Windows endpoints have a running CSFalconService is not a control that survives a real audit. Schedule this Worklet on a daily cadence against the workstation and server policy so CSFalconService is evaluated and restarted where stopped on every endpoint in scope. Each pass restores EDR coverage before the gap shows up in a CIS Critical Security Control 10 review or a SOC 2 CC7.1 finding. The Activity Log records the restart count per endpoint for trending against the EDR uptime dashboard.

How Falcon sensor verification works

1. Evaluation phase: The Worklet checks both the 64-bit and 32-bit Uninstall registry hives at HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall for a DisplayName matching "CrowdStrike Windows Sensor". If no match is found, the script writes "CrowdStrike Windows Sensor is not installed" and exits 0 so unrelated endpoints stay compliant. When the sensor is present, the script runs Get-Service -DisplayName "CrowdStrike Falcon Sensor Service" and reads the Status property. A Running state exits 0. Any other state writes a message and exits 1 to flag the endpoint for remediation.

2. Remediation phase: The remediation script confirms the service object exists with Get-Service -Name "CrowdStrike Falcon Sensor Service", then wraps Start-Service -Name "CrowdStrike Falcon Sensor Service" -ErrorAction Stop in a try/catch block. A successful start writes "The CrowdStrike Falcon Sensor Service service has been started successfully" and exits 0. A start failure, a missing service object, or a permission denial writes the corresponding error and exits 1, which surfaces the failure in Automox activity logs instead of letting it pass silently.

Falcon sensor verification requirements

• Windows workstation or server with the Automox agent installed and running

• CrowdStrike Windows Sensor previously installed; the Worklet does not deploy the sensor, only its service

• SYSTEM-level execution context, which the Automox agent already provides, for Get-Service and Start-Service on a protected service

• PowerShell execution policy that allows agent-delivered scripts (Bypass or RemoteSigned)

• FixNow compatible, so on-call responders can trigger an immediate restart when the CrowdStrike console reports a stale endpoint

Expected Falcon sensor state after remediation

After a successful remediation, Get-Service -DisplayName "CrowdStrike Falcon Sensor Service" returns Status = Running. The Falcon sensor reattaches to its kernel components, begins behavioral monitoring of process execution, file system activity, network connections, and registry modifications, and resumes telemetry upload to the CrowdStrike cloud. Any locally queued events captured while the service was stopped flush up to the cloud and reconstruct the missing window in the event timeline.

The CrowdStrike console updates the host record with a fresh last-seen timestamp, typically within a few minutes. Validate the change with one of these checks: run Get-Service "CrowdStrike Falcon Sensor Service" | Select Status, StartType from an elevated PowerShell prompt; run sc.exe query CSFalconService and confirm STATE is RUNNING; or use the CrowdStrike console host page to confirm sensor heartbeat. Each option produces a copy-paste-ready evidence artifact for audit logs.

Note the scope of this Worklet. It starts the service when stopped, but it does not change the service start type, repair a corrupted sensor install, or reconfigure recovery actions. If the service stops again on the same endpoint inside a short window, that pattern points at a deeper issue such as a kernel driver conflict, a tampered uninstall, or a policy mismatch that needs CrowdStrike support attention. Pair this Worklet with a recurring evaluation policy so the next stop is caught and corrected at the speed of the slowest endpoint, not the speed of the next incident review.