Hey Dan,
Ran into something on CyberLock 9.13 (Windows 11 Pro 26200, running next to Windows Defender + WHHLight) Smart mode, Aggressive, Smart Firewall on Recommended.
I've been using an AI (Claude Code) that fires off a ton of short-lived Git Bash processes in quick succession. Git's bash.exe isn't signed, so nothing matches the whitelist snapshot and every single spawn goes the full cloud route (VoodooAi + WhitelistCloud). Under that burst the service just can't keep up - launches were hanging for about two minutes each, and the machine basically became unusable while it churned.
Digging into the logs is where it got interesting. When the decision path backs up, the driver eventually gives up and lets the process through unevaluated:
[ERROR] HandleSingleProcess: process decision timed out after 122000 ms; replying fail-open to match driver timeout policy.
[ERROR] HandleSingleProcess: Failed to reply to driver (0x801F0020)
I counted 8 of those timeout/fail-open pairs inside about a 90-second window. Any workload that spawns lots of distinct unsigned processes fast should hit it: build tools, git hooks, interpreters shelling out, that kind of thing. A quick loop of 10-20 rapid unsigned launches was enough for me.
The part that made me raise an eyebrow is that the timeout fails OPEN. So a flood of process launches, mine were harmless, but they wouldn't have to be, opens a window where new processes get allowed without any evaluation at all. I keep thinking that for a default-deny product you'd want it to fail closed (block, or hold and retry) rather than wave things through when it's overwhelmed. Defender is still there as a backstop on my end, but the gate going open under load feels like something worth locking down.
For what it's worth, I did get my latency under control with a rule: an Allow rule, type Folder, C:\Program Files\Git\, applied in ON/OFF/AUTOPILOT, with all three file-insight checks (Digital Signature / VoodooAi / WhitelistCloud) turned off, and "Override Custom Folders Settings" on. The log shows the override doing exactly what I hoped:
[INFO] Process blocked by Custom Folders: c:\program files\git\bin\bash.exe
[INFO] Process allowed by Allow Rule: c:\program files\git\bin\bash.exe
After that, 10 back-to-back bash.exe launches ran in about 1.5s (~150ms each) instead of stalling for two minutes, and the timeouts stopped completely. Obviously that's a workaround for my case, not a fix for the fail-open itself.
So mostly I wanted to flag it, plus a few honest questions:
- Is the 122,000 ms fail-open deliberate? Could saturation fail closed instead so the gate can't be forced open by sheer volume?
- Any chance the service could remember a repeated identical unsigned image locally (a per-session decision cache) so it's not re querying the cloud on every spawn in Smart mode?
- Would a bounded or parallel decision queue help, so a burst of one process type doesn't block everything else?
Glad to send over the full DeveloperServiceLog / DeveloperLog with timestamps if that's useful. Thanks.
Excellent report, thank you for taking the time to dig into this so thoroughly. This is exactly the kind of edge case I want to know about.
The 122-second fail-open is deliberate. It is essentially a last-resort safety valve so that if something goes seriously wrong in the decision path, CyberLock does not leave a process hung indefinitely and potentially make the entire machine unusable.
Having said that, I agree with the larger point you are making: saturation should not become a practical way for unevaluated processes to get through the execution gate.
I also do not think simply changing the global timeout from fail-open to fail-closed is necessarily the right solution. If the CyberLock service, network connection, cloud provider, or some other dependency has a problem, blindly failing closed could potentially turn that condition into an endpoint-wide denial of service. We need to distinguish between those kinds of failures and a queue that is temporarily saturated with repetitive work.
Your Claude Code / Git Bash example is particularly useful because bash.exe is the same executable being launched over and over. There is no good reason for CyberLock to repeatedly perform expensive identical work when it can safely determine that it has already evaluated the same image under the same relevant conditions.
So there are really a few things I want to look at here:
1. Coalescing identical evaluations that are already in flight, so 20 launches of the same executable do not create 20 independent cloud-analysis jobs.
2. A short-lived local/session decision cache for identical files where appropriate.
3. Better queue/saturation handling so one bursty workload cannot starve unrelated process decisions.
4. Revisiting the timeout behavior so that overload conditions are handled differently from a true service failure.
Your folder rule is a clever workaround and the log confirms it is behaving exactly as designed. I would not want users to have to create broad allow rules with all of the file-insight checks disabled just to accommodate workloads like this, though. The underlying behavior should be improved.
Please send me the full DeveloperServiceLog and DeveloperLog. If you still have the exact loop/test you used to reproduce it, send that as well. Being able to reproduce this reliably with 10-20 rapid launches should make it substantially easier to fix and verify.
And again, excellent find. This is a very useful report.
