Disabling the VMWare network adapters

When you are not running a VMWare session, you may want to disable the VMware virtual network adapters. I have found that they can slow down network operations on the host. Anything doing a UDP broadcast that is sentg over all adapters will take much longer to run if they broadcast over the VMWare adapters. The ListAvailableSQLServers function call in the SQLDMO library is one example that I came across that slowed down dramaticly with the VMWare adapters running.

You have at least three ways of enabling and disabling the network adapters. You can open up the Device Manager (click the “Start” button, select “Run…”, enter devmgmt.msc), select the “VMware Network Adapter VMnet1” and “VMware Network Adapter VMnet8” adapters and press the disable button in the tool bar. The second option is to right click on “My Network Places” in the Start menu and select “properties”. You can then right click on the “VMware Network Adapter VMnet1” and “VMware Network Adapter VMnet8” adapters and enable or disable them. The third method is via the command line, so that you can script it.

Microsoft, in it’s infinite wisdom, does not provide a command line means of enabling or disabling network adapters out of the box. For that, you’ll need DevCon.exe, the command line alternative to Device Manager. You can get from Microsoft as Knowledge Base article Q311272. With devcon, you can disable/enable a netwoirk adapter by it’s hardware id. You can get the id from Device Manager, or by running devcon.exe like this:

devcon hwids =net

That will spit out a great deal of information, the ID’s that you are looking for are *VMnetAdapter1 and *VMnetAdapter8. You can disable them individually or do both with a wildcard

devcon disable *VMnetAdapter1
devcon disable *VMnetAdapter8

or

devcon disable *VMnetAdapter*

The former probably executes faster, the latter is simpler. I run with the adapters disabled and I only enable them whem I am running a VMWare session.

If you are running Windows 7, you should head to Windows Driver Kit (WDK) Version 7.1.0 Release N, which includes a version of devcon that will install under Win7 64bit.  If you have an older release of the WDK, you can extract the devcon.exe out manually.  A commenter left a link to a post that included the following instructions:

  1. Download the “Windows Driver Kit (WDK) 7.1.0 from MS, it is an ISO image of several hundreds meg in size.
  2. Using UniversalExtractor (http://legroom.net/software/uniextract) extract the ISO to a temporary folder.
  3. Again using UniversalExtractor, extract the install file “WDK\setuptools_x64fre.msi” to a temporary dir
  4. In that temporary dir you will find “WinDDK\7600.16385.win7_wdk.100208-1538\tools\devcon\amd64\devcon.exe”. It may be in a different folder hierarchy, but it should look like.

Along the way UniversalExtractor will prompt you with some warnings, just click OK. With Windows Vista and Windows 7, it will need elevated administrator rights to run.

Exceptions and Threads

Scott Allen has a good post about a difference in how unhandled exceptions are dealt with in .NET 2 from how they were handled in 1.1 In 1.1, if a thread has a unhandled exception, the app would continue to run and there wouldn’t be any notice of an error. In .NET 2.0, an unhandled exception in a thread will take out the app, just like if it had occurred in the main thread.

I’m not sure how other people will like that, but that’s good news in my book. If an unhandled exception is going to take down an application, then it should happen across the board, not just in the main thread.

One of the projects that I am working on now is a set of services (.NET 1.1) that collect data from 3rd party GPS vendors. They are multi-threaded and I have spent a good deal of time working on the concurrency issues and error handling. If one of the background collection threads goes down, I really want to know about. I have try/catch in all of the places that need it, but if I have missed something, I want it to go down in flames instead of pretending nothing has happened.

Service applications, by their very nature, need to be able to document when an exception occurs. Writing to the Windows event log is pretty much a requirement. When the excrement hits the rotating air displacement device, the event log is your friend. I’ve been using Log4Net and logging error messages to my email account through it’s SmtpAppender.

Log4Net was a pain to getting working, but it’s a much simpler mechanism than the Logging block in Enterprise Library. One of the requirements of the service is that it be easy to configure for the end user. I don’t want the end user to have run or even know about the “Enterprise Library Configuration console” that the Enterprise Library uses to manage the configuration settings. It’s a whole lot of overkill for what I needed.