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.

...when I tried it, was stop the intial delay and high CPU utilization when first accessing an Internet site. This time period, from around a half minute to several minutes, prevents any other tasks from being performed while it is happening and it was during this period that the RAM increased to the higher level. All you have to do is turn off the Spy Site Blocking feature. To do this, click the Anti-spyware panel, Spy Site Blocking tab, and enable Off. See if this works for you. You can always turn it back to On if it doesn't

Since you are using procexp already, suggest also checkout the Verify Image Signatures. This allows you to verify driver signatures that are installed on the system. To turn this option on, go to the Options menu and then select Verify Image Signatures. After turning on the signature option, add the column “Verified Signer” to the main screen. If anything shows up as unable to verify, it might give you a clue on the problem process. If it is able to verify the signature, the field displays “(Verified)”, followed by the subject name from the certificate. For Zonealarm appl, it should digitally signed and issued to Check Point Software Technologies Ltd. by VeriSign. For Microsoft, most of its executable files ship as part of Windows have “Microsoft Corporation” as the company name but are signed with a “Microsoft Windows” certificate.

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

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.

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

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...