Computer freezes when answering 'Allow' to a CIS 3.9.95478.509 Firewall Alert

  • CPU: AMD Turion Dual-Core RM-72 (32 bit)
    • Operating System information: Windows Vista Home Premium SP2
    • Actively-running security and utility applications: CIS 3.9…509
    • Specific symptoms of the bug, and steps you can take to reproduce it (step by step): Click ‘Allow’ when the CIS Firewall+ Alert pops up saying that svchost.exe is trying to receive a connection from the Internet (wireless home network router address).
    • Specific steps you have taken to try to resolve it: Click ‘Deny’ or allow the Firewall+ Alert to time out and default to ‘Deny’.
    • Brief description of your Defense+ settings: Clean PC Mode and Firewall+ settings: Safe Mode. Mention if you modified any setting in ADVANCED section of D+ and F+: D+ Image Execution Control set to ‘Normal’. F+ Attack Detection Settings ‘Protect the ARP Cache’ checked. All other F+ and D+ settings are default.
    • If you pc reboots or you have a BSOD post in BSODs: NA
    • Report if you are using: Administrator account. Vista users please Report if you have UAC: Enabled.

I have never had this computer freezing problem on any computers running Windows Vista and Intel processors that I have installed CIS on, so I don’t know if this problem has anything to do with the AMD Turion processor on a computer running Windows Vista. This is the first computer that I have tried to install CIS on that has an AMD Turion processor.

[attachment deleted by admin]

This HP_HC_ scheduler.exe file to what program does it belong? Do you see entries in the D+ logs that may give a clue? Can you post a screenshot of the D+ logs?

I am going to have pay closer attention to the alerts that I take screenshots of. The screenshot that I attached obviously was not the one that I intended to take. I was getting this computer freeze from a Firewall Alert that was related to svchost.exe. This was the file that was causing the computer to freeze every time I clicked ‘Allow’. When I took a screenshot of the Firewall Alert, I apparently wasn’t paying attention and thougtht that the svchost.exe file was again causing the alert. I went in to the Network Security Policy and changed the setting for svchost.exe from ‘Deny’ to ‘Allow’. I haven’t gotten any more Firewall Alerts for svchost.exe and i haven’t had any more computer freezes. This svchost.exe was the only file that was causing the freeze. What would the D+ logs have to do with this Firewall Alert?

Please make svhost.exe Outgoing only. That is the only proper mode.

It was trying to receive a connection from the wireless router on my home network. Isn’t that just information coming from the router itself? If a connection was trying to come from a computer outside the wireless home network, wouldn’t the IP address show something other than the wireless router address? I have always assumed that it would.

Post the actual error message. I also think svchost should only need outbound permission to allow informing the router that a service is running and available, listening to incoming on a port. The service itself needs permission to receive the incoming.

Of course, I am no network guru and my opinion agreeing with Eric adds little weight. OTOH Eric is pretty trustworthy!

I am not getting an error message any more because I am no longer getting a popup Firewall Alert asking to ‘Allow’ or ‘Deny’ the svchost.exe trying to receive a connection from my wireless router address. I have gone into CIS Firewall Advanced Network Security Policy and changed ‘Deny’ to ‘Allow’ for the “Allow and Log UDP In from IP In [ /] To IP Any Where Source Port Is Any and Destination Port Is Any” under C:\Windows\System32\svchost.exe. I think that this is safe because I think this is just the wireless router (IP address communicating with the computer. The information is parenthesis above is basically the information that was on the Firewall Alert popup that would freeze the computer if I clicked ‘Allow’. If I clicked ‘Deny’ the computer would not freeze.

This is my granddaughter’s laptop that I am setting up for her. On my desktop I have under C:\Windows\System32\svchost.exe two entries that allow incoming connections. One is “Allow TCP In from IP In [ /] To IP Any Where Source Port Is Any And Destination Port Is Any”. The other one is “Allow UDP In From IP In [ /] To IP Any Where Source Port Is Any And Destination Port is Any”. Both of these addresses are on my wireless home network. One is the wireless router and the other is another computer on the network.

Exactly the same problem. How many Severity 1 Critical Bugs are there in this program? Last time I tried to update Comodo FW, all my 32bit programs on Vista 64bit stopped working. Now there’s finally a new version, but it freezes my computer if I click Allow.

Where went the old Comodo quality?

Exactly same problem here! (XP x64 - Amd 4800 X2 )

Hi Guys,

3.10 is on its way. I believe it addresses this issue. If any of you would like to test and see before it is released, please PM me and i can give you a test version to verify.

Thanks for the feedback and cooperation,


good job guys :-TU can’t wait

pm sent requesting 3.10 alpha/beta

i postd the same before and got no replys at all…

really hope this gets fixed in the next version.

Just out of curiosity, why do you believe 3.10 addresses this issue? Is there a known bug regarding Comodo freezing in similar situations? Was a specific fix made to address this issue? If not, then there is no reason for believing the problem will be resolved. “Magic” fixes (where something suddenly starts working again without any attempt made to fix it) scare me.

I ask because I am seeing a very similar freeze on my father’s laptop running 64-bit Vista (SP2) and the same version (3.9.95478.509, 64-bit) of Comodo. It does not involve svchost.exe, but rather “System” (whatever that might refer to). I think it involved port 139, but I am not 100% sure of my memory. But the result is the same: click “Allow” in the Comodo dialog and the computer completely locks up. Power Off is the only way to regain control.

I’d hate to download 80MB worth of 3.10 installer over my dial-up connection only to find out that it makes no difference whatsoever.

for me, this bug seems to be solved with version 3.10.102194.530

thnx for fixing. :slight_smile: