What you did: Installed latest version of Cygwin from http://www.cygwin.com/ I use /bin/zsh as the default shell.
What actually happened or you actually saw: Every time I start zsh, it is very slow to start and I see cmdagent take 100% CPU for a good 30 sec. cmdagent also crashed once though I cannot reproduce it (I sent the crash dump files though). I can reproduce the slowness and high CPU usage on 3 machines. This started happening with CIS 5.3
What you expected to happen or see: zsh should start really fast like it was the case with CIS 5.0 This started happening with 5.3
How you tried to fix it & what happened:
If its an application compatibility problem have you tried the application fixes here?: If I disable the A/V part I do not see this problem.
Details & exact version of any application (execpt CIS) involved with download link:
Whether you can make the problem happen again, and if so exact steps to make it happen:
Any other information (eg your guess regarding the cause, with reasons): My guess is that every time the a/v database is updated the next time cygwin/zsh starts it is very very slow. The I think it’s OK for a bit because of the stateful scanning.
Files appended. (Please zip unless screenshots).
Screenshots illustrating the bug:
Screenshots of related CIS event logs and the Defense+ Active Processes List:
A CIS config report or file.
Crash or freeze dump file:
Your set-up
CIS version, AV database version & configuration used: 5.3.176757.1236
a) Have you updated (without uninstall) from CIS 3 or 4: Upgraded from 5.0 to 5.3
b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:
a) Have you imported a config from a previous version of CIS:
b) if so, have U tried a standard config (without losing settings - if not please do)?:
Have you made any other major changes to the default config? (eg ticked ‘block all unknown requests’, other egs here.): No
Defense+, Sandbox, Firewall & AV security levels: D+=Clean PC , Sandbox=Disabled , Firewall =Safe Mode , AV = Stateful
OS version, service pack, number of bits, UAC setting, & account type: WinXP Pro 32-bit Admin
Other security and utility software installed: No
Virtual machine used (Please do NOT use Virtual box): No
I think it’s definitely the A/V part and it happens when new A/V defs are updated. I just experienced this: I had one app that was started fine, pretty fast with A/V defs 7630 I just checked for a/v updates and I got 7633 installed. I started the same app right away and it was dog slow, I think it needs to be validated against the new virus defs. Now if I restart the same app again, it’s fast, I suspect until the next a/v defs. What doesn’t make sense is that having the A/V set to On Access or Stateful does not make a difference. On Access I’d suspect it should always be slow as the app is scanned every time.
It’s disappointing to see that the A/V has issues again, historically the A/V caused troubles in CIS and many times I had to disable it and use some other A/V software.
I’ll disable the A/V completely and see what happens.
OK. Now I’m 100% positive is the real-time A/V scanning that’s causing this after a new a/v defs database is installed. Here’s my test:
I disabled A/V real time scanning while D+ was set to Clean PC Mode.
I updated the defs db and it went from 7633 to 7636.
I could start cygwin/zsh and other apps pretty fast.
I set A/V real-time scanning to Stateful.
Tried starting the same apps, they were VERY SLOW to start and the CPU went crazy at 100% with cmdagent being the culprit. Subsequent restarts of the same apps were fast, presumably because of the statefulness.
I can reproduce the same problem on Windows 7 64-bit, logged in as an admin user. It’s not as bad as on my old Windows XP machine as this new Win 7 machine is faster but the problem is still there, cmdagent takes up a whole core at 100% while cygwin’s zsh starts. Not as bad but still annoying enough. Again, if I disable real-time a/v, the problem goes away.
start cygwin zsh.exe - it takes a while for the prompt to appear
now type “ping google.com” - for whatever reason, “ping” takes forever to be verified and do something, the first time after a virus update. Note that this is happening when running ping via zsh.exe not via cmd.exe