Hiding command window when running VirtualBox Headless

I discovered a couple things today. First, VirtualBox 4 appears to be less resource intensive than Vmware Player for the same workload.

Second, while VirtualBox provides the ability to run in a headless manner (aka hidden, or in the background), the command line tool to do so must be left open (on windows at least)

Yeah… kinda defeats the purpose of being headless.

If you close the cmd window, it kills your VM.

The solution: well here, I’ll just attach it:
(Requires .NET Framework 4 Client Profile)

Just drop it in your c:\Program Files\Oracle\VirtualBox folder (or wherever you installed it to) and invoke it the same as you would VBoxHeadless.exe. Instead of staying open, it will print out the response from VBoxHeadless.exe and return, leaving it running in the background.

All this app does is create a process with a hidden window and passes through the parameters.

Update 9/13/2011: If you are having problems with this not working or otherwise erroring out, it might be because of spaces in the VM Name. Try renaming the VM without spaces and see if that fixes it.
(Thanks David!)

Here is the source code if you are curious.

using System;
using System.Text;
using System.IO;
using System.Diagnostics;

namespace VBoxHeadlessSilent
    class Program
        static void Main(string[] args)
            string headlessPath = "";
            string argString = "";

            for (int i = 0; i < args.Length; i++)
                argString += args[i] + " ";

            headlessPath = Path.Combine(Environment.CurrentDirectory, "VBoxHeadless.exe");
            if (!File.Exists(headlessPath)) headlessPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles), "Oracle", "VirtualBox", "VBoxHeadless.exe");
            if (!File.Exists(headlessPath)) headlessPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86), "Oracle", "VirtualBox", "VBoxHeadless.exe");

            if (File.Exists(headlessPath))
                Process p = new Process();
                p.StartInfo.FileName = headlessPath;
                p.StartInfo.Arguments = argString;
                p.StartInfo.UseShellExecute = false;
                p.StartInfo.CreateNoWindow = true;
                p.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
                p.StartInfo.RedirectStandardOutput = true;
                Console.WriteLine("Could not find VBoxHeadless.exe!");

Launching Internet Explorer without address bar in .NET

I needed to launch an Internet Explorer window to a particular URL in a near “chromeless” fashion – no toolbar, no address bar, no scrollbars, from a C# .NET application. At first I used thread.start(url), but you cannot specify how Internet Explorer should open – there are no command line options to customize the window.

The internet failed me – I was supposed to reference some web COM dll, that I didn’t even have.

The solution is painfully simple. Make sure you have a reference to System.Windows.Forms, create a WebBrowser object in code (no need to add it to a form), give it an about:blank url, then use Document.Window.OpenNew() to launch a new IE window with parameters.


Examples speak louder than words: this snippet will open google in a new browser window

using (WebBrowser wb = new WebBrowser())
    wb.Url = new System.Uri("about:blank");
    wb.Document.Window.OpenNew("http://google.com", "location=no,menubar=no,scrollbars=no,status=yes,toolbar=no,resizable=yes");

If you will be opening a lot of windows, maybe you should keep the WebBrowser object in a class variable.

Maybe this one was out there somewhere, but I couldn’t find it…

CRM 4.0 loader.aspx specify default page parameters

Lets say you want to provide a direct link into CRM (4.0) that opens it up to a particular Area / Section / Entity. Microsoft provides documentation on opening specific Views and Forms, but as far as the internet is concerned, loader.aspx accepts no parameters.

Well, this isn’t entirely true :). Digging through some of the CRM internals, I was able to determine that loader.aspx accepts two parameters: “page” and “area”. The meanings of these fields are a bit reversed. “page” refers to the sitemap Area Id (“Workplace”, “SFA”, “MA”, “CS”, “Settings”, “ResourceCenter” are out of the box). “area” refers to the subAreaId – probably the easiest wat to find this is using Internet Explorer dev tools.

I should note that this is unsupported: you cannot expect it to work past any patches.

For example, if you wanted to provide a link that opened CRM to the Workplace section -> Accounts, you would using the following url:


It also works with custom entities – generally the area for custom entities is simply the logical name.

So there you have it – hope this helps somebody!

Getting fingerprint reader working on Dell laptop

Dell really likes ot make it tricky to get the fingerprint reader working when you install Windows from scratch.

Update 9/7/2012:
Good news! Dell has quietly released a single installer that takes care of installing all the sub-components correctly, in the correct order (thanks Mark for pointing this out). As of this update, the latest version (for the e6520) is here:


The catch: you have to follow a specific procedure to uninstall any old versions. Also, I don’t know if this allows you to use the lighter-weight biometric framework version. I probably won’t try it until they start supporting Windows 8.


UPDATE 8/25/2011: Dell has released new firmware, software and several different drivers for the fingerprint readers, whihc I have not had time to evaluate yet. My experience with the first release of the “Data Protection | Access” is that is is poorly documented, incredibly slow, buggy, and flat-out not worth the effort. Fingerprint login took so much longer than password login that I stopped using it, and did not install the drivers when I later reinstalled windows.
When I get a chance to evaluate the new drivers (which will involve some image backups) I will update this post. See the comments for some more info.

Previously, you had to download several different ControlPoint packages and install them, hoping one was the right one. Well now as of the dell E6520 they have renamed everything to Dell Data Protection | Access (Dell data protection access). You will need to download these three packages and install in this order:

Data Protection | Access — Driver Package

Data Protection | Access — Middleware Package

Data Protection | Access — Application Package

You might also need the ControlVault driver, but I’m not sure – I did for safety’s sake. Update: Do NOT install the ControlVault driver. This will cause “no fingerprint reader found” rn 02000051 error message.

I hope this helps somebody.

UPDATE: If you did install the ControlVault driver, try using system restore to roll back (This is what I did after installing the driver a second time, after reinstalling windows to recover from the first time…). Uninstalling will not remove it. If System Restore doesn’t work, you will probably need to reinstall windows (or call Dell)
Reader Kristof posted some steps in a comment below that other folks confirmed successful – I’m quoting it here for reference:

I also installed the controlvault, but did not have to reinstall windows (restore points were disabled). I solved it as follows:
– uninstall controlvault
– remove fingerprint reader from installed hardware (when it asks, also remove driver)
– uninstall all other DELL Data Protection things you might have installed
– reboot
– reinstall ONLY the Data Protection tools as described in the post
– reboot

and then it just worked… (finally!)

D-link router_info.xml (and other interesting things)

It occurred to me that if D-Link has a desktop gadget that can poll bandwidth statistics from my router (DIR-628) then I should be able to do the same!

Turns out the router has a web service of sorts at http://<router ip>/router_info.xml?section=<section name>

where section is one of:

(Note: I found these by digging through the firmware)

Perfect! If you poll this service, you get stats (and much more) all packaged up in XML. There is something potentially troubling, though. The ddns and wlan_stats sections provide cleartext passwords, even if you are logged in with normal user credentials. In other words, all a person would need in order to get the wireless password is about 10 seconds plugged in to an ethernet port.

This isn’t the only little bit of undocumented goodness though. Here are a bunch of undocumented urls that provide info of various sorts:


Some of them would appear to provide data for the router interface’s ajax – I would assume all the information is also avilable via the interface. It’s just nice to have access to XML.

Have fun!