??? Svchost went crazy accessing /Device/GLOBALROOT

First, I have svchost under its own custom ruleset in CIS premium and I understand I’m going to get a lot of weird alerts if I do that. But this was a bit…out of the ordinary for me. Last night, I noticed a whole bunch of alerts popping up that asked to give it permission to access .dll files in the System32/SysWOW64 folders. The file paths looked like this:


It went on for about 50-100 different files, after which I just decided to log off and shut down because the computer was running low on power. I think it might have something to do with system volume backup but I’m not sure. PC is clean - and relatively new - so viruses or malware are out of the question. What could be going on?

Svshost.exe is a bit of a mysterious process as it is host for various tasks from the OS as well as applications. To know a bit more about what it is doing we need to know the Process ID of the instance of svchost.exe that was running. But since you rebooted there is no way knowing what was happening.

It’s happening again and VSC is disabled. Now it’s going into .NET framework files and winsxs files as well.

This time I can get the process ID easy enough under Killswitch but there are 11 svchost.exes running. If we want the PID of the one spawning cavwp.exe - which was the one showing all the green/red bar activity at the time - that’s 844.

Could this have been a virus scan or (more probable) a scheduled Windows task? Strange because I thought those were supposed to be monthly.

Cavwp.exe will also handle the cache builder and cache cleaner activity of CIS. The av will build a cache of scanned files so they don’t get scanned until the next av database update. This helps to make the av lighter.

You can check the CIS logs to cross reference what action was being taken.

I noticed though that once the cache builder or cache cleaner activity starts it will keep on using one of four cores until it is done. It will start when the system is idle but it won’t throttle back when it gets active again.

Snapshot.etl was also being accessed at the time, which now that I think of it points to Windows Backup as the culprit.