we’re seeing an increased number of blue screens on startup/reboot which apparently is caused by csagent.sys. We are currently running n1 on those devices. It’s happening across all our windows machines, except servers for now.
Honestly i cannot pinpoint when it exactly started but we believe it was after installing Microsoft November patches.
I have raised a ticket but did not get a second response after initial questions were asked yet.
Has been happening to my work computer since Monday (04.12.2023).
Most often occurs when computer resumes from sleep, the work VPN reconnects and vscode does a “reload window” to reconnect to the remote workspace.
Specifically the reload window in vscode causes the BSoD, then in the dump I can see it happened because of csagent in the code.exe process.
IT took all the minidumps from my computer and are apparently trying to figure it out.
They told me there’s many cases like mine that started on same week.
Did you ever get an update/fix to this? We have been dealing with this for a while and thought it was related to VBS, however, we now experienced a BSOD caused by csagent.sys after removing VBS and Credential Guard completely from one of the affected machines.
Crowdstrike support continues to drop the ball; too many instances like this where support is unable to help and we’re left trying to crowdsource. Maybe we need to standup our own unofficial Crowdstrike support subreddit
i have the same issue with sensor update n-1. I still can’t find the root cause because the support still ask me the dump and log. But currently i make sensor update policy to static 7.04 version.
If it violates the subreddit rules, please go ahead and delete my post but as a customer i am trying to gather any useful information about the issue and if it is isolated or not. The last official response I received was yesterday and due to increasing tickets on our end I have to look for a solution as soon as possible and honestly Reddit is/was a good source at least for our old edr.
Having 200,000 agents running for seven years, I can’t say I agree with that sentiment. When it comes to system stability investigations, CS has always been top notch.
Support has been good on my end. Had a few BSODs but was able to get RCA pretty quickly. Sometimes it took longer. Overall pretty happy with Support. Not sure what youre doing wrong "/
Typical things theyll ask for BSOD issues is first provide the .dmp file and provide any information as to what was occurring at the time of the BSOD. Mini dump is not useful they say, they need a full dmp.
The most frequent delaying factor for sensor BSOD related issues is where a complete/full memory dump and a corresponding cswindiag have not been supplied in a support case meaning that there is insufficient data to escalate internally within CrowdStrike for analysis, so the case then pends on data being supplied.
All good, just try to post as little personally identifiable information as possible.
Some tests you can do outside of working with support is toggling elements like Additional User Mode Data (or extended mode) off for a period of time, or moving back to the older build (N-2) and see if the issue persists. Often we recommend having at least 5-10% of your deployment (whether that be VMs or real machines) on the Latest (N) or Early Adopter (N+1, the toggle in the sensor update policy) to catch issues like this before they hit your production environment.
I’d also recommend opening a MSFT support case, often they might initially point the finger at an AV tool but if they look at your memory dump you might get positive resolution from the almighty creators themselves.