2009-09-28 #1

Vista is dead, hooray

So because we are a Microsoft Partner of some sort, we get some fancy licenses which permit us the use of some Microsoft software on our computers.

I have Windows 7, 64-bit, installed on two computers: my Dell Dimension 5150, and my Dell Lattitude 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.

So I bring up the task mangler 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:

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

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.

Solution

Wireshark finally runs on Windows 7-64, 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.