Getting Started with Software Tracing in Windows Drivers
WinHEC 2005 Version - April 18, 2005
Abstract
Software tracing is an efficient way to examining the behavior of a running driver without the overhead of debug print statements or a checked build. This paper provides a general introduction to software tracing in kernel-mode drivers for the Microsoft? Windows? family of operating systems using Event Tracing for Windows (ETW) and the Windows software trace preprocessor (WPP). It also describes advances in software tracing for Microsoft Windows Vista?.
This information applies for the following operating systems:
Windows Vista
Microsoft Windows Server? 2003
Microsoft Windows XP
Microsoft Windows 2000
Future versions of this preview information will be provided in the Windows Driver Kit.
The current version of this paper is maintained on the Web at
https://www.doczj.com/doc/188305848.html,/whdc/DevTools/tools/WPP_Intro.mspx.
References and resources discussed here are listed at the end of this paper. Contents
Introduction (3)
Advantages of Software Tracing for Drivers (3)
Software Tracing Concepts (4)
ETW and the WPP (6)
Instrumenting a Driver for Software Tracing Using the WPP (6)
The DoTraceMessage Macro (10)
Defining a Trace Message Function (11)
Converting Existing Debug Print Statements to Trace Messages (11)
Running a Software Tracing Session (12)
Preparing the Tracedrv Sample (12)
Running a Tracing Session with the Tracedrv Sample (12)
Viewing the Trace Log from the Tracedrv Session (13)
Viewing Trace Messages in Real Time (14)
Redirecting Trace Messages to a Kernel Debugger (15)
Redirecting Trace Messages to KD (15)
Redirecting Trace Messages to WinDbg (16)
Software Tracing Advances for Windows Vista (16)
Summary of Tools for Software Tracing (17)
Tracing Tools in the WDK (17)
Tracing Tools Included with Windows (18)
Summary of Tracing Functions and Macros (18)
Tracing Functions and Macros for Kernel-Mode Drivers (18)
Tracing Functions for User-Mode Applications (19)
Resources (19)
Disclaimer
This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
? 2005 Microsoft Corporation. All rights reserved.
Microsoft, Windows, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Introduction
Software tracing is an efficient way of examining the behavior of a running driver, without the overhead of debug print statements or a checked build. Drivers that are instrumented for tracing can generate trace messages for events determined by the driver writer. Areas that can be useful to trace include:
?Configuration settings.
?State changes, to record the cause of the state change and any related information.
?Input and results of public functions.
?Scavenging or cleanup operations.
?Memory allocations.
?I/O activities such as I/O request packet (IRP) completion, IRP cancellation, and so forth.
?Error paths, especially in libraries that other developers will use. Placing a detailed trace statement in every error path can generate useful information for
a library's users with minimal overhead.
Microsoft? Windows? supports software tracing through Event Tracing for Windows (ETW), a kernel-level trace logging facility that logs both kernel and application-defined events. The Windows software trace preprocessor (WPP) simplifies and enhances ETW tracing in drivers. Drivers for Microsoft Windows 2000 and later versions of Windows can take advantage of ETW and WPP to support software tracing.
This paper provides a general introduction to software tracing in Windows kernel-mode drivers. For detailed information about implementing software tracing in drivers and using tracing tools, see the Windows Driver Kit (WDK).
For information about instrumenting a user-mode application for software tracing, see the Platform SDK.
Advantages of Software Tracing for Drivers
Software tracing provides several significant advantages for drivers:
?Available in shipped products. Because tracing does not require the checked build of Windows, product binaries can be shipped with tracing code left in.
Tracing can be enabled and a trace log captured on a single system in the field by using the tracing tools included with Windows. Use of a kernel-mode
debugger is not required.
?Low impact on performance. Drivers generate trace messages only when tracing is enabled—otherwise, a driver's tracing code is never called. When
tracing is enabled, it incurs little overhead because trace messages are issued in binary format and formatted outside the driver by a separate application. This makes tracing especially useful for investigating bugs whose behavior is
affected by system performance (sometimes called "Heisenbugs" because they tend to disappear when something slows down the system, as debug print
function calls tend to do).
?Dynamic and flexible. Tracing can be enabled or disabled dynamically, without stopping or restarting a component and without rebooting the operating system. Tracing can be enabled selectively for individual components, and it can be enabled at different levels defined by the driver writer.
In Microsoft Windows XP and later versions of Windows, trace messages can be redirected to a real-time trace consumer (any program capable of receiving and formatting trace messages) or a kernel debugger, bypassing the trace log. ?Rich trace information without exposing intellectual property. Developers often put function names and other internal information in debug print
statements. Although this is helpful during debugging, it also simplifies reverse engineering, which can expose your company's intellectual property.
With ETW, all of the static portions of a trace message are placed in the driver's private symbol file. The function name, source file name, and line number for each trace message are added during the preprocessing phase of trace
implementation. When the message is logged, the ETW logging mechanism automatically attaches a timestamp to each trace message (plus any other
dynamic information specified by the driver).
The logged trace messages can be read only by a trace consumer (such as the Tracefmt tool provided with the WDK) that has access to either the driver's
program database (PDB) symbol file or to a trace message format (TMF) file generated from the PDB file.
?Easy migration from debug print statements. The WPP can interpret a driver's existing debug print function calls as trace function calls during the build process, so a driver's existing instrumentation can be used and extended
without having to rewrite existing code.
Software Tracing Concepts
Figure 1 shows software tracing components and how they interact.
Figure 1. Software Tracing Architecture
Trace Providers
A trace provider is an application, operating system component, or driver that is instrumented for tracing. Figure 1 shows three trace providers: Provider A, Provider B, and Provider C (bottom of figure). "Instrumented for tracing" means that the trace provider includes code to generate trace messages. A number of
Windows kernel-mode components, drivers, and Microsoft Windows Server? applications are instrumented as trace providers. Developers can instrument their drivers by using the WPP or ETW, as described in this paper.
A trace provider generates trace messages only when it has been enabled by a trace controller, which is an application or tool that manages trace sessions. TraceView and TraceLog are trace controllers provided with the WDK. (You can also write your own trace controller by using the ETW application programming interface documented in the Platform SDK.)
Trace Sessions
A trace session is a period during which one or more trace providers generate trace messages to a single event log. The trace controller starts and configures a trace session, enables one or more providers, and associates the providers with the session. During a session, the trace controller can query and update properties of the trace session and, finally, stop the session.
The system maintains a set of buffers to store trace messages for each trace session. A trace controller can configure the size of the buffers for a session. Buffers are automatically flushed to the trace log or trace consumer once per second, or sooner if the buffers become full. Buffers are also flushed automatically when the trace controller stops the trace session. In addition, a trace controller can explicitly flush the buffers, either on demand or at regular intervals. If the system crashes, the buffers are still available, so trace messages are not lost.
A single trace session can record events from more than one provider. Trace messages from all providers that are associated with a session are interleaved in the session's buffers. Figure 1 shows three trace sessions: Session 1, Session 2, and Session 64. Provider A and Provider
B are associated with Session 2, whereas Provider
C is associated with Session 64. A trace session can exist without having a provider associated with it. For the moment, no trace provider is associated with Session 1.
On Windows XP and later versions of Windows, ETW supports up to 64 trace sessions executing simultaneously. (On Windows 2000, ETW supports up to 32 sessions.) All but two of these sessions are available for general use. The remaining two sessions are the global logger trace session (which records events that occur early in the operating system boot process) and the NT kernel logger trace session (which records predefined system events generated by the operating system, such as disk I/O or page fault events). It is possible to trace both the Windows kernel and a driver and produce a single trace log with events from both components interleaved, thus capturing the actions of Windows while the driver is running.
Trace Controllers
The trace controller transfers trace messages from the trace session buffers either to an event trace log (ETL) file for that session or directly to a trace consumer, which is an application or tool that receives, formats, and displays trace messages.
(A trace consumer can also just format and display trace messages from the trace log, long after the trace session has ended.)
The trace consumer formats trace messages in human-readable format by using instructions either from the provider's PDB symbol file or from a TMF file that is generated when the provider is built (or generated later from the provider's PDB file, by using a tool such as Tracepdb).
ETW and the WPP
The underlying architecture of Windows kernel-mode tracing is based on ETW. Though ETW tracing can be powerful and flexible, it is also complex to implement, especially for drivers that need only lightweight tracing.
To implement ETW tracing, a driver must provide schemas in a managed object format (MOF) file for its trace events, register as a WMI provider, mark events as traceable, specify a control event for overall enabling and disabling of a set of trace events, store a handle to the logger when it receives a request from WMI to enable events, and decide whether a given trace event should be sent to WMI event consumers or to the WMI event logger only. When an event is triggered, the driver must allocate and fill in an EVENT_TRACE_HEADER structure and then (finally) call IoWMIWriteEvent to log the event.
The WPP simplifies and enhances ETW tracing in drivers and requires considerably less effort on the part of the developer. The WPP macros in driver source code and the WPP template files define C/C++ tracing code to create. During the build process, the WPP uses these macros and templates to generate code for the driver to register as a trace provider and to generate trace messages. The code generated for each source code file is stored in a trace message header (TMH) file, which also contains macros that add trace message formatting instructions to the driver's PDB file. The tracing code that the WPP generates essentially implements ETW tracing on behalf of the driver.
Instrumenting a Driver for Software Tracing Using the WPP
To instrument a driver for software tracing using the WPP, you add certain preprocessor directives and the WPP macros to your driver source code. You also add trace message calls to driver source code (or instruct the WPP how to convert existing debug print statements) for the messages you want to generate.
The tracedrv sample in the WDK consists of a simple driver called tracedrv and a test program called tracectl.Tracedrv implements software tracing through the WPP. Tracectl loads and starts tracedrv and sends an I/O control (IOCTL) to the driver to trigger trace messages. When tracedrv receives the IOCTL, it logs 100 trace messages and then stops. Source code for tracedrv and tracectl is in
the %winddk%\src\general\tracedrv directory.
This section describes the basic steps for instrumenting a driver for software tracing using the WPP, illustrated with examples from tracedrv. These steps are:
1. Include the TMH file for each source code file that contains any WPP macros.
2. Define a WPP_CONTROL_GUIDS macro that specifies a globally unique
identifier (GUID) and trace flag names for controlling tracing.
3. Call WPP_INIT_TRACING from the driver's DriverEntry routine.
4. Call WPP_CLEANUP from the driver's Unload routine.
5. Add a RUN_WPP statement to the driver's sources file.
6. Add trace message function calls to driver code.
Step 1. Include the TMH file for each source code file that contains any WPP macros.
For each source file that contains any WPP macros, add an #include directive for the corresponding TMH file. The WPP generates TMH files during the build process.
A TMH file has the same name as the corresponding source file, with a .tmh filename extension. For example, if the source code file is tracedrv.c, the corresponding TMH file would be tracedrv.tmh and the #include directive would look like the following:
#include tracedrv.tmh
Include the trace message header file before any WPP macro calls and after defining a WPP_CONTROL_GUIDS macro.
Step 2. Define a WPP_CONTROL_GUIDS macro that specifies a GUID and trace flag names for controlling tracing.
The WPP_CONTROL_GUIDS macro establishes a control GUID for the trace provider and defines trace flag names. ETW and the WPP both use the control GUID to identify the provider. Trace flags can be enabled by a trace controller (for example, with the -flag option used with the Tracelog tool) to determine which messages the trace provider generates. The provider interprets the flag as a condition for generating the message. (Trace levels defined in evntrace.h can also be used as conditions for generating trace messages, as described in "Step 6. Add trace message calls to driver code" later in this paper.)
Use a tool such as GUIDGEN to generate a GUID to serve as the control GUID. Define trace flags to distinguish between different levels or categories of tracing in your driver. For example, you might define certain trace flags for error paths and other trace flags for performance.
The tracedrv sample includes the following definition of the
WPP_CONTROL_GUIDs macro:
#define WPP_CONTROL_GUIDS \
WPP_DEFINE_CONTROL_GUID(CtlGuid,(d58c126f, b309, 11d1, 969e, 0000f875a5bc), \
WPP_DEFINE_BIT(TRACELEVELONE) \
WPP_DEFINE_BIT(TRACELEVELTWO) )
In this example, CtlGuid is the friendly name for the GUID {d58c126f-b309-11d1-969e-0000f875a5bc} and the trace flag names are TRACELEVELONE and TRACELEVELTWO. The WPP assigns bit values to a provider's trace flags in the order in which they appear in the WPP_CONTROL_GUIDS structure, beginning with 1. When starting a trace session, use the bit value (not the flag name) to represent the flag.
The control GUID and its friendly name are also specified in the driver's control GUID file, a text file that is used by the Tracelog tool. For example, tracedrv.ctl, the control GUID file for the tracedrv sample, contains the following line:
d58c126f-b309-11d1-969e-0000f875a5bc CtlGuid
A driver can specify more than one control GUID. Each control GUID identifies a unique provider. For example, if a driver defines two control GUIDs, one for a shared library and one for the driver, the library and the driver can be enabled as two different providers. Tracing can be enabled for either the library or the driver, or both.
In contrast, all components that use the same control GUID operate as a single provider. For example, if several drivers use the same control GUID, they can be enabled as a single trace provider. These drivers share the ETW structures and resources, so their trace messages are interleaved in the buffers. This can be useful for tracing drivers that interact during execution, such as a kernel-mode port
driver and its related miniport driver. Components can be user-mode or kernel-mode components, such as a kernel-mode driver and its associated user-mode control or application programs. This enables a provider to produce a consistent trace between user mode and kernel mode.
Step 3. Call WPP_INIT_TRACING from the driver’s DriverEntry routine.
The WPP_INIT_TRACING macro activates software tracing in a driver. The driver cannot generate trace messages until after this macro has been called, so it should be called as early as possible.
For Windows XP and later versions of Windows. Call this macro from the
driver's DriverEntry routine, using the following format:
WPP_INIT_TRACING(DriverObject,RegistryPath);
where RegistryPath is a pointer to a Unicode string that specifies the path to the driver's registry key.
For Windows 2000. If the driver must load on Windows 2000 and does not use WMI, call the WPP_SYSTEMCONTROL(DriverObject) macro from the driver's DriverEntry routine, to set up the WPP dispatch routine that handles WMI IRPs. If the driver uses WMI, see ―Resources‖ at the end of this paper for an alternat ive solution.
Then call the WPP_INIT_TRACING macro from the driver's AddDevice routine and use the following format. Notice that the WPP_INIT_TRACING macro takes a device object (not a driver object) as its first argument:
WPP_INIT_TRACING(DeviceObject, RegistryPath)
Step 4. Call WPP_CLEANUP from the driver’s Unload routine.
The WPP_CLEANUP macro deactivates software tracing in a driver. The driver cannot generate trace messages after this macro has been called, so it should be called as late as possible.
Be aware that failing to call this macro does not generate a compiler error, but it does leave an outstanding reference on the driver object, which causes subsequent loads of the driver to fail and requires the user to reboot the system.
For Windows XP and later versions of Windows. Call this macro from the
driver's Unload routine, using the following format:
WPP_CLEANUP(DriverObject)
For Windows 2000. Call this macro just before calling DeleteDevice on the driver's device object, using the following format. Again, notice that the WPP_CLEANUP macro takes a device object (not a driver object) as its argument:
WPP_CLEANUP(DeviceObject)
Step 5. Add a RUN_WPP directive to the driver's sources file.
The WPP is integrated with the WDK build environment. The RUN_WPP directive invokes the WPP before compiling the driver files.
The WPP processes WPP macros and creates a TMH file for each source file. A TMH file is a text file that contains declarations of functions and variables used by
the tracing code that the WPP generates. The TMH file also includes macros that add trace message formatting instructions to a driver's PDB file.
The RUN_WPP directive should be added to the end of the driver's sources file. In its simplest form, the RUN_WPP directive for a kernel-mode driver looks like the following:
RUN_WPP= $(sources) –km
The -km option defines the WPP_KERNEL_MODE macro, which traces kernel-mode components (by default, only user-mode components are traced). This directive is sufficient for drivers that run on Windows XP and later versions of Windows.
For details about -km and other RUN_WPP options, see the WPP documentation in the WDK.
As an alternative to running the WPP when building your driver, you can use the TraceWPP command-line tool to run the WPP on a source file that includes the WPP macros. TraceWPP uses the same parameters as RUN_WPP. This tool is provided with Windows and documented in the Platform SDK.
For Windows 2000. To support providers that run on Windows 2000 as well as later versions of Windows, build your driver with the template km-w2k.tpl (for a kernel-mode provider) or um-w2k.tpl (for a user-mode provider).
These templates support cross-platform compatibility by adding support for functions that might otherwise be found only in later versions of Windows, such as high-resolution timers and sequence numbers. These templates make it unnecessary to build a separate version of the driver for Windows 2000. These templates are provided with the WDK.
To use the templates, add the -gen parameter to the RUN_WPP macro in the provider's sources file, as shown in the following example for a kernel-mode provider:
RUN_WPP=$(SOURCES) -km -gen:{km-w2k.tpl}*.tmh
The -gen parameter directs the WPP to create a trace message header file for the km-w2k.tpl template. The resulting trace message header file is larger than it would be on Windows XP and later versions of Windows, so software tracing on Windows 2000 might have a slightly higher performance overhead.
Step 6. Add trace message calls to driver code.
A trace message function is the code that actually generates a trace message if the function's conditions are met. ETW supports trace flags and trace levels as conditions that determine which events the trace provider generates.
The default WPP trace macro, DoTraceMessage, generates trace messages on the basis of trace flags. The trace provider defines trace flags in its
WPP_CONTROL_GUIDS structure, as described earlier in this paper. If a trace controller enables the trace flag, the provider generates the message.
The trace level typically represents the severity of an event (information, warning, or error), but a trace provider can interpret trace levels to represent any condition for generating the trace message. Trace levels are defined in the public header file evntrace.h.
You can define your own trace message functions that generate messages on the basis of any condition that is supported by your code, including a combination of
trace flags and trace levels. You can also convert existing debug print statements to trace messages when you build your driver.
Important. Be careful not to expose security or privacy data in trace messages. Any trace consumer with access to your driver's TMH file or PDB file can format and read your driver's trace log.
The DoTraceMessage Macro
DoTraceMessage generates a trace message if a specified trace flag is enabled. A trace controller enables one or more flags when it starts a session.
The DoTraceMessage macro has the following format:
DoTraceMessage(Flag, "Message", MessageVariables...);
In this macro:
Flag is the name of a trace flag specified in the driver's definition of the
WPP_CONTROL_GUIDS macro. The flag is a condition for generating the
trace message specified in Message.
Message specifies a string constant that defines the text of the trace message, including format specifications (%d, %s, and the like). The string constant in Message must be compatible with the FormatMessage function.
MessageVariables specifies a comma-separated list of driver-defined variables whose formatted values are added to the message. The format of this list is the same as for printf.
FormatMessage and printf are both documented in the Platform SDK.
When the WPP encounters a DoTraceMessage call, it treats the message information as a unique message and does the following:
?Defines macros in the driver's TMH file that ultimately expand to WmiTraceMessage calls.
?Creates a compiler directive that adds tracing information to the driver's PDB file, including the required control GUID and information to format the provider's trace messages. Trace consumers use this information to identify the trace
provider and format its trace messages.
For example, the tracedrv sample logs two different messages, each controlled by the trace flag TRACELEVELONE. Assuming TRACELEVELONE is enabled, each time tracedrv receives an IOCTL_TRACEKMP_TRACE_EVENT request, it generates the first trace message once and then generates the second message repeatedly, up to the value of MAXEVENTS as defined in tracedrv.c.
case IOCTL_TRACEKMP_TRACE_EVENT:
ioctlCount++;
DoTraceMessage(TRACELEVELONE, "IOCTL = %d", ioctlCount);
while (i++ < MAXEVENTS) {
DoTraceMessage(TRACELEVELONE, "Hello, %d %s", i, "Hi" );
}
}
In addition to the standard format strings defined for printf, the WPP supports predefined format specifications that can be used in trace messages. For example, %!NTSTATUS! represents a status value and displays the string associated with the status code. For a complete list of predefined format specifications, see the WDK.
Defining a Trace Message Function
The general format of a valid trace message function is:
FunctionName(Conditions..., "Message", MessageVariables...) Conditions is a comma-separated list of values that appear before Message. (All parameters that appear before the message are interpreted as conditions.) The trace message is generated only if all conditions are true.
As for DoTraceMessage, Message specifies a string constant that defines the text of the trace message including format specifications, and MessageVariables specifies a comma-separated list of driver-defined variables whose formatted values are added to the message.
For example, in the following trace message function, the conditions are a trace level, a trace flag, and the subcomponent of the provider that is generating the trace message.
MyDoTrace(Level, Flag, Subcomponent, "Message", MessageVariables...)
In code, this function might look like the following:
MyDoTrace(TRACE_LEVEL_ERROR, VERBOSE, Network, "IOCTL = %d", ControlCode);
where:
TRACE_LEVEL_ERROR is a standard trace level defined in evntrace.h.
VERBOSE is a trace flag defined by the provider.
Network is the subcomponent of the provider.
"IOCTL = %d" is the message string.
ControlCode is the variable to substitute for the %d format specifier in the
message string.
To get the WPP to recognize your trace message function, you must:
?Write alternative versions of the macros that support the DoTraceMessage macro (WPP_LEVEL_ENABLED and WPP_LEVEL_LOGGER).
?Add a -func parameter that specifies your trace message function to the RUN_WPP statement that invokes the WPP.
For more information about these tasks, see the software tracing FAQ "Can I Customize DoTraceMessage?" in the WDK.
Converting Existing Debug Print Statements to Trace Messages The RUN_WPP directive has numerous options for controlling the WPP. One commonly used option is -func:FunctionDescription, which specifies an alternative to the DoTraceMessage function. The -func option can be used to "convert" existing debug print statements in a driver to trace messages. For example, suppose a driver already uses the following debug print command:
KdPrintEx((NULL, LEVEL, MSG, ...))
The following RUN_WPP directive would cause existing KDPrintEx calls to be treated as trace messages, in addition to any DoTraceMessage or other trace message function calls added to the driver source code:
RUN_WPP=$(SOURCES) -km -func:KdPrintEx((NULL, LEVEL,
MSG, ...))
You can specify -func more than once in the same RUN_WPP command.
Running a Software Tracing Session
A software tracing session requires a trace provider and a trace controller, as well as a trace consumer to format and display the resulting trace messages.
This section describes how to run a software tracing session by using the tracedrv sample and the tracing tools Tracepdb, Tracelog, and Tracefmt to produce an ETL file that contains the messages generated by tracedrv. The examples use the tracedrv sample and the tracing tools provided in the Windows Server 2003 SP1 DDK.
Note: To use Tracepdb on versions of Windows earlier than Windows Longhorn, it is necessary to copy Dbghelp.dll file from the %WINDDK%\bin\Platform directory of the WDK into the directory in which Tracepdb.exe is located.
Preparing the Tracedrv Sample
Before starting a trace session with the tracedrv example, you must build both the sample driver and its test program, tracectl, then generate a TMF file and specify a path to the file so the Tracefmt tool can find and use this file to format the trace messages.
To prepare the tracedrv sample:
1. Use the WDK build utility to build tracedrv and tracectl from sample source code
in %winddk%\src\general\tracedrv.
2. Use Tracepdb to generate a TMF file, using the following command.
tracepdb -f tracedrv.pdb -p path
The resulting TMF file is stored at path. Its name consists of a GUID with a .tmf filename extension.
3. Specify the path to the TMF file by setting the
TRACE_FORMAT_SEARCH_PATH environment variable:
SET TRACE_FORMAT_SEARCH_PATH=DriverPathName
The sample control GUID file tracedrv.ctl is included as part of the tracedrv sample files. If you write your own trace provider, you must create your own control GUID file. The file name is the name of the provider with a .ctl filename extension. The control GUID file is a text file that contains a single line consisting of the trace provider's GUID and its friendly name. For example, tracedrv.ctl contains the following line:
d58c126f-b309-11d1-969e-0000f875a5bc CtlGuid
Running a Tracing Session with the Tracedrv Sample
Tracelog is a trace controller that runs at the command line. Tracelog can be used to enable, configure, start, update, and stop real-time and log sessions.
To run a tracing session by using Tracelog and the tracedrv sample:
1. Start the software tracing session by using the following Tracelog command:
tracelog ?start tracedrv ?guid tracedrv.ctl
?f tracedrv.etl ?flag 0x1
This command starts a trace session and associates the tracedrv sample with the session. The command also enables the tracedrv sample for tracing so it will generate trace messages.
In this command:
tracedrv is the name of the trace session.
Tracedrv.ctl is the sample's control GUID file, which specifies its control
GUID and a friendly name for the GUID.
Tracedrv.etl is the name of the trace log file that receives trace messages
from the session buffers.
The -flag option is set to 0x1, which corresponds to the trace flag
TRACELEVELONE specified in the tracedrv sample's
WPP_CONTROL_GUIDS macro. Only trace messages with this flag are
generated during this session. (Although tracedrv defines two trace flags, it
implements messages only for TRACELEVELONE, so -flag must have a
value of 1 for tracedrv to generate any trace messages.)
2. Run the sample test program tracectl.exe.
Tracectl.exe loads tracedrv and, each time you type a letter other than q or Q, it sends an IOCTL to tracedrv. The IOCTL is the event that triggers trace
messages. Type q or Q to quit tracectl.
3. Stop the tracing session by using the following Tracelog command with the
name of the session provided in Step 1:
tracelog ?stop tracedrv
This command flushes the session buffers to write any remaining trace
messages to the trace log file, disables tracedrv so it no longer generates trace messages, and ends the trace session.
Viewing the Trace Log from the Tracedrv Session
Tracefmt is a command-line trace consumer that formats trace messages from real-time trace sessions or trace logs and writes them to files or displays them in a command window.
Tracefmt uses formatting instructions from the TMF file created earlier to convert the binary trace messages to readable form. The Tracefmt example shown here assumes that the TRACE_FORMAT_SEARCH_PATH environment variable is set to the path of the TMF file, as described earlier. If this variable is not set, specify a path to the file.
To view the trace log from the Tracedrv session:
1. Format the trace messages by using the following Tracefmt command:
tracefmt ?o tracedrv.txt ?f tracedrv.etl
In this command:
Tracedrv.txt is the name of a text file to receive the formatted trace
messages.
Tracedrv.etl is the name of the log file containing the trace messages in
binary format.
2. View the converted trace messages by using any text editor.
The following example shows the first few lines of a typical tracedrv sample log file, as formatted by Tracefmt:
EventTrace
[0]0D44.0CF8::03/02/2005-15:18:09.711 [tracedrv]IOCTL = 1
[0]0D44.0CF8::03/02/2005-15:18:09.711 [tracedrv]Hello, 1 Hi
[0]0D44.0CF8::03/02/2005-15:18:09.711 [tracedrv]Hello, 2 Hi
[0]0D44.0CF8::03/02/2005-15:18:09.711 [tracedrv]Hello, 3 Hi
[0]0D44.0CF8::03/02/2005-15:18:09.711 [tracedrv]Hello, 4 Hi
Tracefmt adds a default trace message prefix for the message logged by the corresponding DoTraceMessage call. The default trace message prefix specifies the CPU number, process ID, thread ID, timestamp in Greenwich mean time (GMT), and the control GUID friendly name. For information about formatting trace message prefixes, see the documentation for Tracefmt in the WDK.
Viewing Trace Messages in Real Time
Traceview is a trace controller and trace consumer with a graphical user interface. It is designed especially to display trace messages as they are generated. As a trace controller, Traceview can be used to enable, configure, start, update, and stop tracing sessions. As a trace consumer, Traceview can be used to format, filter, and display trace messages from real-time trace sessions and trace logs. TraceView combines and extends the features of Tracepdb, Tracelog, and Tracefmt. For information about using Traceview, see its online help.
To view trace messages in real time:
1. Start Traceview.
2. Create a new log session (on the File menu, click Create New Log Session).
3. Add tracedrv as a provider by selecting either its PDB file or its control GUID file
(or paste its control GUID into the Manually Entered Control GUID box).
4. Specify the tracedrv TMF file, either by selecting the file or setting the TMF
search path.
5. Select the Real Time Display check box and then click Finish.
6. Run the tracectl test program to load tracedrv and generate trace messages.
The trace messages appear in the TraceView window, as shown in Figure 2.
Figure 2. The TraceView window showing TraceDrv sample messages
Redirecting Trace Messages to a Kernel Debugger Several methods can be used to redirect trace messages to a kernel-mode debugger. You can redirect trace messages to kernel debugger (KD) or WinDbg, whichever is attached. (You cannot redirect trace messages to other kernel debuggers, such as NTSD.)
To display trace messages in a debugger, wmitrace.dll and traceprt.dll must be in the debugger's search path on the host computer. Also, to enable the debugger to find the TMF files for the trace messages, you must either set the value of
the %TRACE_FORMAT_SEARCH_PATH% environment variable or use
the !wmitrace.searchpath debugger extension to indicate the location of the TMF files.
The !wmitrace debugger extension displays trace messages in the trace session buffers before they are written to log files or delivered for display. Debugging Tools for Windows contains !wmitrace.
Redirecting Trace Messages to KD
To redirect trace messages to the KD by using Tracelog:
1. Start KD.
You must start the kernel debugger before submitting a Tracelog command with the -kd parameter. If KD is not running, Tracelog stops responding ("hangs"). 2. In a command window, enter the following Tracelog command:
tracelog -start MyTrace -guid MyProvider.ctl -rt -kd
In this command:
-start starts a trace session named MyTrace.
-guid specifies the trace provider's control GUID file. If this file doesn't exist, create it as described earlier in this paper.
-rt specifies that this is a real-time trace session.
-kd redirects the trace messages to the kernel debugger and sets the
maximum buffer size to 3 KB, the maximum for the debugger.
3. Use the !wmitrace debugger extension to view the messages in the debugger. For information about using !wmitrace, see the Debugging Tools for Windows documentation.
Redirecting Trace Messages to WinDbg
To redirect trace messages to WinDbg by using TraceView:
1. Start WinDbg, and then start TraceView.
2. Create a new trace log session, as described earlier in this paper.
3. After specifying the provider, the TMF file, and Real Time Display, click
Advanced Log Session Options.
4. On the Advanced Log Session Options page, click the Log Session
Parameter Options tab, and then change the value of the WinDbg option from FALSE to TRUE and click OK.
5. Click Finish to finish creating the trace log session.
For information about using WinDbg, see the Debugging Tools for Windows documentation.
Software Tracing Advances for Windows Vista
The Microsoft Windows Driver Kit (WDK) and Microsoft Windows Vista? support several new features for the WPP software tracing.
?Dynamic API selection. Released versions of the WPP determine which logging functions to call at compile time, which requires compiling a separate binary for Windows 2000. For Windows Vista, the WPP determines which
logging functions to call at run time, so a single binary can run on Windows
2000 and still take advantage of new and improved tracing functions in later versions of Windows.
Usage for the WPP macros does not change. However, when
DoTraceMessage and similar macros generate trace messages, they call an appropriate function for the operating system on which the provider is running.
Specifically, when a WPP-enabled component runs on Windows 2000,
DoTraceMessage calls TraceEvent in user mode and IoWMIWriteEvent in kernel mode. When the same WPP-enabled component runs on Windows XP or Windows Server 2003, DoTraceMessage calls TraceMessage in user mode and IoWmiTraceMessage in kernel mode. This makes it possible to write a single provider that runs on Windows 2000 and later without requiring the use of special template files.
?New pre- and post-logging macros. Pre- and post-logging macros define the WPP_LEVEL_PRE(level) and WPP_LEVEL_POST(level) macros, which
enable user code to become part of the tracing function’s macro expansion.
Customers can use this for dynamic setup or cleanup around trace points in the field.
?Support for enumerated types. Enumerations can be used to display meaningful names in trace messages, instead of displaying integer values that users must decode. To use an enumeration in trace messages, add
configuration data such as the following example to your source code file.
// begin_wpp config
// CUSTOM_TYPE(FormatName ItemEnum(EnumName) );
// end_wpp
In this example, EnumName is the enumeration and FormatName is the custom type that can be used in the format string of a trace message. To notify the
WPP to look for this configuration data in the source code file, add
a -scan:sourcecodefile parameter to the RUN_WPP macro that invokes the
WPP.
?Tracewpp module name parameter. The new Tracewpp command-line argument p:modulename replaces the default
?New TMF locator feature in Tracefmt. The TMF locator feature enables the Tracefmt tool to locate a provider's PDB file by using the image file that created the trace and the symbol server or symbol path.
?New !wmitrace debugger extension settings. The new
TRACE_FORMAT_PREFIX command can be used to specify the tracing prefix during a debugging session.
The TRACE_FORMAT_SEARCH_PATH command has been enhanced to
allow adding directories to the existing search path during a debugging session.
Previously, TRACE_FORMAT_SEARCH_PATH permitted setting the entire path but not retrieving the path and adding to it.
Summary of Tools for Software Tracing
The WDK includes a set of GUI-based and command-line tools for software tracing. These tools are designed to support ETW and to supplement the tracing tools that are included in Windows.
Tracing Tools in the WDK
The WDK tracing tools are located at %winddk%\tools\tracing\. They include:
?Tracelog, a command-line trace controller that enables, configures, starts, updates, and stops real-time and log sessions. Tracelog supports user-mode and kernel-mode trace sessions, NT kernel logger trace sessions, the global logger (boot) trace session, and tracing to measure time spent in deferred
procedure calls (DPCs) and interrupt service routines (ISRs).
?Tracepdb, a command-line support tool that creates TMF files from PDB symbol files. TMF files are required input to Tracefmt and can be used in
TraceView.
?Tracefmt, a command-line trace consumer that formats trace messages from real-time trace sessions or trace logs and writes them to files or displays them in the Command Prompt window.
?TraceWPP, a command-line tool that runs the WPP on the source files of trace providers. An alternative to running the WPP in the WDK Build utility,
TraceWPP processes trace macros in a source file and creates a header file to
enable the WPP tracing. TraceWPP (tracewpp.exe) is included in the WDK in the \bin\x86 directory. The command-line options for TraceWPP are the same as those for RUN_WPP.
?TraceView, a GUI-based trace controller and trace consumer designed especially for real-time displays of trace messages. It enables, configures,
starts, updates, and stops tracing sessions, and formats, filters, and displays trace messages from real-time trace sessions and trace logs. TraceView
combines and extends the features of Tracepdb, Tracelog, and Tracefmt.
Tracing Tools Included with Windows
Tracing tools included with Windows XP and later versions of Windows include:
?Logman, a fully functional, GUI-based trace controller designed especially to control the logging of performance counters and event traces.
?Tracerpt, a command-line trace consumer that formats trace events and performance counters and writes them to CSV or XML files. Tracerpt also
analyzes the events and generates summary reports.
Note: The Event Viewer is a Control Panel application that displays events recorded in various application, system, and security logs. It is intended primarily for end users to monitor basic system events such as errors loading system services. The Event Viewer cannot be used to display trace logs generated by drivers. Summary of Tracing Functions and Macros
Tracing Functions and Macros for Kernel-Mode Drivers
For information about these tracing functions and macros, see the WDK.
WPP Trace Provider Macros
WPP_CONTROL_GUIDS
WPP_INIT_TRACING
WPP_CLEANUP
DoTraceMessage
WPP Preprocessor Directive
RUN_WPP
WMI Trace Provider Functions
IoWmiRegistrationControl
IoWMIWriteEvent with WNODE_FLAG_TRACED_GUID
WMiTraceMessage (Windows XP and later)
WmiTraceMessageVa (Windows XP and later)
WMI Trace Collection Control Function
WmiQueryTraceInformation
Tracing Functions for User-Mode Applications
For information about these functions, see the Platform SDK documentation. Trace Provider Functions
TraceEvent
TraceEventInstance
RegisterTraceGuids
UnregisterTraceGuids
TraceMessage
TraceMessageVa
Trace Consumer Functions
OpenTrace
CloseTrace
ProcessTrace
SetTraceCallback
RemoveTraceCallBack
Trace Collection Control Functions
StartTrace
StopTrace
QueryTrace
EnableTrace
UpdateTrace
QueryAllTraces
Resources
References
Platform SDK:
Event Tracing
https://www.doczj.com/doc/188305848.html,/library/default.asp?url=/library/en-
us/perfmon/base/event_tracing.asp
WHDC:
Event Tracing
https://www.doczj.com/doc/188305848.html,/whdc/devtools/tools/EventTracing.mspx
OSR Online:
WPP Tracing Part 1 – Supporting Windows 2000 and Beyond
https://www.doczj.com/doc/188305848.html,/article.cfm?id=376
WPP Tracing Part II – Coexisting Peacefully with WMILIB
https://www.doczj.com/doc/188305848.html,/article.cfm?article=377
Kits and Tools
Windows DDK:
https://www.doczj.com/doc/188305848.html,/whdc/DevTools/ddk/default.mspx
Debugging Tools for Windows:
https://www.doczj.com/doc/188305848.html,/whdc/DevTools/Debugging/default.mspx Windows Driver Kit (WDK):
Preview versions of the WDK are available through the Vista Beta program.
https://www.doczj.com/doc/188305848.html,/whdc/driver/ldk/default.mspx
Windows驱动开发和环境搭建 【文章标题】: Windows驱动开发和调试的环境设置 【文章作者】: haikerenwu 【使用工具】: VC6.0,VMware6.0.3,Windbg 【电脑配置】: 惠普笔记本xp sp3 (一)VMWare安装篇 VMWare的安装一路Next即可，关于其序列号，百度一下就能找到，虚拟机安装完成之后，需要安装操作系统，我在虚拟机中安装的是windows xp sp2系统。 点击“文件”----“新建”----“虚拟机” 进入新建虚拟机的向导，配置虚拟系统参数
选择虚拟系统文件的兼容格式（新手推荐选择默认选项） 按照默认设置继续点击下一步，选择好您需要的操作系统，此处我选择的是Windows XP Prefessional。 设置虚拟机名称和虚拟操作系统安装路径，我单独空出来一个F 盘，将虚拟机和虚拟操作系统全部装在该盘。
配置网络模式（推荐选择NA T，一般主机不用做任何的设置虚拟机就可以利用主机上网）。 配置虚拟磁盘的容量。在这里可以直接单击完成，来完成基本操作设置，磁盘默认空间是8GB,用户可以根据自己的实际使用情况来调整大小，也可以自定义分区。
操作完成之后，在“VM”菜单下有个“setting。。。”菜单，点击此菜单，在CD-ROM中选择合适的选项，我使用的是Use ISO image 选项，将我的xp sp2操作系统的ISO映像路径设置好，安装操作系统。点击ok之后，启动虚拟机，即开始安装操作系统，安装过程跟普通装机过程相同。安装完成之后，启动操作系统，然后在VM菜单下点击“Install VMWare Tools”，把虚拟操作系统的驱动装好。 (二)VMWare设置篇
Windows驱动程序手册ELP-108/168/188ES（Rev.1.4）
目录 1.手册信息 (1) 2.操作系统 (1) 3.程序准备 (1) 4.驱动的安装 (2) 5.驱动的设置 (4) 5.1打印首选项 (4) 5.2其他设置 (9) 6.规格 (10) 6.1分辨率 (10) 6.2纸张规格 (10)
1.手册信息 本手册提供了Windows驱动程序安装说明和主要功能方面的信息。 我们致力于提高和升级产品的功能和质量，规格书的内容可能会更改，恕不另行通知。 2.操作系统 本打印机的Windows驱动适用于以下操作系统: ●Microsoft Windows8(32bit/64bit) ●Microsoft Windows7SPI(32bit/64bit) ●Microsoft Windows7SPI(32bit/64bit) ●Microsoft Windows7SPI(32bit/64bit) ●Microsoft Windows Vista SP2(32bit/64bit) ●Microsoft Windows XP Professional SP3(32bit) ●Microsoft Windows Server2012(64bit) ●Microsoft Windows Server2008R2 ●Microsoft Windows Server2008SP2(32bit/64bit) ●Microsoft Windows Server2003R2SP2(32bit/64bit) 3.程序准备 驱动程序包含在随机所附CD。 驱动文件命名为：Tengen ELP Label Driver-v-X.X.X.X.exe 如：Tengen ELP Label Driver-v-1.2.0.0.exe
驱动程序 驱动程序一般指的是设备驱动程序（Device Driver），是一种可以使计算机和设备通信的特殊程序。相当于硬件的接口，操作系统只有通过这个接口，才能控制硬件设备的工作，假如某设备的驱动程序未能正确安装，便不能正常工作。 因此，驱动程序被比作“硬件的灵魂”、“硬件的主宰”、和“硬件和系统之间的桥梁”等。 中文名 驱动程序 外文名 Device Driver 全称 设备驱动程序 性质 可使计算机和设备通信的特殊程序 目录 1定义 2作用 3界定 ?正式版 ?认证版 ?第三方 ?修改版 ?测试版 4驱动程序的开发 ?微软平台 ?Unix平台 5安装顺序 6inf文件 1定义 驱动程序（Device Driver）全称为“设备驱动程序”，是一种可以使计算机和设备通信的特殊程序，可以说相当于硬件的接口，操作系统只能通过这个接口，才能控制硬件设备的工作，假如某设备的驱动程序未能正确安装，便不能正常工作。 惠普显卡驱动安装 正因为这个原因，驱动程序在系统中的所占的地位十分重要，一般当操作系统安装完毕后，首要的便是安装硬件设备的驱动程序。不过，大多数情况下，我们并不需要安装所有硬件设备的驱动程序，例如硬盘、显示器、光驱等就不需要安装驱动程序，而显卡、声卡、扫描仪、摄像头、Modem等就需要安装驱动程序。另外，不同版本的操作系统对硬件设
备的支持也是不同的，一般情况下版本越高所支持的硬件设备也越多，例如笔者使用了Windows XP，装好系统后一个驱动程序也不用安装。 设备驱动程序用来将硬件本身的功能告诉操作系统，完成硬件设备电子信号与操作系统及软件的高级编程语言之间的互相翻译。当操作系统需要使用某个硬件时，比如：让声卡播放音乐，它会先发送相应指令到声卡驱动程序，声卡驱动程序接收到后，马上将其翻译成声卡才能听懂的电子信号命令，从而让声卡播放音乐。 所以简单的说，驱动程序提供了硬件到操作系统的一个接口以及协调二者之间的关系，而因为驱动程序有如此重要的作用，所以人们都称“驱动程序是硬件的灵魂”、“硬件的主宰”，同时驱动程序也被形象的称为“硬件和系统之间的桥梁”。 戴尔电脑驱动盘 驱动程序即添加到操作系统中的一小块代码，其中包含有关硬件设备的信息。有了此信息，计算机就可以与设备进行通信。驱动程序是硬件厂商根据操作系统编写的配置文件，可以说没有驱动程序，计算机中的硬件就无法工作。操作系统不同，硬件的驱动程序也不同，各个硬件厂商为了保证硬件的兼容性及增强硬件的功能会不断地升级驱动程序。如：Nvidia显卡芯片公司平均每个月会升级显卡驱动程序2－3次。驱动程序是硬件的一部分，当你安装新硬件时，驱动程序是一项不可或缺的重要元件。凡是安装一个原本不属于你电脑中的硬件设备时，系统就会要求你安装驱动程序，将新的硬件与电脑系统连接起来。驱动程序扮演沟通的角色，把硬件的功能告诉电脑系统，并且也将系统的指令传达给硬件，让它开始工作。 当你在安装新硬件时总会被要求放入“这种硬件的驱动程序”，很多人这时就开始头痛。不是找不到驱动程序的盘片，就是找不到文件的位置，或是根本不知道什么是驱动程序。比如安装打印机这类的硬件外设，并不是把连接线接上就算完成，如果你这时候开始使用，系统会告诉你，找不到驱动程序。怎么办呢参照说明书也未必就能顺利安装。其实在安装方面还是有一定的惯例与通则可寻的，这些都可以帮你做到无障碍安装。 在Windows系统中，需要安装主板、光驱、显卡、声卡等一套完整的驱动程序。如果你需要外接别的硬件设备，则还要安装相应的驱动程序，如：外接游戏硬件要安装手柄、方向盘、摇杆、跳舞毯等的驱动程序，外接打印机要安装打印机驱动程序，上网或接入局域网要安装网卡、Modem甚至ISDN、ADSL的驱动程序。说了这么多的驱动程序，你是否有一点头痛了。下面就介绍Windows系统中各种的不同硬件设备的驱动程序，希望能让你拨云见日。 在Windows 9x下，驱动程序按照其提供的硬件支持可以分为:声卡驱动程序、显卡驱动程序、鼠标驱动程序、主板驱动程序、网络设备驱动程序、打印机驱动程序、扫描仪驱动程序等等。为什么没有CPU、内存驱动程序呢因为CPU和内存无需驱动程序便可使用，不仅如此，绝大多数键盘、鼠标、硬盘、软驱、显示器和主板上的标准设备都可以用Windows 自带的标准驱动程序来驱动，当然其它特定功能除外。如果你需要在Windows系统中的DOS 模式下使用光驱，那么还需要在DOS模式下安装光驱驱动程序。多数显卡、声卡、网卡等内置扩展卡和打印机、扫描仪、外置Modem等外设都需要安装与设备型号相符的驱动程序，否则无法发挥其部分或全部功能。驱动程序一般可通过三种途径得到，一是购买的硬件附
Windows驱动开发培训 培训流程： 一、基础知识 在开始驱动开发之前，您应该知道操作系统原理以及驱动程序是如何在操作系统中进行工作的，了解这些基本原理将有助于您做出正确的设计决策并简化您的开发过程。 1、了解Windows操作系统构造\\ 可以链接进去 2、安装WDK，参考相关文档，熟悉WDK的内容\\ 可以链接进去 二、Windows驱动开发\\ 可以链接进去 一、基础知识 在开始驱动开发之前，您应该知道操作系统原理以及驱动程序是如何在操作系统中进行工作的，了解这些基本原理将有助于您做出正确的设计决策并简化您的开发过程。 1、了解Windows操作系统构造 （1）培训目标 深入了解Windows操作系统的系统结构以及工作原理 （2）培训内容 阅读书籍《深入解析Windows操作系统》的第3、4、6、7、9章，重点关注第九章“I/O系统” （3）培训任务 ①掌握Windows操作系统的系统结构 ②理解ISR、IRP、IRQL、DCP等概念的含义 ③了解注册表的用法，掌握注册表数据的查看和修改方法 ④了解进程和线程的内部机理以及线程的调度策略 ⑤了解I/O系统的内容，理解I/O请求以及I/O处理过程 注：以上相关内容，请在一周内完成。
2、安装WDK，参考相关文档，熟悉WDK的内容 （1）培训目标 了解WDK的安装过程，熟悉WDK的编译环境，掌握如何使用WDK的相关帮助文档；了解WDM驱动程序的基本结构 （2）培训内容 ①.阅读文档\\10.151.131.12\book\windows\MSWDM.chm,掌握WDM驱动程序的基本结构以及基本的编程技术。 ②.参考WDK的帮助文档：WDK documentation ，了解WDK的基本内容 （3）培训任务 ①理解分层驱动结构的含义，掌握设备和驱动程序的层次结构 ②理解“驱动对象”和“设备对象”的概念 ③理解2个基本例程：DriverEntry 和addDevice ④了解IRP的结构以及IRP处理的流程 ⑤初步了解I/O的控制操作 注：以上相关内容，请在一周内完成。 二、Windows驱动开发 学习如何基于WDK进行驱动程序的开发 1、培训目标 （1）学会根据WDK开发一个基本的Windows驱动程序和测试程序 （2）学会利用不同的IOCTL方式在内核模式和用户模式之间进行通讯 （3）学会如何在内核模式下和用户模式下访问注册表 （4）利用WinDbg跟踪程序，学会使用WinDbg进行调试 2、培训内容 （1）阅读
用VC IDE环境编译驱动程序目前Windows驱动程序分为两类，一类是不支持即插即用功能的NT式驱动程序，另一类是支持即插即用功能的WDM驱动程序。它们在用VC IDE编译驱动程序时有些不一样，下面分开说明： 一、NT驱动( 红色字体标注的地方是容易忽略的)： （1）用VC建立一个新工程。在VC IDE环境下选择“File”“New”，弹出“New”对话框。在该对话框中，选择“Project”选项卡。在“Project”选项卡中，选择Win32 Application，在这个基础上进行修改。工程名为“XXXXXX”，。单击“OK”，进入下一个对框框，在该对话框中，选择一个空的工程。 （2）将驱动程序的两个源文件XXX.h和XXX.cpp拷贝到工程目录中，并添加到工程中（Project->Add To Project->File）。 （3）增加新的编译版本，去掉Debug和Release版本（Build->Configuration中添加一个Check）。 （4）修改工程属性。选择“Project”|“Setting”，在对话框中，选择“General”选项卡。 将Intermediate files和Output files改为XXX_Check。 （5）选择C/C++选项卡，将原有的Project Options内容中全部删除，替换成如下内容，/nologo /Gz /MLd /W3 /WX /Z7 /Od /D WIN32=100 /D _X86_=1 /D WINVER=0x500 /D DBG=1 /Fo”MyDriver_Check/” /Fd”MyDriver_Check/” /FD /c （6）选择Link选项卡，将原有的Project Options内容全部删除，替换成如下内容，ntoskrnl.lib /nologo /base:”0x10000”/stack:0x400000,0x1000 /entry:”DriverEntry” /subsystem:console /incremental:no /pdb:”MyDriver_Check/XXX.pdb”/debug /machine:I386 /nodefaultlib /out:”MyDriver_Check/XXX.sys”/pdbtype:sept /subsystem:native /driver /SECTION:INIT,D /RELEASE /IGNORE:4078 （7）修改VC的lib目录和include目录。在VC中选择“Tools”|“Options”，在弹出的对话框中选择“Directories”选项卡。在“Show directories for”下拉菜单选择“Include files”菜单。添加“D:\WINDDK\2600\INC\W2K”和“D:\WINDDK\2600\INC\DDK\W2K”，并将这两个目录置于最上。大家可以将这个目录“D:\WINDDK\2600”改成你们自己安装的目录。这里应该选择W2K子目录，DDK中还会有相应的XP子目录。但因为XP驱动编译时候需要高版本的VC编译
故障现象 ?安装驱动程序时连接、识别打印机出现问题，提示连接、识别失败。 ?安装驱动程序时搜索不到 USB 设备，安装失败。 注意事项 在安装驱动程序过程中建议您关闭防火墙软件和杀毒软件，这些软件会限制打印机程序调用系统文件，导致打印机在安装/使用过程中出现问题。 必须确认已经删除了原先安装的驱动程序，电脑上曾经安装过 HP LaserJet 激光打印机的驱动程序，重新安装驱动程序之前，需要先删除以前安装的驱动程序，否则可能会出现无法找到设备或者安装不上驱动程序的现象。 解决方法 1.依次点击“开始”→“打印机和传真”。 2.在“打印机和传真”窗口中，依次点击“文件”→“添加打印机”，进 入“添加打印机向导”窗口。如图 1 打印机和传真所示： 图 1: 打印机和传真 3.在“欢迎使用添加打印机向导”窗口中，点击“下一步”按钮。
4.在“本地或网络打印机”窗口中，选择“连接到此计算机的本地打印 机”选项，勾除“自动检测并安装即插即用打印机”选项，然后点击“下一步”按钮。如图 2 本地或网络打印机所示： 图 2: 本地或网络打印机 5.在“选择打印机端口”窗口中，从“使用以下端口”下拉列表中选择 USB 端口，然后点击“下一步”按钮。 o下拉列表中有多个 USB 端口时，选择数字最大的 USB 端口。例如：有“USB001”、“USB002”两个端口，应该选择“USB002”端口。 o下拉列表中没有 USB 端口时，需要先开启打印机电源，然后将打印机 USB 连接线连接到电脑，操作系统会自动创建 USB 端口。 关闭“添加打印机向导”窗口，重新开始添加打印机即可。 如图 3 选择打印机端口所示： 图 3: 选择打印机端口
接触windows驱动开发有一个月了，感觉Windows驱动编程并不像传说中的那么神秘。为了更好地为以后的学习打下基础，记录下来这些学习心得，也为像跟我一样致力于驱动开发却苦于没有门路的菜鸟朋友们抛个砖，引个玉。 我的开发环境：Windows xp 主机+ VMW ARE虚拟机（windows 2003 server系统）。编译环境：WinDDK6001.18002。代码编辑工具：SourceInsight。IDE：VS2005/VC6.0。调试工具：WinDBG，DbgView.exe, SRVINSTW.EXE 上面所有工具均来自互联网。 对于初学者，DbgView.exe和SRVINSTW.EXE是非常简单有用的两个工具，一定要装上。前者用于查看日志信息，后者用于加载驱动。 下面从最简单的helloworld说起吧。Follow me。 驱动程序的入口函数叫做DriverEntry(PDRIVER_OBJECT pDriverObj,PUNICODE_STRING pRegisgryString)。两个参数，一个是驱动对象，代表该驱动程序；另一个跟注册表相关，是驱动程序在注册表中的服务名，暂时不用管它。DriverEntry 类似于C语言中的main函数。它跟main的差别就是，main完全按照顺序调用的方法执行，所有东西都按照程序员预先设定的顺序依次发生；而DriverEntry则有它自己的规则，程序员只需要填写各个子例程，至于何时调用，谁先调，由操作系统决定。我想这主要是因为驱动偏底层，而底层与硬件打交道，硬件很多都是通过中断来与操作系统通信，中断的话就比较随机了。但到了上层应用程序，我们是看不到中断的影子的。说到中断，驱动程序中可以人为添加软中断，__asm int 3或者Int_3();前者是32位操作系统用的，后者是64位用的。64位驱动不允许内嵌汇编。下面是我的一个helloworld的源码：
河北科技大学硕士学位研究生 2014——2015学年第1学期 《操作系统与驱动开发》课程期末考试试卷 学院信息学院专业电路与系统姓名程莉学号 2201414007 题号一二三四五六总分 得分 一．单项选择题（每小题1分，共10分） 1.操作系统的 D 管理部分负责对进程进行调度。 A.主存储器 B.控制器 C.运算器 D.处理机 2.分时操作系统通常采用 B 策略为用户服务。 A.可靠性和灵活性 B.时间片轮转 C.时间片加权分配 D.短作业优先 3.很好地解决了“零头”问题的存储管理方法是 A 。 A 页式存储管理 B 段式存储管理 C 多重分区管理 D 可变式分区管理 4.用WAIT、SIGNAL操作管理临界区时，信号量的初值应定义为 B 。 A.-1 B.0 C.1 D.任意值 5.在进程管理中，当 C 时，进程从阻塞状态变为就绪状态。 A.进程被进程调度程序选中 B.等待某一事件 C.等待的事件发生 D.时间片用完 6.某系统中有3个并发进程，都需要同类资源4个，试问该系统不会发生死锁的最少资源数 B 。 A.9 B.10 C.11 D.12 7.虚拟存储器管理系统的基础是程序的 B 理论。 A.全局性 B.局部性 C. 动态性 D.虚拟性 8.从用户的角度看，引入文件系统的主要目的是 D A.实现虚拟存储 B.保存系统文档
C.保存用户和系统文档 D.实现对文件的按名存取 9.操作系统中采用多道程序设计技术提高CPU和外部设备的 A A.利用率 B.可靠性 C.稳定性 D.兼容性 10.缓冲技术中缓冲池在 C 中。 A．主存 B. 外存 C. ROM D. 时间片轮转 二．填空（每空0.5分，共15分）。 11.进程存在的唯一标志是PCB 。 12.通常进程实体是由程序块、进程控制块和数据块三部分组成。 13.磁盘访问时间由寻道时间、旋转延迟时间和传输时间组成。 14.作业调度是从后备作业队列中选一些作业，为它们分配资源，并为它们创建进程。 15.文件的物理组织有顺序、链接和索引。 16.若一个进程已经进入临界区，则其它欲要进入临界区的进程必须___等待____。 17.信号量的物理意义是，当信号量值大于零时其值表示可分配资源的个数；当信号 量值小于零时,其绝对值表示等待使用该资源的进程的个数。 18.静态重定位在程序装入时进行； 而动态重定位在程序运行时进行。 19.分区管理中采用“最佳适应”分配算法时，宜把空闲区按长度递增次序登记在空闲 区表中。 20.所谓系统调用，就是用户在程序中调用操作系统所提供的一些子功能。 21.把逻辑地址映射为物理地址的工作称为地址映射。 22.设备管理中采用的数据结构有设备控制表、控制器控制表、通道控制表、 系统设备表等四种。 23.从资源管理（分配）的角度，I/O设备可分为独占设备、共享设备和虚 拟设备三种。 24.设备与控制器之间的接口信号主要包括数据、状态和控制。 25.DMA控制器由三部分组成，分别为主机与DMA控制器的接口、 DMA控制器与块设备的接 口和 I/O控制逻辑。 三．名词解释（每小题2.5分，共10分）。 26.虚拟存储器 答：虚拟存储器是指在具有层次结构存储器的计算机系统中，自动实现部分装入和部分替换功能，能从逻辑上为用户提供一个比物理贮存容量大得多，可寻址的“主存储器”。
Windows驱动程序开发笔记 一、WDK与DDK环境 最新版的WDK 微软已经不提供下载了这里：https://https://www.doczj.com/doc/188305848.html,/ 可以下并且这里有好多好东东！ 不要走进一个误区：下最新版的就好，虽然最新版是Windows Driver Kit (WDK) 7_0_0，支持windows7,vista 2003 xp等但是它的意思是指在windows7操作系统下安装能编写针对windows xp vista的驱动程序， 但是不能在xp 2003环境下安装Windows Driver Kit (WDK) 7_0_0这个高版本，否则你在build的时候会有好多好多的问题. 上文build指：首先安装好WDK/DDK，然后进入"开始"->"所有程序"->"Windows Driver Kits"->"WDK XXXX.XXXX.X" ->"Windows XP"->"x86 Checked Build Environment"在弹出来的命令行窗口中输入"Build"，让它自动生成所需要的库 如果你是要给xp下的开发环境还是老老实实的找针对xp的老版DDK吧，并且xp无WDK 版只有DDK版build自己的demo 有个常见问题： 'jvc' 不是内部或外部命令,也不是可运行的程序。 解决办法：去掉build路径中的空格。 二、下载 WDK 开发包的步骤 1、访问Microsoft Connect Web site站点 2、使用微软 Passport 账户登录站点 3、登录进入之后，点击站点目录链接 4、在左侧的类别列表中选择开发人员工具，在右侧打开的类别：开发人员工具目录中找到Windows Driver Kit (WDK) and Windows Driver Framework (WDF)并添加到您的控制面板中 5、添加该项完毕后，选择您的控制面板，就可以看到新添加进来的项了。 6、点击Windows Driver Kit (WDK) and Windows Driver Framework (WDF)，看到下面有下载链接，OK，下载开始。下载后的文件名为： 6.1.6001.18002.081017-1400_wdksp-WDK18002SP_EN_DVD.iso将近600M大小。
WDM驱动程序开发之读写设备寄存器：KIoRange类 2009-11-09 14:05 WDM驱动程序开发之读写设备寄存器：KIoRange类收藏 KIoRange类： 一、Overview KIoRange类将一系列特殊的外围总线的地址映射到CPU总线的地址空间。CPU总线上的地址即可能在CPU的I/O空间，也可能在CPU的内存空间，这取决于平台和外围总线的控制方式。考虑到可移植性，所有对I/O周期(I/O cycle)进行译码的设备驱动程序必须用这个类对I/O的位置(location)进行正确的访问(access)。KIoRange是KPeripheralAddress类的派生类。 一旦映射关系建立起来，驱动程序就用KIoRange类的成员函数去控制设备的I/O寄存器。这个类提供了8位、16位和32位I/O访问控制的函数。这些函数是以内联(in-line)函数方式来使用的，它们调用系统内相应的宏来产生依赖于平台的代码。 对I/O位置(location)进行访问的另一种备选方案是创建一个KIoRegister 的实例。这要通过取得一个KIoRange对象的数组元素来实现。 为了访问一系列外围总线内存空间的地址，需要用KMemoryRange类。 二、Member Functions 1、KIoRange － Constructor (4 forms) 构造函数 【函数原型】 FORM 1: KIoRange( void ); FORM 2: (NTDDK Only) KIoRange( INTERFACE_TYPE IntfType, ULONG BusNumber , ULONGLONG BaseBusAddress, ULONG Count, BOOLEAN MapToSystemVirtual =TRUE ); FORM 3 (WDM): KIoRange( ULONGLONG CpuPhysicalAddress, BOOLEAN InCpuIoSpace, ULONG Count, BOOLEAN MapToSystemVirtual =TRUE
Windows 内核技术与驱动开发笔记 1.简述Driver Entry例程 动程序的某些全局初始化操作只能在第一次被装入时执行一次，而Driver Entry例程就是这个目的。 * Driver Entry是内核模式驱动程序主入口点常用的名字。 * Driver Entry的第一个参数是一个指针，指向一个刚被初始化的驱动程序对象，该对象就代表你的驱动程序。WDM驱动程序的Driver Entry例程应完成对这个对象的初始化并返回。非WDM驱动程序需要做大量额外的工作，它们必须探测自己的硬件，为硬件创建设备对象（用于代表硬件），配置并初始化硬件使其正常工作。 * Driver Entry的第二个参数是设备服务键的键名。这个串不是长期存在的（函数返回后可能消失）。如果以后想使用该串就必须先把它复制到安全的地方。 * 对于WDM驱动程序的Driver Entry例程，其主要工作是把各种函数指针填入驱动程序对象，这些指针为操作系统指明了驱动程序容器中各种例程的位置。 2.简述使用VC进行内核程序编译的步骤 编译方式是使用VC++进行编译 1.用VC新建工程。 2.将两个源文件Driver.h和Driver.cpp拷贝到工程目录中，并添加到工程中。 3.增加新的编译版本。 4.修改工程属性，选择“project | setting”将IterMediate file和Output file 都改为MyDriver_Check。 5.选择C/C++选项卡，将原有的Project Options内容全部删除替换成相关参数。 6.选择Link选项卡，将原有的Project Options内容删除替换成相关Link。 7.修改VC的lib目录和include的目录。 8.在VC中选择tools | options，在弹出的对话框中选择“Directories”选项卡，在“Show directories for”下拉菜单中选择“Include file”菜单。添加DDK的相关路径。 3.简述单机内核调试技术 答:1.下载和安装WinDbg能够调试windows内核模块的调试工具不多，其中一个选择是微软提供的WinDbg 下载WinDbg后直接双击安装包执行安装。 2.安装好虚拟机以后必须把这个虚拟机上的windows设置为调试执行。在被调试系统2000、2003或是xp的情况下打开虚拟机中的windows系统盘。 3.将boot.ini文件最后一行复制一下，并加上新的参数使之以调试的方法启动。重启系统，在启动时就可以看到菜单，可以进入正常windows xp，也可以进入Debug模式的windows xp。 4.设置VMware管道虚拟串口。调试机与被调试机用串口相连，但是有被调试机是虚拟机的情况下，就不可能用真正的串口连接了，但是可以在虚拟机上生成一个用管道虚拟机的串口，从而可以继续内核调试。 4.请画出Windows架构简图
前言 鉴于国内开发人员迫切需要学习驱动开发技术,而国内有关驱动开发工具DriverStudio的资料很少,大家在开发过程中遇到很多问题却没处问,没法问.而这些问题却是常见的,甚至是很基础的问题。 有感于此，本站联合北京朗维计算机应用公司编写了本教程。本教程的目的是让一个有一些核心态程序编写经验或对系统有所了解的人学习编写驱动程序。当然，本教程不是DDK中有关驱动方面内容的替换，而只是一个开发环境的介绍和指导。 学习本教程，你应该能熟练地使用本套工具编写基本的驱动程序。当然如果你想能顺利地编写各种各样的驱动的话，你应该有相关的硬件知道和系统核心知识并且要经过必要的训练才能胜任。 如果真心说一句话，DriverStudio并没有对驱动程序开发有什么实质的改变，它和DDk的关系不过是sdk和mfc的关系，但很多人选择了MFC,原因不言自明，方便二字何以说得完呀？你再也不用去关注繁琐的框架实现代码，也不用去考虑让人可怕的实现细节。封装完整的C++函数库让你专注于你要实现的程序逻辑。它包含一套完整调试和性能测试、增强工具，使你的代码更稳定。 说些题外话,作驱动开发很苦，不是一般的人能忍受的，那怕开发一个小小的驱动也要忍受无数次的宕机，有时甚至有些灾难性的事故等着你，所以要有充分的思想准备。当然，在开发的过程中你会有一种彻底控制计算机的满足感，调试开发完毕后的成就感是其它开发工作所不能体会到的。当然，就个人前途来说,作驱动开发能拿到别的开发所不能得到的薪水。而且开发的生命期也会长一些，你不用不断的学习新的开发工具，只需要不断的加深对系统的理解就行了。当然，还有一点是必需的，那就是英文要好，否则永远比国外同行慢半拍。 本人水平不高，所做的工作只要能提起大家学习驱动开发的兴趣，能带领大家入门便心满意足了。在此感谢北京朗维公司(DriverStduio 国内总代理)的大力赞助，特别是感谢技术部的王江涛，市场部的李强两位先生的大力支持。同时要感谢我的女友，可爱的小猫（我对她的呢称）的贴心照顾和支持(一些很好看的图片就出自她手：）)。在此我也要感谢论坛各大版主的鼎力支持和广大网友的关怀。 DriverStudio工具包介绍： DriverStudio 是一套用来简化微软Windows 平台下设备驱动程序的开发，调试和测试的工具包。DriverStudio 当前的版本包括下列工具模块： DriverAgent DriverAgent 为Win32 应用程序提供直接访问硬件的功能。即使你没有任何设备驱动程序开发的经验或经历，你也能编写出DriverAgent应用程序来直接访问硬件设备。DriverAgent 应用程序可以运行在 Windows 98, Windows 95, Windows NT 和 Windows 2000平台上。(当前版本不支持Windows XP平台。) VToolsD VToolsD 是一个用来开发针对Win9X (Windows 95 和 Windows 98)操作系统下设备驱动程序(VxD)
标题: 【原创】Windows驱动程序框架 windows驱动程序入门比较坑爹一点，本文旨在降低入门的门槛。注：下面的主要以NT式驱动为例，部分涉及到WDM驱动的差别会有特别说明。 首先，肯定是配置好对应的开发环境啦，不懂的就百度下吧，这里不再次描述了。 在Console控制台下，我们的有一个入口函数main；在Windows图形界面平台下，有另外一个入口函数Winmain。我们只要在这入口函数里面调用其他相关的函数，程序就会按照我们的意愿跑起来了。在我们用IDE开发的时候，也许你不会发现这些细微之处是如何配置出来的，一般来说我们也不用理会，因为在新建工程的时候，IDE已经帮我们把编译器（Compiler）以及连接器（Linker）的相关参数设置好，在正式编程的时候，我们只要按照规定的框架编程就行了。 同样，在驱动程序也有一个入口函数DriverEntry，这并不是一定的，但这是微软默认的、推荐使用的。在我们配置开发环境的时候我们有机会指定入口函数，这是链接器的参数/entry:"DriverEntry"。 入口函数的声明 代码: DriverEntry主要是对驱动程序进行初始化工作，它由系统进程（System）创建，系统启动的时候System系统进程就被创建了。 驱动加载的时候，系统进程将会创建新的线程，然后调用执行体组件中的对象管理器，创建一个驱动对象（DRIVER_OBJECT）。另外，系统进程还得调用执行体组件中的配置管理程序，查询此驱动程序在注册表中对应项。系统进程在调用驱动程序的Driv erEntry的时候就会将这两个值传到pDriverObject和pRegistryPath。 接下来，我们介绍下上面出现的几个数据结构： typedef LONG NTSTATUS 在驱动开发中，我们应习惯于用NTSTATUS返回信息，NTSTATUS各个位有不同的含义，我们可以也应该用宏NT_SUCCESS来判断是否返回成功。 代码: NTSTAUS的编码意义： 其中 Ser是Serviity的缩写，代表严重程度。 00：成功01：信息10：警告11：错误 C是Customer的缩写，代表自定义的位。
[置顶]Windows7+WDK+VS2010+VisualDDK驱动开发环境搭建（菜鸟的经验） 分类：驱动开发2011-08-12 23:30 863人阅读评论(3) 收藏举报 自己在研究驱动开发，第一步就是开发环境的搭建，网上已有很多的教程一，我也是按着教程一步一步搭建的，但在搭建过程的过程当中遇到一些问题，也花了我不少时间。 第一个难题就是，我是Windows7+VS2010+WDK的开发环境。 首先我参考了网上的一篇文章：https://www.doczj.com/doc/188305848.html,/guojingjia2006/archive/2011/03/19/142211.html WINDOWS 7 配置驱动开发环境（wdk7.60） 1. 安装VS2010,WDK7.60 （GRMWDK_EN_7600_1） 2. 新建VC 控制台项目(选择为空项目)
3. 新建项目配置“driver” ，点击下拉按钮-点击（配置管理器） 输入名称（driver）点击确定就可以了，其他的不要动哦！
完成后的效果！ 点击确定按钮之后呈现出来的画面
鼠标右击新建的driver属性，会弹出以下窗口！ 4. 设置VC++路径 <我把wdk安装在E盘下> a. 配置可执行文件目 录:E:\WinDDK\7600.16385.1\bin\x86;
b. 配置包含目录： E:\WinDDK\7600.16385.1\inc\ddk E:\WinDDK\7600.16385.1\inc\ E:\WinDDK\7600.16385.1\inc\api c. 配置库目 录: E:\WinDDK\7600.16385.1\lib\win7\i3865 新建C/C++文件不然无C/C++设置选项 <刚开始我们创建了一个空的项目所以项目里没有 c++文件，现在要做的就是在空的项目-源文件-添加一个新建项c++文件> 常规 目标文件扩展名：.sys //必选 6. 设置C/C++选项 常规选项卡 1 调试信息格式(C7 兼容(/Z7) //可选 2 警告等级（2 级(/W2) //可选 3 将警告视为错误(是(/wx) //可选
Windows驱动开发技术详解第六章的(Windows内核函数)自我理解 学习各种高级外挂制作技术，马上去百度搜索（魔鬼作坊），点击第一个站进入，快速成为做挂达人。 其实这章主要就是讲函数DDK有自己的函数跟SDK一样编写DDK使用DDK提供的函数就OK了 /////////////////////////////////////////////////////////////////////////////// ASCII字符串和宽字符串 ASCII字符构造 char*str1="abc"; 打印ASCII字符串 char*string="hello"; KdPrint("%s\n",string);\\注意是小写%s ///// UNICODE字符构造 wchar_t*str2=L"abc"; 打印宽字符串 WCHAR*string=L"hello"; KdPrint("%S\n",string);\\注意是大写%S /////////////////////////////////////////////////////////////////////////////// ANSI_STRING字符串和UNICODE_STRING字符串 ASCII字符串进行了封装 typedef struct_STRING{ USHORT Length;//字符的长度。 USHORT MaximumLength;//整个字符串缓冲区的最大长度。 PCHAR Buffer;//缓冲区的指针。 }STRING; 输出字符串 ANSI_STRING ansiString; KdPrint("%Z\n",&ansiString);//注意是%Z UNICODE_STRING宽字符串封装 typedef struct_UNICODE_STRING{ USHORT Length;//字符的长度，单位是字节。如果是N个字符，那么Length等于N的2倍。USHORT MaximumLength;//整个字符串缓冲区的最大长度，单位也是字节。 PWSTR Buffer;//缓冲区的指针。 }UNICODE_STRING*PUNICODE_STRING; 输出字符串 UNICODE_STRING ansiString; KdPrint("%wZ\n",&ansiString);//注意是%wZ ///////////////////////////////////////////////////////////////////////////////
安装win7驱动程序的3种主要方法 1 通过网络自动安装驱动程序 在Windows 7系统中，安装设备驱动程序往往都需要获得管理员权限。当发现新的设备后，首先Windows 7会尝试自动读取硬件设备固件内部的硬件信息，然后 与%SystemRoot%＼System32、Driver Store\File Repository文件夹系统自带的驱动程序安装信息文件夹包含的ID进行比对，如果能够找到相关符合的硬件∞，并且带有数字签名的驱动程序，那么会在不需要用户干涉的前提下自动安装正确的驱动程序，如图15-3所示为提示正在安装设备驱动程序。安装后自动对系统进行必要的设置，同时会在系统任务栏上，使用气球图标显示相关的提示信息。 图15-3 自动安装设备驱动程序如果经过对比后，Windows 7没有在自带的驱动程序安装信息文件夹中找到所对应的硬件信息，则会自动弹出“发现新硬件”对话框，接着根据对话框的提示进行安装硬件驱动程序即可具体安装方法如下。蕊当电脑检测到新硬件时，会自动到网上Windows Update站点搜索所需的驱动程序。如果找到对应的驱动程序，会自动下载并安装，如图15-4所示。 鬈囊如果系统在网上没有找到硬件所需的驱动程序，此时会允许用户手工安装驱动程序，如果有驱动 程序光盘，将相关光盘放入光驱，然后按照提示进行操作即可完成安装。如果没有光盘，按照如 图15-5所示的方法进行操作。
2 手动安装驱动程序 如果有些硬件设备的驱动程序为．inf格式，则需要用手动安装驱动的方式来安装。手动安装驱动程序的方法如下。 从“设备管理器”窗口中查找没有安装驱动的设备，一般没有安装驱动程序的设备前面标着一个 黄色的问号或显示一个感叹号。一般常见的未知声卡设备名为： PCI Multimedia Audio Device或“未 知多媒体设备”；未知网卡为：PCI Network Adpater Device;未知USB设备为：“未知USB设备”， 如图15-6所示。
<学习笔记>Windows驱动开发技术详解 派遣函数是Windows驱动程序中的重要概念。驱动程序的主要功能是负责处理I/O请求，其中大部分I/O请求是在派遣函数中处理的。 用户模式下所有对驱动程序的I/O请求，全部由操作系统转换为一个叫做IRP数据结构，不同的IRP会被“派遣”到不同的派遣函数中。IRP与派遣函数 IRP的处理机制类似于Windows应用程序中的“消息处理”，驱动程序接收到不同的IRP后，会进入不同的派遣函数，在派遣函数中IRP得到处理。1.IRP 在Windows内核中，有一种数据结构叫做IRP（I/O Request Package），即输入输出请求包。上层应用程序与底层驱动程序通信时，应用程序会发出I/O请求。操作系统将I/O请求转化为相应的IRP数据，不同类型的IRP会被传递到不同的派遣函数中。 IRP有两个基本的重要属性，一个是MajorFunction，另一个MinorFunction，分别记录IRP的主类型和子类型，操作系统根据MajorFunction将IRP“派遣”到不同的派遣函数中，在派遣函数中还可以继续判断这个IRP属于哪种MinorFunction。 下面是HelloDDK的DriverEntry中关于派遣函数的注册：
view plaincopy to clipboardprint? #pragma INITCODE extern "C" NTSTATUS DriverEntry( IN PDRIVER_OBJECT pDriverObject, IN PUNICODE_STRING pRegisterPath ) { NTSTATUS status; KdPrint(("Enter DriverEntry\n")); //设置卸载函数 pDriverObject->DriverUnload = HelloDDKUnload; //设置派遣函数 pDriverObject->MajorFunction[IRP_MJ_CREATE] = HelloDDKDispatchRoutine; pDriverObject->MajorFunction[IRP_MJ_CLOSE] = HelloDDKDispatchRoutine;