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?
Best Answer
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.