asked on
ZoneAlarm CPU Hogging and Bizarre Hook to Windows Backup Service
Been pestering me for weeks. Finally attempted troubleshooting last night. After a wasted couple of hours with ZA support, thought I'd try the Experts.
This is the summary I posted to them:
Windows 8.1, i7 cpu, 12 Gb RAM
ZoneAlarm Pro version: 12.0.104.000
ZoneAlarm license key: xxx
Vsmon version: 12.0.104.000
Driver version: 12.0.102.000
After several system rebuilds (not associated with ZA) and multiple clean installs, Zonealarm - specifically vsmon.exe - continues to hog the cpu.
I have disabled logging. I have shut down all apps which could be attracting firewall attention. I have stopped all internet activity. I have attempted to force priority low. I have even tried to change the affinity to a specific processor (I have an i7, with 8 processors). I have deliberately opened apps with intensive activity (eg ip cameras).
NONE of these makes the slightest difference to the stable 12-14% cpu activity used by vsmon.
If I perform a clean install, disconnect from the internet and reboot, close down nearly all apps, open up the task manager, and just let the system sit there, I can watch vsmon build up its activity, over about 20 minutes till it reaches 12-14% and stabilises.
Using procexp, I even tried to identify and shut down ANY other activity using the cpu at all, to see if any were related to vsmon's greed. In the process, I may have found a clue.
I found windows backup service sdclt.exe churning away using a small amount of cpu power (~0.1-0.2%) and tried to shut it down. The message I got was interesting. It asked if I wanted to shut down ZATray.exe. At first I thought I must have right clicked on the wrong item in the list but however carefully I tried, any attempt to shut down sdclt.exe resulted in the same question.
So we know that ZATray is running the windows backup service PERMANENTLY for whatever reason, on my machine. (It does not appear to be doing this on any other machine I have access to)
So I'd like you to investigate why it might be doing that and how I can switch it off, even if only to test the consequences for the overall vsmon problem.
**************************
They deny even the possibility of a link to the backup service and suggested a selective startup (nothing except ZA and MS basics). Made zero difference and sdclt.exe still shows up as a child process of ZATray. As Process Explorer also reveals that Vsmon is performing a ludicrous amount of reading, writing and cpu cycling, I strongly suspect the root of the problem is at least linked to this bizarre hook where ZATray is spawning sdclt.
I have eliminated the possibility that the windows file is infected . (SFC /Scannow and clamwin both say everything is clean) and, no, I'm not running any other firewall. (Windows firewall disabled) and I'm deliberately only using Windows Defender for real-time scanning/protection and clamwin for manual scanning. So no Avast, Malwarebytes or any other malware shields are implicated.
I'm open to suggestions
This is the summary I posted to them:
Windows 8.1, i7 cpu, 12 Gb RAM
ZoneAlarm Pro version: 12.0.104.000
ZoneAlarm license key: xxx
Vsmon version: 12.0.104.000
Driver version: 12.0.102.000
After several system rebuilds (not associated with ZA) and multiple clean installs, Zonealarm - specifically vsmon.exe - continues to hog the cpu.
I have disabled logging. I have shut down all apps which could be attracting firewall attention. I have stopped all internet activity. I have attempted to force priority low. I have even tried to change the affinity to a specific processor (I have an i7, with 8 processors). I have deliberately opened apps with intensive activity (eg ip cameras).
NONE of these makes the slightest difference to the stable 12-14% cpu activity used by vsmon.
If I perform a clean install, disconnect from the internet and reboot, close down nearly all apps, open up the task manager, and just let the system sit there, I can watch vsmon build up its activity, over about 20 minutes till it reaches 12-14% and stabilises.
Using procexp, I even tried to identify and shut down ANY other activity using the cpu at all, to see if any were related to vsmon's greed. In the process, I may have found a clue.
I found windows backup service sdclt.exe churning away using a small amount of cpu power (~0.1-0.2%) and tried to shut it down. The message I got was interesting. It asked if I wanted to shut down ZATray.exe. At first I thought I must have right clicked on the wrong item in the list but however carefully I tried, any attempt to shut down sdclt.exe resulted in the same question.
So we know that ZATray is running the windows backup service PERMANENTLY for whatever reason, on my machine. (It does not appear to be doing this on any other machine I have access to)
So I'd like you to investigate why it might be doing that and how I can switch it off, even if only to test the consequences for the overall vsmon problem.
**************************
They deny even the possibility of a link to the backup service and suggested a selective startup (nothing except ZA and MS basics). Made zero difference and sdclt.exe still shows up as a child process of ZATray. As Process Explorer also reveals that Vsmon is performing a ludicrous amount of reading, writing and cpu cycling, I strongly suspect the root of the problem is at least linked to this bizarre hook where ZATray is spawning sdclt.
I have eliminated the possibility that the windows file is infected . (SFC /Scannow and clamwin both say everything is clean) and, no, I'm not running any other firewall. (Windows firewall disabled) and I'm deliberately only using Windows Defender for real-time scanning/protection and clamwin for manual scanning. So no Avast, Malwarebytes or any other malware shields are implicated.
I'm open to suggestions
VulnerabilitiesMicrosoft Legacy OSSoftware Firewalls
Last Comment
btan
ASKER
Good idea using the Verified Signature option. Saves running sfc /scannow every time I have suspicions!
They all checked out on this occasion, but, while checking that, I think I've spotted a red herring in my initial report. It seems that the apparent link between sdclt.exe and ZATray is an artifact caused by what looks like a bug in Procexp.
It looks like the apparent link is dependent on the order in which programs are loaded. I discovered this because I had ZA switched off, but turned it on to run the signature verification check. As usual vsmon leapt to 14% but I scrolled down to see what sdclt was doing and it wasn't beneath the ZATray icon. My first thought was that perhaps that was because I'd only just switched on ZA. Then, out of curiousity, I tried to kill its process as I had previously tried and failed (with the question "Are you sure you want to kill ZATray.exe?"). This time I got the question "Are you sure you want to kill Digiguide.exe?" which was the program listed immediately above sdclt.exe. So it looks like there's something weird about sdclt.exe which causes procexp to point to the program above it in the list when attempting to control it.
That justifies ZA's denial of any link between ZA and windows backup service but means I still have no clue as to the cause of vsmon's cpu hogging.
I've just downloaded tcpview and I'll report back when I've got some results from that.
They all checked out on this occasion, but, while checking that, I think I've spotted a red herring in my initial report. It seems that the apparent link between sdclt.exe and ZATray is an artifact caused by what looks like a bug in Procexp.
It looks like the apparent link is dependent on the order in which programs are loaded. I discovered this because I had ZA switched off, but turned it on to run the signature verification check. As usual vsmon leapt to 14% but I scrolled down to see what sdclt was doing and it wasn't beneath the ZATray icon. My first thought was that perhaps that was because I'd only just switched on ZA. Then, out of curiousity, I tried to kill its process as I had previously tried and failed (with the question "Are you sure you want to kill ZATray.exe?"). This time I got the question "Are you sure you want to kill Digiguide.exe?" which was the program listed immediately above sdclt.exe. So it looks like there's something weird about sdclt.exe which causes procexp to point to the program above it in the list when attempting to control it.
That justifies ZA's denial of any link between ZA and windows backup service but means I still have no clue as to the cause of vsmon's cpu hogging.
I've just downloaded tcpview and I'll report back when I've got some results from that.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
bingo!
It is sdclt.exe that is the cause of the problem.
see http://superuser.com/questions/679539/windows-backup-service-spawning-endlessly-and-occupying-processor
for example
And you get the credit for providing not the solution but the path to it. That process hacker is an excellent tool and enabled me to see both what was happening and what it meant. That led me to understand what I'd been seeing in procexp but didn't understand. i.e. sdclt was spawning every second or so (and dying). Did a search for that and a few hundred other windoze 8.1 users seem to be having the same problem (I suspect its probably a few million but most haven't yet noticed the effect)
The solution is to disable the scheduled task which is causing it. 50 minutes after a reboot, vsmon is behaving completely normally.
Job done. Thanks. Today you haven't provided a fish, you've taught a man how to fish. Always a better result...
It is sdclt.exe that is the cause of the problem.
see http://superuser.com/questions/679539/windows-backup-service-spawning-endlessly-and-occupying-processor
for example
And you get the credit for providing not the solution but the path to it. That process hacker is an excellent tool and enabled me to see both what was happening and what it meant. That led me to understand what I'd been seeing in procexp but didn't understand. i.e. sdclt was spawning every second or so (and dying). Did a search for that and a few hundred other windoze 8.1 users seem to be having the same problem (I suspect its probably a few million but most haven't yet noticed the effect)
The solution is to disable the scheduled task which is causing it. 50 minutes after a reboot, vsmon is behaving completely normally.
Job done. Thanks. Today you haven't provided a fish, you've taught a man how to fish. Always a better result...
ASKER
see my final comment.
glad it helps :)
So far, ZATray is the ZoneAlarm Security Toolbar (see this pertaining to the exe which shouldnt be getting so much resrc though, same for the sdclt.exe too) and currently I understand that it is not supported in IE 11. I was thinking if the toolbar is uninstalled (hopefully it does not mean trigger the prompt too) will the utilisation still be the same. Toolbard uninstallation is independent of the vsmon uninstallation if I recall correctly. (w/o toolbar, the web protection is implicated but the av and fw should still be running fine)
I wondering the relationship if there are listening to same port for these two process too using TCPView or CurrPort etc. (But not sure if they can run on Windows 8.1, they should though and maybe even ZA may be triggered). So far did not hear of any such dependency (alert prompt linkage) though
FYI, on a tinywall FW FAQ (last one) specific on .NET appl e.g. Why does TinyWall seem to use a lot of memory? @ http://tinywall.pados.hu/faq.php