Windows System Software -- Consulting, Training, Development -- Engineering Excellence, Every Time.

OSR Driver Development Seminar Lab System Setup Requirements

Coming to a Seminar?  Don’t Forget Your Laptop!

Attending a Seminar Remotely? Be Sure to Setup Your Lab System In Advance!

Last updated: 30 October 2020 (to reflect remote attendance); 20 July 2020 (to reflect WDK 2004 and VS 16.6)

When you attend an OSR seminar that includes lab exercises involving driver development, you’ll need to have access to a pre-configured Lab System to do the labs.

The Lab System setup requirements can vary depending on the particular class you’ll be attending.  So please make sure to check with the OSR Seminar Team to determine the setup requirements that apply to your specific seminar.

Which Seminar?

This page describes the general lab system setup requirements, and are primarily designed for our WDF Core Concepts seminarIf you’ll be attending a different seminar, the requirements might be different.  Check with the OSR Seminar Team well before the start of your seminar so you know what you’ll need.

We’re also not as strict about requirements for more advanced seminars as we are for the more introductory level seminars. For example, if you’re attending our  WDF II (Advanced Implementation Concepts) seminar we still recommend you use the standard setup.  But given that if you’re attending this seminar you’re an experienced WDF developer, we assume you know what you’re doing and we’re happy to have you use whatever development environment and tools you prefer.  The only caveat (and it’s a significant one) is that our instructional team will not be able to help with anything other than our standard setup.  So, if you need help debugging a problem and you’re using the Windows Enterprise WDK, building from the command line, editing with vim, and trying to debug your driver running on VirtualBox… you’re basically on your own to make all that stuff work during class.

Standard Lab System Setup Requirements

Your Lab System must be running 64-bit Windows 7 SP1 or later. Running version of 2004 of Windows 10, V20H1, is strongly preferred — we’ve got a good reason that we’ll explain later. Please have your lab system updated with the latest Windows Updates and ensure your Internet access works (if you’re coming to an in-person seminar, either WiFi or hardwired is fine). Also, if you’re taking the WDF I seminar, you’ll need at least one available USB 2.0 port for the USB exercise. We strongly recommend a system with at least 4GB of memory and 60GB of free disk space. Because you’ll be running a virtual machine on your lab system, “more memory is always better.”

While almost everyone’s lab system configurations work without any problem, we’ve occasionally seen people bring laptops to our seminars that are configured by Corporate IT departments with “security” software (network proxies, remote management agents, document management and tracking, access control, and the like) that have a variety of problems during the seminar. Some network proxies, for example, can make it impossible for the debugger (WinDbg) to download symbols that you’ll need from the Microsoft symbol server.  Bottom line: If you have a choice, keep it simple.  A lab system that’s not domain joined and is not “managed” by your employer’s IT department is usually best.  A lot of folks bring “test” laptops, with clean installs of Windows and the tools described below to class. This almost always tends to workout well and, if you have a choice, is what we most strongly recommend. An, older, slower, system, that’s been installed and configured specifically for class without corporate management and security software, is almost always preferable to a newer, more powerful, system that’s domain joined and centrally managed.

In addition to the base Windows installation, you will need to have Visual Studio 2019 V16.6 or later, and VMware (Player or Workstation Pro) V15.5 or later. Notes on installing these two products:

  • Installing Microsoft Visual Studio (VS) 2019 V16.6 with the latest updates and the WDK for Windows 10 Version 2004.  If you’re installing Visual Studio specifically for this class, we recommend you install Visual Studio Professional. If you already have VS 2019 installed on your system and working with the WDK for Windows Version 2004 that will work just fine. You don’t need to reinstall VS just for the class. Please be sure you install the Windows 10 10.0.19041 SDK and the necessary Spectre mitigated libraries as part of installing VS 2019.  The links and complete installation instructions can be found at  They look like this:

Please, go to the WDK download page, and read and follow the instructions carefully. Particularly note the Microsoft instructions about installing the Spectre mitigated libraries. You will need to manually select the x64/x86 versions of these libraries to install. This means that in addition to selecting the “Desktop development with C++” workload, you will need to select “Individual components” and then check the box to install the “MSVC V142 – VS2019 C++ x64/x86 Spectre-mitigated libs (V14.xx)”  – where xx matches the version number of the “MSVC V142 – VS2019 C++ x64/x86 build tools (V14.xx)” that are being installed as shown below:

  • Installing VMware Workstation Player 15.5 (or later) – This software is available from  If you or your company doesn’t already have a license and you don’t qualify for the “free trial” of this product, you’re responsible for the retail license cost of $149 for this product (which is not included in the cost of your seminar). The VMware installation on your lab system will host a Windows 10 x64 virtual machine provided by OSR that will be used as the target system on which to test your drivers during class. VMware Workstation Pro 15.5 (or later) may be used in place of the VMware Workstation Player. In fact, if you’ll continue to do driver development using VMware after your seminar, OSR recommends you select Workstation Pro due to its increased functionality and flexibility over Player.  But either version will work equally well during your seminar.

    The VMware VM that OSR provides for your class is simply a client VM image running Windows 10 – nothing else is installed in this VM. Please be aware that the names of the VMware products (that is “Player” and “Workstation Pro”) have changed several times over the past few years.  The terminology above reflects the names that were current as of VMware V15.  Contact the OSR seminar team if you have any questions about which VMware product you need to install.

Please be sure to test your installation of Visual Studio 2019 and the Windows 10 WDK V2004, and the VMware product of your choice thoroughly before class begins.  Detailed instructions for testing are provided below.

If it is not possible for you to provide a suitable system, or you have ANY questions regarding the required configuration, please contact our seminar team: seminars at

Have Your Lab System Ready and Tested Before Class Starts

We know you’ll be super-busy at work before you your seminar begin.  But, do yourself a favor:  Reserve an afternoon before the start of your seminar to install the required software on your lab system, and to test that software.

If you leave the installation, configuration, and testing until after the seminar starts, you’re just making things harder on yourself. This is especially true if you’re attending the seminar in person. Internet connections at hotels aren’t always the greatest, right?  Not to mention that we promise you that you’ll be tired after the first day of your seminar (the first day is almost always 100% lecture).

How to Test Your Lab System Setup

If you’re already familiar with Windows driver development using Visual Studio and VMware, you know what to do to test your installation to make sure everything is properly configured and working.  If you’re new to Windows driver development, here are some steps that you can take to test your installation to be sure you’re ready to go for your seminar’s first lab session:

  1. Basic Validation: Start Visual Studio. From the VS “File” menu select “New” and then “Project”.   A “New Project” dialog should appear and under “Installed” and “Visual C++” should be an entry named “Windows Drivers” with several types of sub projects under it.   If this is what you see, “Cancel” out of the dialog and proceed to Step 2.   Otherwise check and re-check your VS and WDK installation before you do anything else. If you continue to have problems, contact the seminar team by email.
  2. Check the Debugger: Ensure that the Windows Debugger (WinDbg) is installed on your development system and that you can start it. You should find windbg.exe in the directory %ProgramFiles%\Windows Kits\10\Debuggers\x86\ — You might want to put a short-cut in your tool tray to the file in this directory. Note that depending on how you installed the SDK, you may also have an entry for WinDbg in your Start screen. This will point to the version installed by the SDK.
  3. Build a Test Driver: The final test for Visual Studio is to build a sample driver using the WDK.  For this test, you’ll build one of the starter “template” WDF driver projects.  If you won’t be attending a WDF seminar, don’t worry.  The goal here is just to test that Visual Studio and the WDK are installed and working.  If you can build one type of driver, you’ll be able to build any type of driver we’ll be creating in class. For this test once again start Visual Studio.  Select “Create New Project” from the startup dialog and change “All Project Types” to “Driver”.  You should now see several driver project templates.  Select the one that reads “Kernel Mode Driver (KMDF)” in the center pane, like you see below:

    Click “Next” and ensure that you have access to the path in the “Location:” box (if not, adjust properly).  Click the “Create” button.  Wait for the template project to be generated.  Once the project has been successfully created, ensure “Debug” and “x64” are selected as the Solution Configuration and Solution Platform, respectively.  Then, right click the solution and select “Build Solution” from the pop-up dialog: Within a few seconds, the build should complete and the Visual Studio output window should indicate that the build is successful: If the build succeeds, you know that your lab system configuration of Visual Studio and the Windows Driver kit is ready for your seminar!  Next, test your VMware installation.

  4. Test Your VMware Installation: If VMware installed without any errors, that only indicates that the installation is correct.  You still have to make sure you can successfully start and run a virtual machine (VM).  To test this, download and start a small VM of any operating system.  We recommend something like the Tiny Core Linux VM that you can download from this link.  Download the VM image (it’s a 12MB “OVA” archive).  Then start the VMware product you’ll be using (either Player or Workstation), and open the downloaded OVA file the VMware “File… Open” dialog.  This will decompress the OVA file and start it. The Tiny Core Linux VM boots in less than 5 seconds, even on a slow system.
Start this Tiny Linux VM to test your VMware install
Start this Tiny Linux VM to test your VMware installVMware is particularly good about diagnosing incompatibilities and letting you know about any problems it finds.  So, if you can successfully start the virtual machine, VMware works and you’re ready for your seminar!

If you have problems, check the steps carefully.  If you can’t diagnose the problem on your own, contact the OSR Seminar Team and one of our engineers will try to help you.

Having Trouble?  Can’t Run VMware?  Other?

To make your life simple, we recommend you using a lab system that’s not domain joined and not subject to your employer’s remote management scheme (if there is one). By far, the majority of problems we see in class with people setting up lab systems are due to their trying to do stuff to managed systems that their employers make difficult.  So, if you’re everyday system is company managed, and you’re attending your seminar in person here at OSR, you might consider bringing a separate, non domain-joined, “test” laptop that you setup specifically for use in class.

If you are NOT running Windows 2004 (20H1) and VMware 15.5 (or later) on your lab system you might get a dialog box like the following when you try to start the test VM within VMware:

VMware Workstation and Device Guard are not compatible.

You will get a similar message even if you don’t have Device or Credential Guard enabled, but you have Hyper-V installed.  VMware and Hyper-V cannot co-exist on versions of Windows before Windows 2004, and VMware 15.5. However, they CAN be installed (and even running) at the same time starting with VMware 15.5 and Windows 2004. THIS is why we specifically recommend using Windows 2004 and VMware 15.5 (or later).

To use VMware on systems that are not running Windows 2004, you’re going to have to disable Hyper-V on your system.  The easiest way to do this is to just turn the Hyper-V feature OFF on your system.  Don’t worry, you can enable it again at any time if you want to.  Go to the “Turn Windows Features On or Off” dialog, and uncheck Hyper-V. The dialog is shown at the left.

Click OK and follow the instructions.  You’ll have to reboot.  When you do, Hyper-V will be disabled and you should be able to use VMware.

Note that instead of turning Hyper-V off as described here, it is sometimes possible to disable Hyper-V use using bcdedit.  We do not recommend this approach, however, because (depending on your system configuration) Windows may just turn it on again.

Another reason folks have trouble running VMware is because Device Guard or Credential Guard are enabled on their lab systems, and they are running a Windows version prior to 2004 (20H1).  Manually enabling and disabling these features can be challenging… but there’s an easy solution.  To disable Windows Defender Credential Guard and Windows Defender Device Guard, download the the Windows Defender Device Guard and Credential Guard Hardware Readiness Tool.  And run it as follows:

DG_Readiness.ps1 -Disable -AutoReboot

Whenever seminar attendees have had Device Guard or Credential Guard issues, we have been 100% successful in getting these features disabled with the above procedure.