Last year for Workstation 6.0, one of the features we added was a plugin for Visual Studio 2005 that allows developers to debug a project (native and managed C/C++, C#, or Visual Basic) inside of a Windows virtual machine (specifically Windows 98, Windows 2000, and later).  All of you Windows developers know how much of a pain it is to support multiple versions of Windows, but this tool is designed to make that process much, much easier.  The Visual Studio Integrated Debugger (VSID in short) plugin utilizes Visual Studio remote debugging technology to allow you to debug a project inside of a VM as if you were debugging on your host computer with the click of one button.

The plugin's toolbar and menu, added to Visual Studio 2005:

The most difficult part of getting all of this to work is the initial setup.  Once you can get your configuration working, it should work well for a long time.  But it is certainly a chore getting your host and guest set up to comply with all of the security regulations that Microsoft requires to successfully remotely debug on another machine.  This walkthrough is intended to get you through the process of setting up remote debugging and provide helpful troubleshooting tips in case everything does not go smoothly.

For a full list of all setup steps, Chapter 2 in the VSID manual is a must-read (open up Visual Studio 2005 and go to the VMware menu and click Help Topics), but I will try and summarize the main points.  The first thing you will need to do is to make sure that you have the same username and password on your host and guest.  This is a built-in security requirement so not just anyone can remotely debug in your machine; Visual Studio automatically uses your host's login and password as authentication and if they are different than the guest's, it won't work.  It is very strongly recommended that both your host and guest be on the same domain (or if not on a domain, that they both be in the same workgroup), although my own testing has shown me that it is not always necessary.  Anecdotally, I have found that Vista hosts are a little more strict about this than XP hosts, but it is certainly suggested if at all possible.

The next task is to configure the firewall on both your host and guest.  For the guest, we recommend that you disable the firewall.  For the host, I would recommend that at the least, you set Visual Studio as an exception so that the firewall leaves it alone.  If possible, I have found it helpful to disable the firewall on your host as well, because it can sometimes be a bit disruptive.  If you have any other security products running on your host or guest, you should make sure that they are also configured correctly.  For more information about setting up remote debugging, here are some instructions from Microsoft.  This is such a crucial step and I have found that most remote debugging failures come from a host firewall blocking remote debugging.

The final step in setting up remote debugging is changing a few settings in your guest.  Here is a short list:

1. Disable the security prompts that come from running programs off a network share (which is what happens when the plugin runs your host program in the guest through Shared Folders).  To do this, open up Internet Explorer, choose Tools > Internet Options > Security > Local Intranet, click Sites, click Advanced and add a new Web site "file://*..host" (without the quotes).
2. Make sure the name of your virtual machine is unique on the domain.  Conflicts like this often happen if virtual machines are cloned and handed around between multiple people.  To change it, go to Start > Control Panel > System > Computer Name and select Change.  On Windows 2000, the tab is named "Network Identification" instead of "Computer Name".
3. For Windows XP virtual machines, change the guest user authentication scheme to Classic.  To do this, go to the Control Panel > Administrative Tools > Local Security Policy > Local Policies > Security Options page and set "Network access: Sharing and security model for local accounts" to "Classic - local users authenticated as themselves".  Windows XP Home does not have this setting and does not respect it even if you set the corresponding registry key, so that's why we don't support debugging in XP Home guests.
4. If you are running a Windows 98 VM, you will need to perform a couple of extra steps.  Take a look at the VSID user manual for the list.

Now that you have your virtual machine set up for remote debugging, it's time to set up your Visual Studio project.  Thankfully, this is much easier.  If the VSID plugin has been installed in Visual Studio 2005, you should see an extra toolbar and a VMware menu.  To configure your project, open up your solution in Visual Studio and go to the VMware menu and click Options.  To set up your project for remote debugging enter the following pieces of information:

1. In the Command space, enter the full path to the executable that you want to debug in the guest.  If it is a path on your host machine, make sure "Run Command as" is set to "a host path through a shared folder".  If it is a path in your virtual machine, make sure that "Run Command as" is set to "a guest path".
2. Verify that the Remote Debug Monitor path is set correctly.  If you are debugging a 32-bit application, it should be the path to the 32-bit remote debug monitor.  If you are debugging a 64-bit application, it should be the path to the 64-bit remote debug monitor.  Typically, the 32-bit remote debug monitor is installed in %Program Files%\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x86\msvsmon.exe.
3. Click "Virtual Machine" in the left column and enter the path to the virtual machine in the "Virtual Machine" space of that page.
4. Look through any other options that you would like to specify.  However, all other settings are optional or already have a default specified.

One of the configuration pages:

If all goes well, you should be able to start debugging in your virtual machine by hitting VMware > Start.  If you get an error message, the unfortunate situation is that the Visual Studio extensibility framework doesn't give us any information about why debugging failed, so you are left to go through more official routes to get that information.

The first reason why debugging often fails is that your virtual machine is not configured to run your application properly.  If your application requires the .NET Framework to be installed, make sure that it is installed.  You should also make sure that all the dll's you need are registered in the guest and any other configurations are all correct.  To verify that your application is configured properly, simply go to the VMware menu in Visual Studio and select Start Without Debugging.  If your application runs properly, then you don't have any of these problems.  But often times you will see an error message complaining that a required component is missing.  This is probably the reason why remote debugging is failing, because Visual Studio is trying to debug the program in your guest but the program can't even run successfully.

If you are still running into problems, the next step is to manually remotely debug in your virtual machine using Visual Studio's built-in framework.  The reason why this is important is that Visual Studio will give you much more descriptive error messages than the extensibility framework gives to the plugin.  Here are the steps to set it up using a C/C++ project:

1. With your virtual machine running, go to Workstation, open up the VM Settings editor, select the Options tab, and select Shared Folders.  Enable Shared Folders and add two shared folders: 1) Add the folder your application is being compiled in on your host machine; name it "Project". 2) Add the folder where the remote debug monitor is on your host machine; name it "RDM".
2. Go into your guest and open up ..host\Shared Folders\RDM\msvsmon.exe.  This is the equivalent of running your host's remote debug monitor in your guest.
3. Open up the Project menu and select Properties.  Open up the Configuration Properties node on the left and select Debugging.  Now write down any existing debugging settings you have, because we may be overwriting these.
4. Under "Debugger to launch:" select Remote Windows Debugger.  For "Remote Command", enter the path to your host executable using the Shared Folder you just created.  This will be \\.host\Shared Folders\Project\<executable name>.exe
5. Change "Remote Server Name" to the name of the server that the remote debug monitor created in your guest.  To find this, look in your guest at the remote debug monitor; it should say something like "msvsmon started a new server named 'grossag@foo'. Waiting for new connections."  In this case, the remote server name is grossag@foo
6. Now go to Start > Debug.  If remotely debugging through the VMware plugin wasn't working, then this should fail as well and give you a better error message.

If debugging fails with the following error, you should follow the troubleshooting tips above.

Well that's about it for me.  Good luck with remote debugging and feel free to post any questions that you have!  And I almost forgot that if you are looking for Visual Studio 2008 support, feel free to download our new Workstation 6.5 beta, although I will warn you that the current beta (build 84113) doesn't work well with debugging in Windows 2000 guests.

By now, many of you have probably heard about the newly enhanced “execution record / replay” feature of Workstation 6.5. You may remember this feature being originally introduced (experimentally) in Workstation 6, and may even have some experience trying it out. However, for a lot of people this is still an entirely new concept, so let us take a step back for a minute…

So, what exactly is this feature about? What can you do with it and what’s so awesome about is it?

Execution record and replay does exactly what its name implies – it allows you to record the execution of your virtual machine, and then to play it back later. This is where you may think “Oh, just like a movie, right?” Well, actually, not at all. :)

It’s not just some movie or a video recorded session – but, rather, much more then that. We are talking about literally recording the entire execution of your VM as it happens. Not just what you see, but everything that happens under the hood as well. Events, interrupts, memory, changes to disk contents, input and output… everything. And when you replay, you essentially get a carbon copy of what your entire VM was like at the same point while recording. All of the execution happens deterministically and in exactly the same fashion as it did while it was recorded! And, since we only record asynchronous events instead of interpreting every instruction to do this, we have a fairly low performance overhead.

So, what’s so cool about that? Well, one advantage of execution record / replay is its interactivity. For instance, let’s say that you decided while replaying a session that you would have liked to do something different then what was done at record time. Maybe you want to alter some of your actions half-way thorough the recording, or change the settings of some software running on the VM. Well, you can “take the VM live” as we call it – essentially, stop replaying and start interacting “live” with it from exactly the point of your choice. I guess one could think of the recorded session as prolonged super-snapshot of the VM over a long period of time, which allows you access and modification of said VM at any point during this time.

And if that’s not exciting enough for you, let me give you another example of this feature’s power. As everyone who writes code knows, code tends to have bugs. And some bugs, like cockroaches, tend to be worse then others. Anyone who has ever had to deal with a deadlock, a race condition, or any timing-related issue for that matter knows just how annoying and difficult these problems can be. You are sitting there all pumped up and ready to fix the problem, but Murphy’s Law guarantees that it just refuses to even happen for you in the first place – despite anything your try. But sure enough, the second someone else uses your application – or, better yet, you try to demo it – there it is. Sigh. And you are just left wishing you could somehow magically capture the bug as it happens, to be able to investigate it later… But wait, VMware has just right kind of magic! Record the execution of your VM, catch the issue in action once, and then have eternal access to it with the virtual debugger. (Check out Slava’s blog http://stackframe.blogspot.com/ for more details and cool info on debugging inside the guest.)

Well, enough of that. Let’s get to the cutting-edge stuff. What is actually new in WS 6.5 as compared to the experimental record / replay in WS 6? Quite a lot of things:

Enhanced Support:

- Execution record and replay for 32-bit guests on Intel P4, Core2, and Penryn

- Execution record and replay for 64-bit guests on Intel Penryn processors

- Support for CD-ROM devices

- Support for USB controllers

- Support for SCSI

- Support for LSI

Enhanced Record

- Save the state of the VM in “Markers” while recording, for faster access during replay.

- Set up disk space quota to limit how large your recording can grow.

- Set up automatic Markers, which get taken periodically as you leave your VM.

- Take a “rolling recording”, only saving the last ~30 minutes of it for example.

- Use VAssert to add replay-time only assertions to your applications.

Enhanced Replay:

- Easily control replay by pausing, changing replay speed, and going live at will.

- Browse the recording by dragging the play slider around and getting a pre-view of the guest state.

- Randomly access any point in the recording by dropping
                the slider at the target location.

- Add additional Marker points during Replay near points of interest.

- Crop your recording from the beginning or from the end at any Marker.

Overall, there are lots of new and cool things in store for you. Execution record / replay is a very powerful feature, so much in fact that it can difficult to truly grasp all of its aspects without trying it out for yourself. And that’s exactly what I urge everyone to do!

(Thanks to ksc, trowbrds, and slava_malyugin for their help and input.)

About two years ago, we conducted a survey of VMware Workstation users. While looking at the results we discovered that some of the common complaints included being unable to increase the screen resolution of VMs and having no idea how to "ungrab" the mouse after clicking inside the VM's console. This surprised us because both those issues are solved trivially by the installation of VMware Tools, which includes device drivers for the virtual hardware we present to the guest OS. After some initial head-scratching, we realized that users hadn't been installing our Tools software! Guessing that users simply weren't aware that this was necessary for a good experience, we attempted to gently educate them about the benefits of installing VMware Tools and providing more convenient access to instructions for doing so. Although that was a decent stopgap measure for Workstation 6.0, we knew that we could do better.

Meanwhile, in usability studies and during contextual inquiries we kept noticing that being asked to select the guest OS while creating new VMs frequently gave users the impression that the VM would already have the selected OS installed on it at the end of the process. Users kept powering on their new VMs and feeling like something had gone wrong because there was no guest installed on them. Again, we made a small change to the New VM wizard that informed them of the need to install a guest OS on their VM once it had been created. Not long after this, however, VMware Fusion shipped with the ability to install certain new versions of Windows onto a VM automatically. The feature was a big hit and we realized that we could incorporate it into the next release of Workstation as part of our effort to streamline the process of creating new VMs.

It's always a bit dodgy trying to release software on April 1st, but seriously, this isn't a hoax!  Really!

Hot off the presses, the first publically available beta for Workstation 6.5 is now available for download from VMware:

http://communities.vmware.com/community/beta/workstation6.5

Tons of great stuff to be tried out here.  Oh, and did I mention that it will even do your laundry for you?  (Ok, maybe that would be stretching the truth).  But nevertheless, you should definitely check it out.  No better time than now to give us the feedback we need to make sure that it works when for you when it does GA.

Ok, well, not quite "completely different."  Perhaps exactly the opposite.  VMware Workstation!  Yeah, you remember it: that sweet software that lives happily on your PC and helps you get things done!  The product on which VMware was founded!  Going strong for nearly a decade now!

So welcome to the "Workstation Zealot" blog!  Us "old-school" folks at VMware are finally getting into the 21st century and starting a up what we hope will be a great new source of news, information and amusement for the millions of Workstation faithful out there.  From time to time, you'll see postings from various developers in the team on interesting technical topics, thoughts on industry developments, highlighted use cases, beta announcements, insights into life in the Workstation trenches, and more.

How will this blog be different from other assorted VMware blogs?  Well, if you're someone who cares enough about Workstation to read a blog about it, you can probably consider yourself officially "hard-core" :-)  So we'll do our best to keep things lively with the sort of info that takes your clearly superior intelligence into account.  If we're lucky, even I'll be befuddled by some of what our development team will have to say, so stay tuned!

And of course, if there are specific topics you'd like to see us cover in a blog style format, don't be shy about sending along your comments.  If you're not reading, then we're screwing up.

Cheers!

Robert Baesman - Sr. R&D Manager - VMware Inc.