cpu usage - What is cisvc.exe and why is it consuming so much CPU time?

I have Windows 7, 64-bit, installed on two computers: my Dell Dimension 5150, and my Dell Latitude D830.

Today's gripe is this:

Sometimes I look at my CPU usage thingie and I see something like this:

On my Dimension 5150, this state can go on, uninterrupted, for hours. After a certain amount of time I get annoyed by it (since the VMware Server instance installed on it starts to steadily lose time if the host remains in this state too long) and I reboot the computer to make it go away.

On my Lattitude D830, it comes and goes and comes and goes. It doesn't seem to make any difference as to what network I am connected to, what I am doing on the computer, whether I am docked or not...

So I bring up the task manager, and I see this:

OK, so the main offender is some svchost.exe thing which is going berserk. So I right click on the svchost instance and select Go to Services. This brings up the DLL-based services that are associated with this svchost instance. I see this:

This tells me that these are the offenders (written out for Google's benefit):

• MpsSvc "Windows Firewall"
• DPS "Diagnostic Policy Service"
• BFE "Base Filtering Engine"

On the desktop it is interfering with the VMware server; on the laptop it is killing my battery life. I could go 4-5 hours on one charge; when these services freak out I'm lucky to get 2.

I do have a version of Symantec Endpoint installed on these computers, v11.0.4202.75.

I would really like to know why MpsSvc, DPS, and/or BFE decide to freak out and take my computer down with them.

Can anyone give me any hints?

Wireshark finally runs on Windows 7 64-bit, and I find my answer.

When running wireshark during one of these incidents on my laptop, the Interface Capture screen shows that my TAP-Win32 Adapter V9 is accumulating packets at a very high rate.

Capturing that interface shows that the packets are a sequence of DHCP requests: Discover, Offer, Request, NAK -- that were all running in 0.0159 seconds and then repeating.

In this highly specific case, the subnet (and interface, upon reflection) is one that is used by the OpenVPN client installed on my laptop. In some cases when unsuspending, especially when unsuspending onto a wireless network, the OpenVPN client "connects" and then gets scrambled up while the network settings are settling. I frequently have to disconnect, then connect the OpenVPN client in order to use it.

Remembering all this, I disconnected and reconnected the OpenVPN client. This immediately was rewarded with a DHCP Discover-Offer-Request-Ack sequence followed by the usual noise that Windows sends along network connections. More importantly, the CPU usage immediately ceased.

The desktop system involved also had a OpenVPN client installed on it and was probably the source of those issues too.

Don't know the exact cause, but when BFE component of svchost starts hogging cpu, the right action is to restart the windows firewall (from services.msc). If you try to restart BFE it most probably will not succeed.

Just had this issue 5 mins ago, mine's on a Win7-64 too. No need for a reboot, although i did disable/enable my network card from devmgmt.msc too, just as a precaution (it helps surprisingly often with various network card issues).

There are many threads about this on Microsoft's sites but without any resolution (and i'm replying to a 3 year old post!).

This is a list of things that you can check (not a solution).
Create a system restore point before going on.

1. Check the Event Viewer for unusual system errors
2. Check the Event Viewer for unusual Firewall errors : in the left pane, click Applications / Services Log / Microsoft / Windows / Windows Firewall with Advanced Security / Firewall.
3. Turn on Firewall logging as explained here. Examine the log for funny stuff.
4. Use TCPView to see if any programs are opening strange ports (or trying to).
5. Use Autoruns to check for funny startups. You can with it save the current state and then selectively turn off some startup programs to see if this changes anything. You can afterward return the situation back.
6. Scan using several antivirus programs. You can use online scaners from well-known companies (each takes hours).
7. Turn off your router to see if it's faulty and bombarding you with packets.
8. Disable your network card to see if it's faulty and bombarding you with packets.
9. Check the hardware for a failing fan or motherboard or else.

That's it, I'm fresh out of ideas.