Windows has specific models for lots of other device types as well. Lacking a specific model for your device type, you can use one of the general-purpose models. WDM is the old, historic, model for writing Windows drivers. Nobody should use this model anymore for writing new Windows drivers.
Trying to write a new WDM driver in the 21st Century will do nothing but make you hate life. Enough said? This is the second general-purpose driver model that Windows supports. WDF is a modern, pleasant, and dare I say it almost easy to use method for writing Windows drivers.
One interesting thing about WDF is that it actually comes in three flavors, called Frameworks:. Using UMDF today is a bit of a problem. UMDF V1 is the older model. UMDF V2. To be absolutely clear, this means that if you write a UMDF V2 driver, that driver can only be installed on systems that are running Windows 8. In short, unless you only need to support Windows 8. On the other hand, if you do only need to support Windows 8.
We told you many people find this driver model stuff confusing. Fortunately, there are some simple rules that can help you decide the best driver model for your use. Here are those rules:. There are a number of factors that contribute to the decision of which driver model is best for you. You can read more about this on MSDN. Once you understand the driver model to use, you have to figure out how to write a driver using that model. The available books on Windows driver development are either lacking in practical detail, wrong, out of date, or all three.
While you could learn on your own, with trial and error and help from news groups, this is where we here at OSR can help! So, why spend the time and effort it will be weeks, at least trying to learn this discipline on your own when you have an expert resource you can use?
Seriously consider taking an OSR seminar. We teach all of our most popular seminars WDF , Internals and Software Drivers , Kernel-Mode Debugging and Crash Analysis , and even Windows File System Minifilters multiple times a year online, with a live instructor, so you can participate from locations all over the world.
Remember what we said earlier, that writing a Windows driver any type of driver is quite a bit more complicated than writing an application? CodeProject and Stack Overflow have their place… but that place is unfortunately not the world of Windows drivers. Learn a bit about Windows architecture, get the tools, and choose a model for your driver. The hardware ID for the device is displayed in the list box. Select and hold or right-click and copy the hardware ID string. Referencing both co-installers in the INF will lead to installation errors.
Reflector—If your driver gets loaded successfully, the reflector is loaded as the top-most driver in the kernel-mode stack. The reflector must be the top driver in the kernel mode stack. For more information, see Building a Driver. To test and debug a driver, you run the debugger on the host computer and the driver on the target computer. So far, you have used Visual Studio on the host computer to build a driver. Next you need to configure a target computer. To configure a target computer, follow the instructions in Provision a computer for driver deployment and testing.
The template code contains several trace messages TraceEvents that can help you track function calls. All functions in the source code contain trace messages that mark the entry and exit of a routine. For errors, the trace message contains the error code and a meaningful string.
Because WPP tracing is enabled for your driver project, the PDB symbol file created during the build process contains trace message formatting instructions.
If you configure the host and target computers for WPP tracing, your driver can send trace messages to a file or the debugger. You can use Tracepdb. The following command creates TMF files for the driver project. The -f option specifies the location and the name of the PDB symbol file. They are given GUID file names. Make sure you have the Tracelog tool on your target computer.
For more information, see Tracelog Command Syntax. The guid argument specifies the GUID of the trace provider, which is the client driver. As another option, you can type the following command and specify the GUID in a. The file contains the GUID in hyphen format:. For more information about deploying the driver to the target system in Visual Studio Professional , see Deploying a Driver to a Test Computer. You can also manually install the driver on the target computer by using Device Manager.
If you want to install the driver from a command prompt, these utilities are available:. This tool comes with the Windows. You can use this utility to add the driver to the driver store. For more information, see PnPUtil Examples.
DevCon Update. Visual Studio first displays progress in the Output window. Then it opens the Debugger Immediate Window. On the host computer, open your solution in Visual Studio. You can double-click the solution file, KmdfHelloWorld.
For Target Device Name , select the name of the computer that you configured for testing and debugging. In this exercise, we use a computer named MyTestComputer. Select OK. In this exercise, the hardware ID does not identify a real piece of hardware. It identifies an imaginary device that will be given a place in the device tree as a child of the root node.
The hardware ID is located under [Standard. On the Build menu, choose Deploy Solution. Visual Studio automatically copies the files required to install and run the driver to the target computer. This may take a minute or two. If something goes wrong during deployment, you can check to see if the files are copied to the test computer. Verify that the. For more information about deploying drivers, see Deploying a Driver to a Test Computer. With your Hello World driver deployed to the target computer, now you'll install the driver.
When you previously provisioned the target computer with Visual Studio using the automatic option, Visual Studio set up the target computer to run test signed drivers as part of the provisioning process. Now you just need to install the driver using the DevCon tool. For example, look in the following folder:.
On the target computer, install the driver by navigating to the folder containing the driver files, then running the DevCon tool. Open a Command Prompt window as Administrator. Navigate to your folder containing the built driver. If you get an error message about devcon not being recognized, try adding the path to the devcon tool. A dialog box will appear indicating that the test driver is an unsigned driver.
Select Install this driver anyway to proceed. Now that you have installed your KmdfHelloWorld driver on the target computer, you'll attach a debugger remotely from the host computer.
0コメント