Hey everyone, I'm seeking some help with a frustrating issue we've been facing. After a series of recent Windows Updates, several servers and user machines are experiencing a serious problem: we're seeing multiple instances of gpupdate.exe running at the same time, causing CPU usage to spike consistently to 100%. This started happening around February 25th, with these processes respawning every four hours. What's strange is that this is happening across various environments, OS versions, and even different antivirus setups, although it seems Microsoft Defender might be involved. Not every machine is affected, but the issue began right after those cumulative updates. Can anyone share if they've experienced this behavior? I'm particularly curious if this could stem from a regression in a February update, a change in Group Policy behavior, or some trigger causing the Software Installation Client-Side Extension to activate without any active MSI assignments. Any insights would be greatly appreciated before we escalate this further!
3 Answers
I’m having the same issue, just wanted to chime in that it’s not isolated. Definitely something off with the recent updates!
Same here, we've noticed this issue too today. Our environment uses ScreenConnect and SentinelOne along with Huntress for security. So far, the only workaround we've found is to manually kill the gpupdate process whenever it spikes. Not ideal, but it's a temporary fix.
We've encountered the same issue in our managed service provider setup following the February updates. The only consistent factor among the affected machines has been a specific remote management agent we’re using. What solution are you using on those systems? We also noticed **4688 process creation events** in the security logs that coincided with the gpupdate process respawning. It seemed more linked to the remote management agent than a straight-up bug from the updates, especially since the problems span different OS versions. I'm curious about your tech stack for those machines.
Interesting, we're using a larger CWRMM agent, so knowing this might be tied back to the ScreenConnect part of your stack helps a lot. I’ll share this with our team as they just released an update mentioning issues with RMM. You can check their status updates here: [https://status.connectwise.com](https://status.connectwise.com).