CC SecurityDriver and Compatibility Notes
CC Security's complete protection consists of a standard-privilege interface, a user-mode protection service, collection processes, and two Windows kernel drivers. Opening the interface does not mean the kernel components have loaded or actual blocking is effective. Before installation, review these notes and the Important Safety Notice. Prefer a virtual machine with restorable snapshots or a dedicated test device.
1 Current System Scope
Item | Current information |
|---|---|
Architecture | x64 Windows; no commitment to native x86 or ARM64 support |
Windows 10 | Minimum build target 19041; primary compatibility target is 22H2 build 19045 |
Windows 11 | Intended for x64 environments; validation is still required for the specific device and security policies |
Drivers | Experimental test signing; system loading requirements and installation eligibility must be met |
Interface | Requires WebView2 Runtime; visual effects depend on system composition capabilities |
Current evidence limits | Build, test-fixture, and interface checks have been performed; these are not comprehensive physical-device compatibility certification |
This version targets x64 Windows. The minimum build target is Windows 10 build 19041, with Windows 10 22H2 build 19045 among the primary compatibility targets. This is not comprehensive device compatibility certification. Windows 7, Windows 8, 32-bit Windows, native ARM64 environments, and Windows Server editions are outside the currently validated support scope.
Windows version, system security policies, virtualization-based security, graphics drivers, WebView2 Runtime, and other kernel drivers may all affect behavior. Retain system updates and trusted backups, and check the operating system's own maintenance eligibility. CC's Windows 10 compatibility work does not guarantee Microsoft's maintenance lifecycle.
2 Component Responsibilities
CCSecurityAgent is the user-mode protection service responsible for receiving events, correlating rules, performing permission-controlled administrative operations, and taking confirmed remediation actions. CCSecurityGuard.sys handles process, registry, object-handle, and related protection callbacks. CCSecurityScriptFilter.sys is a file-system filter driver for relevant NTFS file events and operation enforcement.
CCSecurityEDR.exe performs local rule matching. CCSecurityMemory.exe and CCSecurityActivity.exe provide corresponding memory or call-chain metadata. A collector starting, normal memory usage, or a successful EDR worker handshake establishes only the status of that stage. It does not prove the complete protection chain is effective.
File filtering currently focuses primarily on NTFS collection. Do not assume network drives, other file systems, access-restricted processes, or behaviors not collected have the same coverage as local NTFS. Some memory and image information is observed after the event and cannot support a claim of blocking before the first instruction executes.
3 Current Test Signing Requirements
The delivered kernel drivers are signed with a CC test certificate. They must not yet be described as Microsoft production-signed, WHQL-certified, or eligible as ordinary release drivers. Installing components requires administrator privileges. The scripts check the device's existing Windows TESTSIGNING state and do not automatically modify boot configuration to enable test mode.
Once test conditions are met, installation checks the bundled certificate and component signatures, imports the test certificate into the relevant local-machine certificate stores as required for deployment, and registers the protection service and drivers. Trusting a test certificate changes the system and should be done only in a test environment you understand and control. A digital signature alone does not prove a file is free of vulnerabilities.
Secure Boot, Memory integrity, organizational Group Policy, and other code-integrity policies may reject test-signed drivers. Do not disable existing protection, use vulnerable drivers to bypass restrictions, or import certificates of unknown provenance merely to run this experimental package. If the device does not qualify, stop deployment or use a separate test environment that meets the requirements.
4 Preinstallation Checks
1. Create a rollback snapshot for the virtual machine and independent, verified backups of important files. Retain disk-encryption recovery information and ensure you can enter the Windows Recovery Environment.
2. Verify installer provenance, integrity, version, and revision. Do not mix services, drivers, and EDR workers from different packages. Keep a complete installer known to work.
3. Confirm the device administrator has approved deployment of experimental kernel drivers and that a lawful, suitable test environment is already available. An account having administrator privileges does not establish that every system loading requirement is met.
4. Check whether other real-time security products or filter drivers are running. If compatibility is unknown, prefer a separate test machine rather than directly disabling existing security products.
5 Assessing Status After Installation
After starting CC Security, open "Virus and threat protection" to check the protection service connection and real-time protection status. Then open "Settings" > "About" to check the build and protection component information. Address a disconnected service, unavailable components, and audit mode separately. Do not judge solely by the Home icon.
Component deployment logs are stored at %ProgramData%\CC Security\component-install.log. Protection service diagnostics are in service-diagnostics.log in the same directory. For interface and elevation issues, see %LocalAppData%\CC Security\webview-diagnostics.log. Logs may contain local paths or usernames. Review and sanitize them before submitting feedback.
After an in-place installation of a new package, resident kernel components may still require unloading, reloading, or a restart to match the files on disk. Copying only the new UI EXE is not a complete upgrade. Restart as instructed by the installer, recheck status, and validate expected functionality in a separate test directory.
6 Interface Blur and Notifications
Desktop blur uses Windows composition capabilities. Windows 10 and Windows 11 use different compatibility paths. System transparency settings, high contrast, power policies, and the graphics environment may affect the result. The current Windows 10 path has been tested through a forced compatibility path, but this is not equivalent to physical-device testing across Windows 10 build 19045 devices.
Unavailable blur or card animation does not directly indicate protection-service failure. A healthy protection-service connection likewise does not guarantee correct visuals. First try disabling animation or frosted-glass effects and restoring the default appearance, then check protection status separately. Blocking alerts use native Windows notifications, whose display depends on system notification permissions and Do not disturb settings.
7 Faults and Discontinuing Use
If blue screens, startup problems, significant performance degradation, or conflicts with other drivers occur, stop triggering further tests and retain the version, logs, and necessary dump information. Do not attempt repair by repeatedly loading drivers, forcibly terminating system processes, or substituting unknown drivers.
If Windows remains accessible, uninstall normally following the Uninstallation and Troubleshooting Guide. If Windows cannot start, prefer rolling back a virtual-machine snapshot or using prepared recovery methods such as System Restore in the Windows Recovery Environment. Authorized maintenance personnel should handle offline registry work, disk encryption, or dump-file analysis.
Send compatibility issues to kelematubako@gmail.com. Include the Windows version and build, CC build and revision, whether you restarted, the specific error, and recovery actions already taken. Do not send account passwords, complete personal files, or memory dumps that have not been reviewed.
8 References
Microsoft test-signing guidance https://learn.microsoft.com/windows-hardware/drivers/install/the-testsigning-boot-configuration-option
Microsoft driver-signing options https://learn.microsoft.com/windows-hardware/drivers/dashboard/driver-signing-offerings
Microsoft WebView2 distribution guidance https://learn.microsoft.com/microsoft-edge/webview2/concepts/distribution