I'm dealing with some frustrating crashes related to CCMExec, MonitoringHost, and CScript applications, all tied to RPCRT4.dll. About 6 months ago, we noticed that users were disconnecting from our servers, and while they could use Chrome (if it was already open), any new applications couldn't access the network. Nslookup fails and pings by hostname just don't work.
The logs show a flood of repetitive crash events, leading to a summary event in our SIEM systems. Unfortunately, when we check the Windows Error Reporting queue, the reports are missing. Restarting the computer temporarily fixes the issue.
There's no obvious commonality among the affected devices, with different makes, users, and times of occurrence. Any insights or suggestions would be hugely appreciated!
2 Answers
This issue likely isn't a random app crash since it's tied to RPC and RPCRT4.dll. When that DLL misbehaves, new connections fail, while existing connections (like Chrome) keep working. It’s possible that something related to SCCM, WMI, or even a security software is interfering. Start by identifying any common factors between the affected machines, such as updates or agent versions, and consider disabling one element at a time on a test machine to see if the problem persists.
Here are a couple of things to check: 1. Ensure the network card driver is the correct version from the manufacturer. 2. If the devices are domain-joined, make sure they are using the AD-integrated DNS servers exclusively.
I can confirm that the network card drivers are up to date, and this issue even shows up on brand-new devices straight out of the box. Our DNS servers are strictly Microsoft AD ones, so no external DNS involved.
We’ve investigated several possibilities. We removed MonitoringHost and some SCCM tools from a test computer, but the issues still happened. The only non-Microsoft product is a SIEM tool with limited involvement, and even after uninstalling it, the problem continued. However, we did notice that WMI responses slow down during these crashes, sometimes taking several seconds. We found logs pointing to the Delivery Optimization Service and tried disabling it, but it caused issues with SCCM, so we had to enable it again. Despite all devices being updated, we’re hesitant to pin this on Windows itself due to the sporadic nature.