Windows 8, VMWare, HAL_INITIALIZATION_FAILED, VirtualBox and broken network bridging

A couple of days ago I downloaded Windows 8 to port my C++ code to this new platform. I tried to install
Windows 8 into my good old VMWare Workstation 5.5.9 where I run my other virtual machines, but ended up getting a HAL_INITIALIZATION_FAILED error message when booting from the .iso:

But since word was on the street that VirtualBox 4.1.2 could handle Windows 8 I gave that a try.
Unfortunately the Windows installer kept hanging while "Expanding Windows Files" while installing it onto
the VirtualBox virtual machine.

After some trial and error I changed the number of processors/cores in the VirtualBox virtual machine settings to the same number of processors/cores as on the host system, in my case two. This change seemed to do the trick and the installation completed without any other issues.

When I went back to run my VMWare virtual machines I noticed that their brigded networking was no longer working :( Switching to NAT and it worked fine, back to bridged and no network connection. For some reason the installation of VirtualBox caused my existing bridged connection to fail. Anyway, the solution was to explicitly set the network adapter VMWare should bridge with, in my case the Wireless adapter:

Hope this helped someone. Now I'm going to try the 64-bit version of Windows 8.

How to find the process that is using a TCP port

Earlier today I was inspecting all computers in my home for malware with the help of GMER and FreeFixer. I was also using the netstat command line tool to look for any suspicious network connections. Netstat shows established TCP connections and ports that are listening for incoming connections. There was one entry in the netstats output that looked a bit suspicious: A connection to a server at cust.tele2.se on port 5938 and cust.bredbandsbolaget.se, also on port 5938.



The problem with netstat is that I couldn't see the name of the executable file that had established this connection. As usual Sysinternals comes to the rescue. They offer a tool called TCPView which also shows the process name along with connection info. It turned out that TeamViewer that I recently installed had established the cust.tele2.se:5938 connection:



Another alternative to find the process name that owns a connection is to use netstat -o which will list the process identifier for each connection and compare it to the information listed in the Windows Task Manager.