Attending a Seminar? Be Sure to Setup Your Lab System In Advance!
Last updated: 1 December 2021 (to reflect Win 11 WDK)
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 seminar. If 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
You always need two systems running Windows to develop drivers: You need a Development System, with Visual Studio and the Windows Driver Kit (WDK) installed for writing and building your driver. And you need a Test System, which is the system on which you’ll be running the driver code that you build on your Development System.
For doing the labs during your seminar, we assume your Test System will be a virtual machine running under VMware on your Development System. Other setups are possible, but — as we said before — our instructional team will not be able to help with anything other than the setup that we describe here.
Your Development System must be running 64-bit Windows 7 SP1 or later. A recent version of Windows 10 (at least version 2004, that is 20H1, or later) or Windows 11 is recommended. Please have your Development 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 hard-wired is fine). Also, if you’re taking the WDF I seminar, you’ll need at least one available USB 2.0 capable port (with a “USB type A” connector or adapter) to use with the OSR USB FX2 board, if you choose to do the USB exercise. We strongly recommend a system with at least 8GB of memory and 60GB of free disk space. Because you’ll be running a virtual machine on your Development 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 system that’s not domain joined and is not “managed” by your employer’s IT department is usually best. A lot of students use “test” laptops, with clean installs of Windows and the tools described below to class. This almost always tends to work 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.
If you’re doing the lab exercises from home or from your office, you can use whatever system you normally use for development, assuming you can successfully install the software we list and you have successfully tested it (as described later).
Your Development System will need to have the following software installed:
- Microsoft Visual Studio (VS) 2019 with the latest updates, the Windows 11 SDK, and the WDK for Windows 11. At this time, you can NOT use Visual Studio 2022 to build drivers.
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 11 you can use that. You don’t need to reinstall VS just for the class.
The links and complete installation instructions for downloading and installing VS, the WDK, and the SDK can be found at https://docs.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk.
To install VS, the SDK, and the WDK 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 may need to select “Individual components” and then check the box to install the “MSVC V142 – VS2019 C++ x64/x86 Spectre-mitigated libs (Latest)” as shown on the WDK download page.
The Microsoft WDK download page looks like this:
- VMware Workstation Player 15.5 (or later) – This software is available from http://www.vmware.com/products/player. 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 Development 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 11WDK, and the VMware product of your choice thoroughly before class begins. Detailed instructions for testing are provided below.
If you have ANY questions regarding the required configuration, please contact our seminar team: seminars at osr.com.
Have Your Lab System Ready and Tested Before Class Starts
We know you’ll be super-busy at work before your seminar begins. 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.
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:
- 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.
- 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.
- 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.
- 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.
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 especially if 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 10 V2004 (20H1) or later 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:
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 10 V2004. THIS is why we specifically recommend using Windows 10 V2004 and VMware 15.5 (or later).
To use VMware on systems that are not running Windows 10 V2004, 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.
OSR Open Systems Resources, Inc.