How To: Boot the WRK in a Virtual Machine

By Alexander Schmidt

In a previous post, we showed you how to debug the WRK on a Mac OS system using Sun's VirtualBox. However, in that post, I only concentrated on how to link both virtual machines but not on how to create a WRK-ready virtual machine (VM), because I thought that this task is well documented on the WRK DVD. Unfortunately, on the latest revision of the WRK DVD (verion 1.3, series F), this documentation is missing. In general, this is not a problem, as Microsoft provides a WRK-ready Virtual PC image on the DVD, where all the settings have been done already, but it is of no help, if you plan to use VirtualBox in your environment. In this article, we want to re-iterate over the steps necessary to run the WRK in your virtual machine.

In this article, we assume that you are using Sun's VirtualBox, but it should work with other vendors as well.

Disabling automatic updates

First of all, you must install Windows Server 2003 with Service Pack 1 in your virtual machine. You may choose between the 32-bit or 64-bit version, but the service pack version must be the exact same! Once the installation is complete, we recommend adjusting the Windows Update policy such that updates are not installed automatically. This step is necessary, as Windows Update will probably download a higher service pack version, which the WRK might be incompatible with.

Determining the HAL Version

The WRK requires a multi-processor version of the hardware abstraction layer (HAL) library, which abstracts from all the chipset specific settings of your mainboard. If the VM is not a multi-processor VM, the Windows Server 2003 installation process may choose to install the single processor version of the HAL. To figure out, which HAL you have on your VM, go to the %systemroot%\system32 directory and right click on the HAL.dll file, and select Properties. In the appearing dialog, choose the Version tab and select the Internal Name property, which shows you the internal name of the selected file.

Depending on the internal name, you need to copy one of the following files from the Resources\Windows_Research_Kernel\Get_WRK\WRK-v1.2\WS03SP1HALS\ folder on the DVD to the %systemroot%\system32 on your VM.

Internal Name	File to Copy
halacpi.dll	halacpim.dll
halaacpi.dll	halmacpi.dll
halapic.dll	halmps.dll

Deploying the Kernel

Once you have built the WRK, copy the resulting executable (either wrkx86.exe or wrkamd64.exe) to the %systemroot%\system32 folder on the WRK VM.

Configuring Boot Options

The last step to make your VM WRK-ready is to update your boot.ini file, which resides in the root directory of our boot partition (probably C:\). To edit the file on your VM, click on the Start menu, right click My Computer and select Properties. In the properies dialog, click on the Advanced tab. In the Advanced tab, click on the Settings button in the Startup and Recovery section:

In the Startup and Recovery dialog, click the Edit button, which opens the boot.ini file in the Notepad editor.

Edit the file as follows:

[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, Standard" multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, WRK" /kernel=wrkx86.exe /hal=<your HAL> /debug /debugport=com1 multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows Server 2003, WRK - No Debugger" /kernel=wrkx86.exe /hal=<your HAL>

Update <your HAL> with the appropriate file name from the above table. Note that the filenames must be short (8.3) names.

Information about aditional boot options, such as the /debug switch, can be found here. For configuring the debugger, you may also have a look at this post. Do not forget to safe the file. You can then close the editor.

Booting the WRK

Once you configured the boot.ini file, re-boot the system. If you configured the operating system name of your boot.ini file as mentioned above, you should now see the following boot screen:

The second entry boots up your WRK with the debugger stub being active, while the last entry just boots your kernel without any debug features.