I've had these exact symptoms like yours for about a week now. I opened then a service request last week with McAfee, but so far they hadn't had any news to tell, let alone a workaround (our "workaround" is to open McAfeeFire.exe, disable IPS policies and let firewall policy intact).
Our main issue with this behaviour is that VPN client gets rendered unusable and stays this way until McAfee Host Intrusion Prevention Service is disabled and workstation rebooted.
I've noticed that there's no significant difference whether the laptop's radio is ON or OFF. In both statuses the symptoms may occur. It occured also, when I was updating Intel-based NIC-driver (no VPN client was installed and laptop's radio was OFF).
I've encountered bunches of these lines on FireSvc.log, too: "NipsMessaging.cpp ERROR (3620) NimQ - Unexpected mac address value", though the number in brackets may vary from a computer to another.
After a couple of hours of FireSvc.exe's high CPU consumption there might appear an error line "Clear boot time protection - no action taken" (or something similar) and right after that a wsc.cpp-related line "Couldn't register WSC for Vista SP1 or later..."
This could lead to something, but even though being systematically testing this, I haven't any useful news yet.
In addition, last spring, with HIPS8, installing a DAT update caused these same symptoms and the case was fixed with another DAT update (AFAIK). These were the threads then:
Will continue to investigate...
Yesterday (September 19th) I was informed of a hotfix to this very issue, and a KB article, which was published on Monday this week:
I was told that the hotfix addresses the VPN client's malfunctioning as well as the high CPU consumption of FireSvc.exe.
I'm expecting to have the hotfix for testing today.
Till then, I'll continue to investigate...Message was edited by: asgars on 9/20/12 1:51:02 AM CDT
High CPU is not mentioned in the KB article, nor is it menioned in the hotfix. It seems to address the VPN issue. Please post if this does solve your issue.
KB article do not solve our problems also we dont see after there run / installtion if the hotfix installed or not. We dont get any information if it installed or not!
The mcafee support spoke to me as next step i must move the loopback rule from the firewall to the first position.....but the problem is not solved.
Now we push the case and it is escalates to tier 2.
I'll investigate....Nachricht geändert durch evoco on 25.09.12 08:01:37 CDT
our Service Request at McAfee was escalated to Tier 3. The sheer existence of VPN client (or using it) or the WiFi radio being turned ON doesn't cause this FireSvc.exe behaviour, they simply help it happen in a shorter time.
Anyway, I managed to install the hotfix this way:
1. Disable the conflict-producing hardware driver from Windows's Device Manager (I mean WiFi device).
2. Disable Host IPS and Network IPS from McAfeeFire.exe.
3. Launch "McAfeeHIP_ClientHotfix2_771202.exe" using elevated privileges (even if you're logged in as an admin).
4. After a couple of minutes, check the HIPS version. In my cases, version changed from 22.214.171.1241 to 126.96.36.1998. This means that the hotfix has succeeded.
5. Reboot the workstation. No more high CPU consumption of FireSvc.exe should appear (at least due to this very cause).
Did this help? I noticed, that the hotfix won't succeed if either IPS is enabled or WiFi device isn't disabled.
I'll still keep on investigating...
One more phase might be needed between phases 1 and 2, if installing the hotfix doesn't succeed: a reboot.
McAfee instructs generally, concerning HIPS updates/patches/hotfixes, that HIPS should be disabled prior to installing (phase 2 on my list), and installing should be done via elevated privileges (phase 3).
But to my experience, those two phases weren't enough if FireSvc.exe was on-wild. Thus my phase 1. And if FireSvc.exe is on-wild, the service won't fall silent until workstation is rebooted (phase 5).
Hello Asgars, you are right the version switches after there installation from 188.8.131.521 to 184.108.40.2068.
But for us is with that prodcedure the problem not resolved or fixed. We test this fix by three hp notebooks and its nothing solved.
Interested is we get only the problem if the notebook not in the local area network or conected with LAN. If we start the notebook without any connection to network (WAN or LAN) we get this problem. It must be to do with the local adapters.Nachricht geändert durch evoco on 26.09.12 02:36:24 CDT
indeed I was celebrating way too soon. The hotfix helped for about fifteen minutes (or till the next reboot), but after that, FireSvc.exe woke up again.
Do you get this problem even if the WiFi driver is disabled from Win Device Manager and the workstation is rebooted? We don't.Message was edited by: asgars on 9/26/12 8:23:42 AM CDT
I did notice in the testing that we did that the issue only occured while on wireless. If I restarted the laptop connected to wired network, it never had an issue.
>Do you get this problem even if the WiFi driver is disabled from Win Device Manager and the workstation is rebooted? We don't
we get the same problem, its with that issue not resolved.