The following instructions show you how to install and test the sample driver. Here's the general syntax for the devcon tool that you will use to install the driver:. The INF file required for installing this driver is echo. The inf file contains the hardware ID for installing the echo. Navigate to your driver package folder, and enter the following command:. Select Install this driver anyway to proceed. If you have any issues with the installation, check the following file for more information.
On the target computer, in a Command Prompt window, enter devmgmt open Device Manager. In Device Manager, on the View menu, choose Devices by type. Type echoapp to start the test echo app to confirm that the driver is functional. In Section 5, you will set the symbol path and use kernel debugger commands to display information about the KMDF echo sample driver.
If you closed the debugger, open it again using the following command in the administrator command prompt window. To set the symbols path to the Microsoft symbol server in the WinDbg environment, use the. To add your local symbol location to use your local symbols, add the path using. Note The. In some cases, this command also reloads or unloads the module itself.
Note You must load the proper symbols to use advanced functionality that WinDbg provides. If you do not have symbols properly configured, you will receive messages indicating that symbols are not available when you attempt to use functionality that is dependent on symbols.
There are a number of approaches that can be used to work with symbols. In many situations, you can configure the PC to access symbols from a symbol server that Microsoft provides when they are needed. This walkthrough assumes that this approach will be used. If the symbols in your environment are in a different location, modify the steps to use that location.
For additional information, see Symbol path for Windows debugger. To perform source debugging, you must build a checked debug version of your binaries. The compiler will create symbol files. These symbol files will show the debugger how the binary instructions correspond to the source lines. The actual source files themselves must also be accessible to the debugger.
The symbol files do not contain the text of the source code. For debugging, it is best if the linker does not optimize your code. Source debugging and access to local variables are more difficult, and sometimes nearly impossible, if the code has been optimized. If you are having problems viewing local variables or source lines, set the following build options:. Type the following in the command area of the debugger to display information about the echo driver :.
For information, see lm. For information, see x Examine Symbols. Your output should be similar to the text shown below. Type the following to change the default debug bit mask so that all debug messages from the target system will be displayed in the debugger.
Set the mask to 0x if you would like to reduce the amount of information that is displayed. In Section 6, you will display information about the echo sample device driver and where it lives in the Plug and Play device tree.
Information about the device driver in the Plug and Play device tree can be useful for troubleshooting. For example, if a device driver is not resident in the device tree, there may an issue with the installation of the device driver.
For more information about the device node debug extension, see! To see all the device nodes in the Plug and Play device tree, enter the! The echo device driver should be loaded. Use the! The output displayed in the previous command includes the PDO associated with the running instance of our driver, in this example it is 0xffffeb71a Enter the!
Use the PDO address that! The output displayed in the! The output shows that we have a fairly simple device driver stack. The echo driver is a child of the PnPManager node. The PnPManager is a root node. Note For more information about more complex driver stacks, see Driver stacks and Device nodes and device stacks.
To be able to step through code and check the values of variables in real time, we need to enable breakpoints and set a path to the source code. Breakpoints are used to stop code execution at a particular line of code. You can then step forward in the code from that point, to debug that specific section of code. Sets a breakpoint that is unresolved when the module is unloaded and re-enables when the module reloads.
UsbView displays these number. In the following example, the bus number is 48, the device number is 0, and the function number is 0. After you have identified an xHCI controller that supports debugging, the next step is to locate the physical USB connector that is associated with a port on the xHCI controller.
To find the physical connector, plug any USB 3. Refresh UsbView to see where your device is located. Before using bcdedit to change boot information you may need to temporarily suspend Windows security features such as BitLocker and Secure Boot on the test PC.
Note that TargetName does not have to be the official name of the target computer; it can be any string that you create as long as it meets these restrictions:. Under Location on the General tab, the bus, device, and function numbers are displayed. Enter this command:. The bus, device, and function numbers must be in decimal format.
In some cases, power transitions can interfere with debugging over USB 3. To avoid these problems, disable selective suspend for the xHCI host controller and its root hub that you are using for debugging. Right click the node, and choose Properties. Under Execution , select Enabled. Under Continue , select Not Handled. Click the Argument button, and then in the text box enter the filename of the co-installer, excluding the file extension for example, enter "mycoinst" for mycoinst.
Click OK and then click Close. Resume execution by pressing F5 or entering the g Go command in the Debugger Command window. When the co-installer is loaded, execution will break back into the debugger. At this point, you can set any additional breakpoints that you need. In certain cases, running a device installation package under DevCon may result in slightly different behavior than that of a PnP installation, because of different security tokens and the like.
If you are trying to debug a specific problem in your co-installer, it is possible that this problem will not replicate if DevCon is involved. Therefore, before using this technique, you should use DevCon to install your driver without a debugger attached to verify that this problem exists in both the PnP and the DevCon scenarios.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services. Privacy policy. The Windows Debugger WinDbg can be used to debug kernel-mode and user-mode code, analyze crash dumps, and examine the CPU registers while the code executes. WinDbg Preview is a new version of WinDbg with more modern visuals, faster windows, and a full-fledged scripting experience.
0コメント