Update README.md for samples portal (#358)
* Update README.md for samples portal * Update README.md for samples portal * Removed installwdf * Update fork (#2) * Fix typo ture -> true * Remove InstallWdf sample * Fix typo (#340) ture -> true * Readme typo fix (#349) * Update langid
This commit is contained in:
Barry Golden
Adonais Romero González
Родитель
35bff356ac
Коммит
ef7ec4ec9f
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: TrEE sample
|
||||
description: The Trusted Execution Environment (TrEE) sample.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: TrEE sample
|
||||
platform: KMDF
|
||||
|
|
@ -8,3 +18,5 @@
|
|||
--->
|
||||
|
||||
# TrEE sample
|
||||
|
||||
The Trusted Execution Environment (TrEE) sample.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: TrEE sample
|
||||
description: TrEE sample
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /TrEE/TrEESample.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: SysVAD Virtual Audio Device Driver Sample
|
||||
description: The Microsoft SysVAD Virtual Audio Device Driver (SYSVAD) shows how to develop a WDM audio driver that exposes support for multiple audio devices.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: SysVAD Virtual Audio Device Driver Sample
|
||||
platform: WDM
|
||||
|
|
@ -7,8 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620183
|
||||
--->
|
||||
|
||||
SysVAD Virtual Audio Device Driver Sample
|
||||
========================================
|
||||
# SysVAD Virtual Audio Device Driver Sample
|
||||
|
||||
The Microsoft SysVAD Virtual Audio Device Driver (SYSVAD) shows how to develop a WDM audio driver that exposes support for multiple audio devices.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: SysVAD Virtual Audio Device Driver Sample
|
||||
description: The Microsoft SysVAD Virtual Audio Device Driver (SYSVAD) shows how to develop a WDM audio driver that exposes support for multiple audio devices.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /audio/sysvad/sysvad.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: AvsCamera - AVStream Camera Sample Driver
|
||||
description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: AvsCamera - AVStream Camera Sample Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,8 +17,8 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620184
|
||||
--->
|
||||
|
||||
AvsCamera: AVStream Camera Sample Driver
|
||||
========================================
|
||||
# AvsCamera: AVStream Camera Sample Driver
|
||||
|
||||
The AvsCamera sample provides a pin-centric AVStream capture driver for a simulated front and back camera. The driver performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. The purpose of the sample is to demonstrate how to write a fully functional AVStream camera driver.
|
||||
|
||||
This sample features strong parameter validation and overflow detection. It provides validation and simulation logic for all advanced camera controls in the CCaptureFilter class. A real camera driver would replace the filter automation table and CSensor and CSynthesizer class hierarchies to produce a new camera driver.
|
||||
|
|
@ -16,7 +26,9 @@ This sample features strong parameter validation and overflow detection. It pro
|
|||
The sample comes with its own MFT0 called AvsCameraMft0.dll. This MFT0 is used to parse metadata supplied in the AvsCamera driver samples. The metadata communications from the driver is primarily a private channel to its MFT0. The MFT0 is responsible for reformatting that information for the capture pipeline.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. The sample works on 32-bit and 64-bit x86, amd64 and arm platforms. Once installed, the simulated camera should show in the Windows Inbox camera app.
|
||||
|
||||
## Building the sample
|
||||
The AvsCamera sample can be built by opening the AvsCamera.sln solution file. A successful build produces AvsCamera.sys, AvsCameraMft0.dll, AvsCamera.inf and AvsCamera.cat.
|
||||
|
||||
The AvsCamera sample can be built by opening the AvsCamera.sln solution file. A successful build produces AvsCamera.sys, AvsCameraMft0.dll, AvsCamera.inf and AvsCamera.cat.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: AvsCamera - AVStream Camera Sample Driver
|
||||
description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /avstream/avscamera/avscamera.sln
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
topic: sample
|
||||
name: AvsCamera - AVStream Camera Sample Driver
|
||||
description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: AvsCamera - AVStream Camera Sample Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: Camera AVStream
|
||||
description: Provides a pin-centric AVStream capture driver for a simulated front and back camera that performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620184
|
||||
--->
|
||||
|
||||
# AvsCamera: AVStream Camera Sample Driver
|
||||
|
||||
The AvsCamera sample provides a pin-centric AVStream capture driver for a simulated front and back camera. The driver performs simulated captures at 320x240 or 640x480 in RGB24, RGB32, YUY2 and NV12 formats at various frame rates. The purpose of the sample is to demonstrate how to write a fully functional AVStream camera driver.
|
||||
|
||||
This sample features strong parameter validation and overflow detection. It provides validation and simulation logic for all advanced camera controls in the CCaptureFilter class. A real camera driver would replace the filter automation table and CSensor and CSynthesizer class hierarchies to produce a new camera driver.
|
||||
|
||||
The sample comes with its own MFT0 called AvsCameraMft0.dll. This MFT0 is used to parse metadata supplied in the AvsCamera driver samples. The metadata communications from the driver is primarily a private channel to its MFT0. The MFT0 is responsible for reformatting that information for the capture pipeline.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP. The sample works on 32-bit and 64-bit x86, amd64 and arm platforms. Once installed, the simulated camera should show in the Windows Inbox camera app.
|
||||
|
||||
## Building the sample
|
||||
|
||||
The AvsCamera sample can be built by opening the AvsCamera.sln solution file. A successful build produces AvsCamera.sys, AvsCameraMft0.dll, AvsCamera.inf and AvsCamera.cat.
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: AVStream simulated hardware sample driver (Avshws)
|
||||
description: A simulated hardware sample driver providing a pin-centric capture driver to simulate AV capture hardware.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: AVStream simulated hardware sample driver (Avshws)
|
||||
platform: WDM
|
||||
|
|
@ -7,8 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620185
|
||||
--->
|
||||
|
||||
AVStream simulated hardware sample driver (Avshws)
|
||||
==================================================
|
||||
# AVStream simulated hardware sample driver (Avshws)
|
||||
|
||||
The AVStream simulated hardware sample driver (Avshws) provides a pin-centric [AVStream](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554240) capture driver for a simulated piece of hardware. This streaming media driver performs video captures at 320 x 240 pixels in either RGB24 or YUV422 format using direct memory access (DMA) into capture buffers. The purpose of the sample is to demonstrate how to write a pin-centric AVStream minidriver. The sample also shows how to implement DMA by using the related functionality provided by the AVStream class driver.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: AVStream simulated hardware sample driver (Avshws)
|
||||
description: A simulated hardware sample driver providing a pin-centric capture driver to simulate AV capture hardware.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /avstream/avshws/avshws.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: AVStream filter-centric simulated capture sample driver (Avssamp)
|
||||
description: An AVStream filter-centric simulated capture sample driver with functional audio.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: AVStream filter-centric simulated capture sample driver (Avssamp)
|
||||
platform: WDM
|
||||
|
|
@ -7,8 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620186
|
||||
--->
|
||||
|
||||
AVStream filter-centric simulated capture sample driver (Avssamp)
|
||||
=================================================================
|
||||
# AVStream filter-centric simulated capture sample driver (Avssamp)
|
||||
|
||||
The AVStream filter-centric simulated capture sample driver (Avssamp) provides a filter-centric [AVStream](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554240) capture driver with functional audio. This streaming media driver performs video captures at 320 x 240 pixel resolution in RGB24 or YUV422 format while playing a user-provided Pulse Code Modulation (PCM) wave audio file in a loop. The sample demonstrates how to write a filter-centric AVStream minidriver.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: AVStream filter-centric simulated capture sample driver (Avssamp)
|
||||
description: An AVStream filter-centric simulated capture sample driver with functional audio.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /avstream/avssamp/avssamp.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Driver Device Transform Sample
|
||||
description: A driver device transform which loads in a process streaming an Avstream based camera device using Media Foundation.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Driver Device Transform Sample
|
||||
platform: WDM
|
||||
|
|
@ -7,8 +17,8 @@
|
|||
samplefwlink: https://go.microsoft.com/fwlink/?linkid=866747
|
||||
--->
|
||||
|
||||
Driver Device Transform Sample
|
||||
==============================
|
||||
# Driver Device Transform Sample
|
||||
|
||||
Illustrative example for a *Driver Device Transform* which loads in a process streaming an Avstream based camera device using Media Foundation.
|
||||
|
||||
A *Driver Device Transform* is a new kind of a transform that's used with a specific camera when capturing video. The *Driver Device Transform* is also known as DeviceMFT because it is the first Device Transform applied to the video source. This *Driver Device Transform* is an alternative to the Driver MFT i.e. MFT0 in that, it caters to the source rather than the streams . An N stream source supporting DeviceMFT will have a single instance of the *Device Driver Transform* loaded, while MFT0 will have *N* instances for each pipeline process. The DeviceMFT can advertise multiple streams at the output, which can differ from the number of streams advertised by the source. This is analogous to having a user mode driver in the MF pipeline which intercepts and processes commands before they enter/ leave the Kernel mode driver loaded for the streaming source.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Driver Device Transform Sample
|
||||
description: A driver device transform which loads in a process streaming an Avstream based camera device using Media Foundation.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /avstream/sampledevicemft/SampleDeviceMft.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Driver MFT Sample
|
||||
description: A driver MFT for use with a camera's Windows device app.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Driver MFT Sample
|
||||
platform: WDM
|
||||
|
|
@ -7,8 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617126
|
||||
--->
|
||||
|
||||
Driver MFT Sample
|
||||
=================
|
||||
# Driver MFT Sample
|
||||
|
||||
Provides a *driver MFT* for use with a camera's UWP device app.A *driver MFT* is a Media Foundation Transform that's used with a specific camera when capturing video. The driver MFT is also known as MFT0 because it is the first MFT applied to the video stream captured from the camera. This MFT can provide a video effect or other processing when capturing photos or video from the camera. It can be distributed along with the driver package for a camera.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Driver MFT Sample
|
||||
description: A driver MFT for use with a camera's Windows device app.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /avstream/samplemft0/SampleMft0.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Windows Biometric Driver Samples (UMDF Version 1)
|
||||
description: Contains the Windows Biometric Driver Interface sample and the Windows Biometric Service Adapter samples.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Windows Biometric Driver Samples (UMDF Version 1)
|
||||
platform: UMDF1
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620189
|
||||
--->
|
||||
|
||||
|
||||
Windows Biometric Driver Samples (UMDF Version 1)
|
||||
=================================================
|
||||
# Windows Biometric Driver Samples (UMDF Version 1)
|
||||
|
||||
The Windows Biometric Driver Samples contain the Windows Biometric Driver Interface sample and the Windows Biometric Service Adapter samples.
|
||||
|
||||
|
|
@ -52,11 +60,11 @@ Design and Operation
|
|||
|
||||
This sample is taken from the UMDF FX2 sample and has been modified to expose WBDI. It has the necessary hooks to make this a WBDI driver:
|
||||
|
||||
- Installs WBDI driver, including correct class GUID settings and icons, and registry settings for Windows Biometric Framework configuration.
|
||||
- Publishes WBDI device interface.
|
||||
- Supports all the mandatory [WBDI IOCTLs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536414).
|
||||
- Supports cancellation.
|
||||
- Can be opened with exclusivity.
|
||||
- Installs WBDI driver, including correct class GUID settings and icons, and registry settings for Windows Biometric Framework configuration.
|
||||
- Publishes WBDI device interface.
|
||||
- Supports all the mandatory [WBDI IOCTLs](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/_biometric/#ioctls).
|
||||
- Supports cancellation.
|
||||
- Can be opened with exclusivity.
|
||||
|
||||
All of these things are required for the Windows Biometric Framework service to recognize this device as a biometric device and set up a Biometric Unit. It allows the service to properly control the device.
|
||||
|
||||
|
|
@ -68,7 +76,7 @@ It uses device level-locking to simplify internal thread synchronization. This m
|
|||
|
||||
It supports cancellation of any IOCTL which may be I/O intensive, particularly a capture IOCTL. This sample does not have a real capture mechanism, so it is simulated by a 5 second delay returning a capture IOCTL. Cancellation is supported through the mechanism exposed by WUDF, with a callback for a request object. Cancellation support is required for all IOCTLs.
|
||||
|
||||
There are hooks for all [WBDI IOCTLs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536414), including the optional IOCTLs.
|
||||
There are hooks for all [WBDI IOCTLs](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/_biometric/#ioctls), including the optional IOCTLs.
|
||||
|
||||
PnP is very simple for this driver. It needs to only implement **OnPrepareHardware** and **OnReleaseHardware** from **IPnpCallbackHardware**.
|
||||
|
||||
|
|
@ -78,11 +86,10 @@ Some device drivers may need to keep several pending reads to the WinUsb I/O tar
|
|||
|
||||
WinBio Adapters are plug-in components that provide a standard interface layer between the Windows Biometric Service and a biometric device. The WinBio Service recognizes three types of Adapters:
|
||||
|
||||
- Sensor Adapters - expose the sample-capture capabilities of the biometric device.
|
||||
- Engine Adapters - expose the sample manipulation, template generation, and matching capabilities of the device.
|
||||
- Storage Adapters - expose the template storage and retrieval capabilities of the device.
|
||||
- Sensor Adapters - expose the sample-capture capabilities of the biometric device.
|
||||
- Engine Adapters - expose the sample manipulation, template generation, and matching capabilities of the device.
|
||||
- Storage Adapters - expose the template storage and retrieval capabilities of the device.
|
||||
|
||||
For many simple biometric devices, it will only be necessary to write a WBDI driver for the device plus an Engine Adapter to perform matching operations. Consult the programming guidelines in the WinBio Service documentation for more details.
|
||||
|
||||
Each Adapter sample contains a well-known interface-discovery function, whose job is to return the address of a function dispatch table. When the WinBio Service loads an Adapter plug-in, it uses the interface-discovery function to locate the dispatch table, and then calls various methods in the table to communicate with the biometric device. The purpose, arguments, and return codes of each Adapter method are described in the WinBio Service programming guidelines. More information on adapter plug-ins is available at [WBDI Plug-in Reference](http://msdn.microsoft.com/en-us/library/windows/desktop/dd401553(v=vs.85).aspx).
|
||||
|
||||
Each Adapter sample contains a well-known interface-discovery function, whose job is to return the address of a function dispatch table. When the WinBio Service loads an Adapter plug-in, it uses the interface-discovery function to locate the dispatch table, and then calls various methods in the table to communicate with the biometric device. The purpose, arguments, and return codes of each Adapter method are described in the WinBio Service programming guidelines. More information on adapter plug-ins is available at [WBDI Plug-in Reference](https://docs.microsoft.com/windows/desktop/SecBioMet/plug-in-reference).
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Windows Biometric Driver Samples (UMDF Version 1)
|
||||
description: Contains the Windows Biometric Driver Interface sample and the Windows Biometric Service Adapter samples.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /biometrics/WBDIsample.sln
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Bluetooth Echo L2CAP Profile Driver
|
||||
description: Demonstrates development of Bluetooth L2CAP profile drivers using the Bluetooth L2CAP DDIs.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /bluetooth/bthecho/bthecho.sln
|
||||
|
|
@ -0,0 +1,231 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Bluetooth Echo L2CAP Profile Driver
|
||||
description: Demonstrates development of Bluetooth L2CAP profile drivers using the Bluetooth L2CAP DDIs.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Bluetooth Echo L2CAP Profile Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: Bluetooth
|
||||
description: Demonstrates development of Bluetooth L2CAP profile drivers using the Bluetooth L2CAP DDIs.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617640
|
||||
--->
|
||||
|
||||
# Bluetooth Echo L2CAP Profile Driver
|
||||
|
||||
This sample demonstrates developing [Bluetooth L2CAP profile drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536598) using [Bluetooth L2CAP DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585).The sample includes two drivers. One for a device that acts as an L2CAP server and another for a device that acts as an L2CAP client. The server simply echoes back any data that it receives from client on the same L2CA channel. These drivers can be used with devices that can be installed with bth.inf. Such devices get installed as 'Generic Bluetooth Radio'. Examples of such devices are Bluetooth USB dongles such as (but not limited to):
|
||||
|
||||
```
|
||||
Generic Bluetooth Radio=\
|
||||
BthUsb, USB\Vid_0a12&Pid_0001
|
||||
CSR Nanosira=\
|
||||
BthUsb, USB\Vid_0a12&Pid_0003
|
||||
CSR Nanosira WHQL Reference Radio=\
|
||||
BthUsb, USB\Vid_0a12&Pid_0004
|
||||
CSR Nanosira-Multimedia=\
|
||||
BthUsb, USB\Vid_0a12&Pid_0005
|
||||
CSR Nanosira-Multimedia WHQL Reference Radio=\
|
||||
BthUsb, USB\Vid_0a12&Pid_0006
|
||||
```
|
||||
|
||||
Please refer to bth.inf for the complete list of devices. The installation steps below describe how to install echo server and client with such a device. Please note that RFCOMM based profiles must be developed and accessed using user-mode socket APIs.
|
||||
|
||||
Build the sample
|
||||
----------------
|
||||
|
||||
You can build the sample in two ways: using the Visual Studio Integrated Development Environment (IDE) or from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe).
|
||||
|
||||
**Building the sample using Visual Studio**
|
||||
|
||||
1. Open Visual Studio. From the **File** menu, select **Open Project/Solution** and open the bthecho.sln project file.
|
||||
2. Right-click the solution in the **Solution Explorer** and select **Configuration Manager**.
|
||||
3. From the **Configuration Manager**, select the **Active Solution Configuration** and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in.
|
||||
4. From the **Build** menu, click **Build Solution** (Ctrl+Shift+B).
|
||||
|
||||
**Building the sample using the command line (MSBuild)**
|
||||
|
||||
1. Open a Visual Studio Command Prompt window. Click **Start** and search for **Developer Command Prompt**. If your project is under %PROGRAMFILES%, you need to open the command prompt window using elevated permissions (**Run as administrator**). From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file.
|
||||
2. Navigate to each of the respective project directories and enter the appropriate **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called BthEcho.vcxproj, navigate to the samples\\bluetooth\\bthecho\\bthcli\\sys project directory and enter the following MSBuild command: **msbuild /t:clean /t:build .\\BthEchoSampleCli.vcxproj**.
|
||||
3. If the build succeeds, you will find the driver (BthEchoSampleCli.sys) in the binary output directory corresponding to the target platform.
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
|
||||
**INSTALLATION**
|
||||
|
||||
**Note**: Bluetooth echo server device and echo client device must be installed on two different machines, as described below.
|
||||
|
||||
**Server Installation**
|
||||
|
||||
1. Copy KMDF coinstaller (wdfcoinstallerMMmmm.dll, from redist\\wdf\\ ), BthEchoSampleSrv.Sys, BthEchoSampleSrv.inf and bthsrvinst.exe on a temporary directory on the target machine.
|
||||
|
||||
2. Run bthsrvinst.exe /i to install the echo server device. This enables the Bluetooth Enumerator (BthEnum.sys) to enumerate echo server device and create a PDO for the device (please refer to the device tree below).
|
||||
|
||||
3. Step \#2 causes BthEnum.sys to create a PDO. Consequently hardware installation wizard gets launched. Either go through the UI and point it to the temporary directory where you copied the binaries in step \#1, or using devcon.exe from the tools\\devcon folder, run the following command from the temporary directory:
|
||||
|
||||
```
|
||||
devcon.exe update BthEchoSampleSrv.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4}
|
||||
```
|
||||
|
||||
If devcon.exe fails check the error level using:
|
||||
|
||||
```
|
||||
echo %errorlevel%
|
||||
```
|
||||
|
||||
If errorlevel is 1, you need to reboot the machine for KMDF update to take effect. If errorlevel is 2, please make sure that you have the driver files described in \#1 available in the current directory. For more information on installation failure please check setup logs.
|
||||
|
||||
4. Upon successful installation you will see 'Bluetooth Echo Sample Server' in Device Manager under Bluetooth devices.
|
||||
|
||||
**Device tree for Echo Server device**
|
||||
|
||||
(Drivers for FDOs are shown for each devnode in the tree.)
|
||||
|
||||
```
|
||||
--------------------
|
||||
|BthEchoSampleSrv.sys|<----Function driver for PDO ejected by BthEnum.sys
|
||||
--------------------
|
||||
^
|
||||
| --------------------
|
||||
| |Bluetooth Enumerator|
|
||||
-----| (BthEnum.SYS) |
|
||||
--------------------
|
||||
^
|
||||
| (Bth port driver loaded by bthusb.sys)
|
||||
| --------------------- ----------------------
|
||||
-----| bthport.SYS |<--->| bthusb.SYS |
|
||||
--------------------- ----------------------
|
||||
^
|
||||
|
|
||||
V
|
||||
----------------------
|
||||
| USB Stack |
|
||||
----------------------
|
||||
^
|
||||
|
|
||||
V
|
||||
----------------------
|
||||
| USB Bluetooth Dongle |
|
||||
----------------------
|
||||
```
|
||||
|
||||
**Client Installation**
|
||||
|
||||
1. **Important**: This must be done on a separate machine from the one where echo server device was installed.
|
||||
|
||||
2. Copy KMDF coinstaller (wdfcoinstallerMMmmm.dll, from redist\\wdf\\), BthEchoSampleCli.Sys, BthEchoSampleCli.inf and bthecho.exe on a temporary directory on the target machine.
|
||||
|
||||
3. Run bthprops.cpl from a command line or right click on the Bluetooth icon in the system tray and select 'Show Devices' to bring up a list of installed Bluetooth devices.
|
||||
|
||||
4. In the **Bluetooth Devices** window, click the **Add a device** button.
|
||||
|
||||
5. In the Add a Device wizard select the server machine (the machine where you installed the echo server) as a Bluetooth device. If the server machine does not appear, please check the echo server installation and make sure that you have enabled 'Allow Bluetooth device to find this computer' on the server machine as explained above. When the server machine is correctly displayed, select it and pick 'Next'.
|
||||
|
||||
6. The wizard should default to a numeric compare ceremony for pairing the machines. When this happens, ensure the numbers match on both the client and the server, select 'Yes' on both machines to indicate they match, and click 'Next' on both machines to complete the pairing.
|
||||
|
||||
7. Go through Device Manager and update driver software for it. Either point the wizard to the temporary directory created in step \#2, or use devcon.exe from the tools\\devcon folder to install the client device:
|
||||
|
||||
```
|
||||
Devcon.exe update BthEchoSampleCli.inf BTHENUM\{c07508f2-b970-43ca-b5dd-cc4f2391bef4}
|
||||
```
|
||||
|
||||
Check for any error from devcon.exe as described in server installation.
|
||||
|
||||
If the installation is successful, you will see 'Bluetooth Echo Sample Client' in Device Manager under Bluetooth devices.
|
||||
|
||||
The device tree for echo client device is similar to the one shown for the echo server device, since both client and server are enumerated by BthEnum.sys (although the installation mechanism and properties of client and server are different).
|
||||
|
||||
**Uninstalling Server**
|
||||
|
||||
1. Uninstall the device and delete driver software using the Bluetooth Devices window by running bthprops.cpl, right clicking on the device, and selecting 'Remove Device'
|
||||
|
||||
2. Run bthsrvinst.exe /u to uninstall the echo server. This would make bthenum.sys stop enumerating the echo server. Without this step 'Found New Hardware' wizard will be launched again when you reconnect the device.
|
||||
|
||||
**Uninstalling Client**
|
||||
|
||||
|
||||
- Uninstall the device and delete driver software using the Bluetooth Devices window by running bthprops.cpl, right clicking on the device, and selecting 'Remove Device'.
|
||||
|
||||
**TESTING**
|
||||
|
||||
Run BthEcho.exe on the client machine. You should see client sending data to the server and receiving the same data echoed back. Press Ctrl+c to terminate the application. You will see output similar to below:
|
||||
|
||||
```
|
||||
D:\bth\wdfcli>BthEcho.exe
|
||||
DevicePath: \\?\bthenum#{c07508f2-b970-43ca-b5dd-cc4f2391bef4}_localmfg&000a#7&3
|
||||
62d0a3&0&000c55ff727a_c00000001#{fc71b33d-d528-4763-a86c-78777c7bcd7b}
|
||||
Opened device successfully
|
||||
Written 26 bytes: WDF Bluetooth Sample Echo
|
||||
Reply from server 26 bytes: WDF Bluetooth Sample Echo
|
||||
Written 26 bytes: WDF Bluetooth Sample Echo
|
||||
Reply from server 26 bytes: WDF Bluetooth Sample Echo
|
||||
Written 26 bytes: WDF Bluetooth Sample Echo
|
||||
Reply from server 26 bytes: WDF Bluetooth Sample Echo
|
||||
Written 26 bytes: WDF Bluetooth Sample Echo
|
||||
Reply from server 26 bytes: WDF Bluetooth Sample Echo
|
||||
Written 26 bytes: WDF Bluetooth Sample Echo
|
||||
^C
|
||||
```
|
||||
|
||||
You can launch multiple instances of BthEcho.exe. Each client application would cause echo client device to have an independent connection to the echo server and thereby have an independent echo session. You can also have echo client devices and apps installed on multiple machines and talking to a single echo server.
|
||||
|
||||
**CODE TOUR**
|
||||
|
||||
**Common code**
|
||||
|
||||
**Connection object**: The common code contains implementation of a connection object (in connection.\*) that is utilized by both client and the server. Client uses this object to maintain the information about opened connection and the server uses this object to maintain information about the accepted connection. Connection object also supports continuous reader which is utilized by server to read the data sent by client. Connection object is implemented as a WDF user object. Connection details are maintained in BTHECHO\_CONNECTION structure. This structure is used as the context for WDF user object. Passive dispose is used to make the connection object cleanup wait for disconnect completion and continuous reader rundown. Please see WDF documentation for WDF user object and passive dispose (see WdfObjectCreate).
|
||||
|
||||
**Server**
|
||||
|
||||
**Startup**: Server registers PSM and L2CA server and published SDP record on startup in BthEchoSrvEvtDeviceSelfManagedIoInit (this callback is invoked by WDF during device start). While registering the L2CA server it passes BthEchoSrvIndicationCallback as the callback for incoming connection notifications.
|
||||
|
||||
**Server SDP record creation**: The sample uses dynamic creation of server SDP record using Bluetooth DDIs. Please note that for your particular device you may be able to use static data for the SDP record.
|
||||
|
||||
**Incoming connections**: Bluetooth stack invokes BthEchoSrvIndicationCallback for the incoming connections from clients. In response server accepts the connection and passes BthEchoSrvConnectionIndicationCallback callback to Bluetooth stack for disconnect notification. It is possible to use the same indication callback for server and connection but the sample uses different callbacks for clarity. Server adds the accepted connection to the connection list it maintains. Please see below for connection rundown details.
|
||||
|
||||
**Connection rundown**: Server maintains a list of all the connections it has accepted. This allows server to properly close down these connections on orderly removal. On surprise removal bthport.sys itself gets removed and takes care of running down the connections, but in case of orderly removal driver has to make sure to rundown the connections.
|
||||
|
||||
**Connection state machine**:
|
||||
|
||||
```
|
||||
ConnectFailed
|
||||
^
|
||||
|
|
||||
|
|
||||
| (connection failure)
|
||||
Uninitialized ----> Connecting -------> Connected
|
||||
| (disconnect) / ^
|
||||
| / /
|
||||
| / /
|
||||
V V / (connection complete)
|
||||
Disconnecting
|
||||
| (disconnect complete)
|
||||
|
|
||||
|
|
||||
V
|
||||
Disconnected
|
||||
```
|
||||
|
||||
One transition to note here is that if disconnect is received in the connecting state (i.e. when the connection is not completed) we wait for connection to completed (transition to connected state) and then invoke disconnect.
|
||||
|
||||
**Important**: Such state machine is needed only if Disconnect is initiated by something other than Bluetooth stack (for example device removal in our case). Bluetooth stack itself would not send disconnect before connect completion. If you adapt this sample for your device please evaluate whether your driver would require such state machine. For example, the echo client device does not need such state machine (although we use common connection code for client and the server).
|
||||
|
||||
**Shutdown**: Server removes the SDP record and unregisters L2CAP server and PSM in BthEchoSrvEvtDeviceSelfManagedIoCleanup (this callback is invoked by WDF during device removal). It also disconnects any open connections (see Connection rundown above).
|
||||
|
||||
**Client**
|
||||
|
||||
**Startup**: Client retrieves local and server Bluetooth address in BthEchoSrvEvtDeviceSelfManagedIoInit (this callback is invoked by WDF during device start). Please note that server Bluetooth address would be available regardless of presence of the server. Thus echo client device start doesn't fail even if echo server is not available.
|
||||
|
||||
**Connecting to server**: Client connects to echo server when application opens a handle to it (BthEchoCliEvtDeviceFileCreate) and closes the connection on file close (BthEchoCliEvtFileClose).
|
||||
|
||||
**Sending and receiving data from server**: When application writes data to the client, client sends this data to server on the connection opened for the given handle. Server would echo back this data. This data is retrieved by the application using a read operation. Echo Sample Client doesn't do any draining of echoed data on its own. Application read/write are handled using a parallel WDF I/O queue.
|
||||
|
||||
**Shutdown**: Client doesn't need any specific shutdown code as connection open/close and read/write are done within the context of application's handle open.
|
||||
|
||||
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Bluetooth Serial HCI Bus Driver
|
||||
description: Demonstrates how to implement a basic bus driver to support the new Bluetooth Extensibility transport DDIs over the UART transport.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Bluetooth Serial HCI Bus Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,12 +17,12 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617641
|
||||
--->
|
||||
|
||||
Bluetooth Serial HCI Bus Driver
|
||||
===============================
|
||||
# Bluetooth Serial HCI Bus Driver
|
||||
|
||||
The purpose of this sample is to demonstrate how to implement a basic bus driver to support the new [Bluetooth Extensibility transport DDIs](http://msdn.microsoft.com/en-us/library/windows/hardware/ff536585) over the UART transport. Such a serial bus driver can support a multi-radio device over the UART transport and utilize a common Bluetooth HCI packet for communication. The lower edge of this driver interfaces with a UART controller following the Bluetooth SIG's UART (H4) transport protocol.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
**Note** This sample driver is generic. It is not designed for a specific device and allows for a vendor to adopt and enhance it for supporting Bluetooth.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Bluetooth Serial HCI Bus Driver
|
||||
description: Demonstrates how to implement a basic bus driver to support the new Bluetooth Extensibility transport DDIs over the UART transport.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /bluetooth/serialhcibus/serialhcibus.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: CDFS File System Driver
|
||||
description: The CD-ROM file system driver (cdfs) sample is a file system driver for removable media.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: CDFS File System Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617642
|
||||
--->
|
||||
|
||||
|
||||
CDFS File System Driver
|
||||
=======================
|
||||
# CDFS File System Driver
|
||||
|
||||
The CD-ROM file system driver (cdfs) sample is a sample file system driver that you can use to write new file systems.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: CDFS File System Driver
|
||||
description: The CD-ROM file system driver (cdfs) sample is a file system driver for removable media.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/cdfs/cdfs.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: fastfat File System Driver
|
||||
description: A file system driver based on the Windows inbox FastFAT file system used as a model for new file systems.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: fastfat File System Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,10 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620305
|
||||
--->
|
||||
|
||||
|
||||
|
||||
fastfat File System Driver
|
||||
==========================
|
||||
# fastfat File System Driver
|
||||
|
||||
The *fastfat* sample is file system driver that you can use as a model to write new file systems.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: fastfat File System Driver
|
||||
description: A file system driver based on the Windows inbox FastFAT file system used as a model for new file systems.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/fastfat/fastfat.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Metadata Manager File System Minifilter Driver
|
||||
description: An example of how to use files for storing metadata that corresponds to minifilters.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Metadata Manager File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,17 +17,15 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617650
|
||||
--->
|
||||
|
||||
|
||||
Metadata Manager File System Minifilter Driver
|
||||
==============================================
|
||||
# Metadata Manager File System Minifilter Driver
|
||||
|
||||
The Metadata Manager minifilter sample serves as an example if you want to use files for storing metadata that corresponds to your minifilters. The implementation of this sample depicts scenarios in which modifications to the file might have to be blocked or the minifilter might be required to close the file temporarily.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The Metadata Manager minifilter opens a file when it is first loaded. After that, the minifilter monitors open, close, file control, device control, and Plug and Play (PnP) operations to identify scenarios in which it should close its metadata file or block all writes to it. Applications such as chkdsk obtain implicit or explicit exclusive locks on the volume, and the metadata minifilter demonstrates how to maintain a metadata file without interfering with such lock acquisitions.
|
||||
|
||||
|
|
@ -28,4 +36,3 @@ Similarly, the minifilter might close its metadata file if it sees an explicit F
|
|||
The metadata minifilter also handles the case when a snapshot of its volume object is being taken. In this scenario, the minifilter acquires a shared exclusive lock on the metadata resource object while calling the callback that corresponds to the pre-device control operation for IOCTL\_VOLSNAP\_FLUSH\_AND\_HOLD\_WRITES. The lock is later released in the callback that corresponds to the post-device control operation for IOCTL\_VOLSNAP\_FLUSH\_AND\_HOLD\_WRITES. The lock is acquired to prevent any modifications on the metadata file while the snapshot is being taken.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Metadata Manager File System Minifilter Driver
|
||||
description: An example of how to use files for storing metadata that corresponds to minifilters.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/MetadataManager/MetadataManager.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: NameChanger File System Minifilter Driver
|
||||
description: Grafts a directory from one part of a volume's namespace to another part using a mapping.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: NameChanger File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617652
|
||||
--->
|
||||
|
||||
|
||||
NameChanger File System Minifilter Driver
|
||||
=========================================
|
||||
# NameChanger File System Minifilter Driver
|
||||
|
||||
The *NameChanger* minifilter grafts a directory from one part of a volume's namespace to another part using a mapping. The minifilter maintains this illusion by acting as a name provider, injecting entries into directory enumerations and forwarding directory change notifications.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: NameChanger File System Minifilter Driver
|
||||
description: Grafts a directory from one part of a volume's namespace to another part using a mapping.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/NameChanger/NameChanger.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: AvScan File System Minifilter Driver
|
||||
description: This filter is a transaction-aware file scanner that examines data in files.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: AvScan File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617644
|
||||
--->
|
||||
|
||||
|
||||
AvScan File System Minifilter Driver
|
||||
====================================
|
||||
# AvScan File System Minifilter Driver
|
||||
|
||||
The AvScan minifilter is a transaction-aware file scanner. This is an example for developers who intend to write filters that examine data in files. Typically, anti-virus products fall into this category.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: AvScan File System Minifilter Driver
|
||||
description: This filter is a transaction-aware file scanner that examines data in files.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/avscan/avscan.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: CancelSafe File System Minifilter Driver
|
||||
description: A minifilter demonstrating the use of cancel-safe queues.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: CancelSafe File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617645
|
||||
--->
|
||||
|
||||
|
||||
CancelSafe File System Minifilter Driver
|
||||
========================================
|
||||
# CancelSafe File System Minifilter Driver
|
||||
|
||||
The CancelSafe filter is a sample minifilter that you use if you want to use cancel-safe queues.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: CancelSafe File System Minifilter Driver
|
||||
description: A minifilter demonstrating the use of cancel-safe queues.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/cancelSafe/cancelSafe.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: CDO File System Minifilter Driver
|
||||
description: An example of using a control device object (CDO) with a minifilter.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: CDO File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,15 +17,14 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617646
|
||||
--->
|
||||
|
||||
|
||||
CDO File System Minifilter Driver
|
||||
=================================
|
||||
# CDO File System Minifilter Driver
|
||||
|
||||
The CDO minifilter sample is an example if you intend to use a control device object (CDO) with your minifilters.
|
||||
|
||||
Although the filter manager infrastructure provides a message interface for communication between applications and minifilters, you might need explicit CDOs while the minifilters interface with legacy software. This sample shows how to create and use a CDO with minifilters.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: CDO File System Minifilter Driver
|
||||
description: An example of using a control device object (CDO) with a minifilter.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/cdo/cdo.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Change File System Minifilter Driver
|
||||
description: A transaction-aware filter that monitors file changes in real time.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Change File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617647
|
||||
--->
|
||||
|
||||
|
||||
Change File System Minifilter Driver
|
||||
====================================
|
||||
# Change File System Minifilter Driver
|
||||
|
||||
The Change minifilter is a transaction-aware filter that monitors file changes in real time.
|
||||
|
||||
|
|
@ -17,11 +25,11 @@ This filter tracks if the files are 'dirty' by intercepting write I/O requests.
|
|||
|
||||
The primary tasks of the filter for tracking a transacted file are the following:
|
||||
|
||||
1. In the post create callback, if a transacted file is open with attribute FILE\_WRITE\_DATA or FILE\_APPEND\_DATA, then enlist its file context into the transaction context.
|
||||
2. In the pre-operation callback, if the operation needs to be dirty, such as IRP\_MJ\_WRITE and the file is part of a transaction, update the transacted dirty record instead of the non-transacted dirty record.
|
||||
3. In the kernel transaction manager (KTM) notification callback, if the transaction is committed, then propagate the dirty information from the transacted dirty record to the non-transacted dirty record; if rollback, do not propagate.
|
||||
4. Properly remove the context structure in the TransactionContextCleanup routine.
|
||||
1. In the post create callback, if a transacted file is open with attribute FILE\_WRITE\_DATA or FILE\_APPEND\_DATA, then enlist its file context into the transaction context.
|
||||
1. In the pre-operation callback, if the operation needs to be dirty, such as IRP\_MJ\_WRITE and the file is part of a transaction, update the transacted dirty record instead of the non-transacted dirty record.
|
||||
1. In the kernel transaction manager (KTM) notification callback, if the transaction is committed, then propagate the dirty information from the transacted dirty record to the non-transacted dirty record; if rollback, do not propagate.
|
||||
1. Properly remove the context structure in the TransactionContextCleanup routine.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Change File System Minifilter Driver
|
||||
description: A transaction-aware filter that monitors file changes in real time.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/change/change.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Ctx File System Minifilter Driver
|
||||
description: Demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Ctx File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,17 +17,15 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617648
|
||||
--->
|
||||
|
||||
|
||||
Ctx File System Minifilter Driver
|
||||
=================================
|
||||
# Ctx File System Minifilter Drive
|
||||
|
||||
The Ctx minifilter is an example that demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The *Ctx* minifilter demonstrates how to attach and remove contexts from instances, files, steams, and stream handles. *Ctx* attaches a context whenever one of these objects is created. While attaching a context to a file, the sample also creates a stream and stream handle context. All contexts are ultimately deleted by the filter manager using the callback function that the *Ctx* minifilter provides.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Ctx File System Minifilter Driver
|
||||
description: Demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/ctx/ctx.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Delete File System Minifilter Driver
|
||||
description: Demonstrates how to detect deletions of files or streams.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Delete File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,16 +17,15 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617649
|
||||
--->
|
||||
|
||||
Delete File System Minifilter Driver
|
||||
====================================
|
||||
# Delete File System Minifilter Driver
|
||||
|
||||
The Delete minifilter is an example that demonstrates how to detect deletions of files or streams. Deletions are reported as debug output.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The *delete* minifilter illustrates how to detect deletion of files and streams. It monitors IRP\_MJ\_CREATE requests for the FILE\_DELETE\_ON\_CLOSE flag. Also, it detects IRP\_MJ\_SET\_INFORMATION requests for setting FileDispositionInformation/FileDispositionInformationEx. The sample also illustrates how to handle racing deletes (in the form of multiple parallel IRP\_MJ\_SET\_INFORMATION operations), and how to distinguish deletion of an entire file from deletion of just one stream of the file.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Delete File System Minifilter Driver
|
||||
description: Demonstrates how to detect deletions of files or streams.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/delete/delete.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Minispy File System Minifilter Driver
|
||||
description: A tool to monitor and log any I/O and transaction activity that occurs in the system.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Minispy File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,21 +17,18 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617651
|
||||
--->
|
||||
|
||||
|
||||
Minispy File System Minifilter Driver
|
||||
=====================================
|
||||
# Minispy File System Minifilter Driver
|
||||
|
||||
The Minispy sample is a tool to monitor and log any I/O and transaction activity that occurs in the system. Minispy is implemented as a minifilter.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
Minispy consists of both user-mode and kernel-mode components. The kernel-mode component registers callback functions that correspond to various I/O and transaction operations with the filter manager. These callback functions help Minispy record any I/O and transaction activity occurring in the system. When a user can request the recorded information, the recorded information is passed to the user-mode component, which can either output it on screen or log it to a file on disk.
|
||||
|
||||
To observe I/O activity on a device, you must explicitly attach Minispy to that device by using the Minispy user-mode component. Similarly, you can request Minispy to stop logging data for a particular device.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Minispy File System Minifilter Driver
|
||||
description: A tool to monitor and log any I/O and transaction activity that occurs in the system.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/minispy/minispy.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: NullFilter File System Minifilter Driver
|
||||
description: A minifilter that demonstrates registration with the filter manager.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: NullFilter File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,18 +17,16 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617653
|
||||
--->
|
||||
|
||||
NullFilter File System Minifilter Driver
|
||||
========================================
|
||||
# NullFilter File System Minifilter Driver
|
||||
|
||||
The NullFilter minifilter is a sample minifilter that shows how to register a minifilter with the filter manager.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The *NullFilter* minifilter is a simple minifilter that registers itself with the filter manager for no callback operations.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: NullFilter File System Minifilter Driver
|
||||
description: A minifilter that demonstrates registration with the filter manager.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/nullFilter/nullFilter.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: PassThrough File System Minifilter Driver
|
||||
description: Demonstrates how to specify callback functions for different types of I/O requests.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: PassThrough File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,19 +17,16 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617654
|
||||
--->
|
||||
|
||||
|
||||
PassThrough File System Minifilter Driver
|
||||
=========================================
|
||||
# PassThrough File System Minifilter Driver
|
||||
|
||||
The PassThrough minifilter demonstrates how to specify callback functions for different types of I/O requests.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The *PassThrough* minifilter does not have any real functionality. For each type of I/O operation, the same pre and post callback functions are called. These callback functions simply forward the I/O request to the next filter on the stack.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: PassThrough File System Minifilter Driver
|
||||
description: Demonstrates how to specify callback functions for different types of I/O requests.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/passThrough/passThrough.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Scanner File System Minifilter Driver
|
||||
description: A file data scanner example. Typically, anti-virus filters are of this type.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Scanner File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,21 +17,18 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617655
|
||||
--->
|
||||
|
||||
|
||||
Scanner File System Minifilter Driver
|
||||
=====================================
|
||||
# Scanner File System Minifilter Driver
|
||||
|
||||
The Scanner minifilter is an example for developers who intend to write filters that examine data in files. Typically, antivirus products fall into this category.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The Scanner minifilter comprises both kernel-mode and user-mode components. The kernel-mode component recognizes appropriate moments for scanning a file's data and passes it to the user-mode component for further validation. The user-mode component creates a number of threads that await validation requests and corresponding data from the kernel-mode component. After scanning the data for occurrences of a "foul" string, the user-mode component sends an appropriate response to the kernel-mode component.
|
||||
|
||||
The kernel-mode component scans files with specific extensions only. The file is first scanned on a successful open. If the file was opened with write access, it is scanned again before a close. Scanning is also performed on data that is about to be written to a file. Writes will be rejected if any occurrences of a "foul" string are found in the data. If a "foul" string is detected during the closing of a file, a debug message is printed.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Scanner File System Minifilter Driver
|
||||
description: A file data scanner example. Typically, anti-virus filters are of this type.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/scanner/scanner.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: SimRep File System Minifilter Driver
|
||||
description: Demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: SimRep File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,17 +17,15 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617656
|
||||
--->
|
||||
|
||||
|
||||
SimRep File System Minifilter Driver
|
||||
====================================
|
||||
# SimRep File System Minifilter Driver
|
||||
|
||||
SimRep is a sample filter that demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
Normally, if the file-system sees an open for a file with a reparse-point on it, the filesystem fills out the tag buffer and returns STATUS\_REPARSE. Minifilters see the post-operation callback for this create. As the create travels up file system filter stack in post-create path, each minifilter has the opportunity to interpret the reparse point if they own the tag. If no file system filter claims the tag, IO Manager will attempt to interpret the tag based on tags known to and serviced by IO Manager. If the tag is unknown to IO manager then the create is failed with STATUS\_IO\_REPARSE\_TAG\_NOT\_HANDLED. SimRep does not demonstrate how to handle the case where the file system hits a reparse-point on the file. Instead it "fakes" encountering a reparse point before the create reaches the filesystem. When SimRep detects a create for a path that it is redirecting, SimRep replaces the file name in the file object and completes the open with STATUS\_REPARSE. This means we reparse without actually going to the file system.
|
||||
|
||||
|
|
@ -26,4 +34,3 @@ SimRep decides to reparse according to a mapping. The mapping is made up of a "N
|
|||
It is important to note that SimRep does not take long and short names into account. It literally does a string comparison to detect overlap with the mapping paths. SimRep also handles IRP\_MJ\_NETWORK\_QUERY\_OPEN. Because network query opens are FastIo operations, they cannot be reparsed. This means network query opens which need to be redirected must be failed with FLT\_PREOP\_DISALLOW\_FASTIO. This will cause the Io Manager to reissue the open as a regular IRP based open. To prevent performance regression, SimRep only fails network query opens which need to be reparsed.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: SimRep File System Minifilter Driver
|
||||
description: Demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/simrep/simrep.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: SwapBuffer File System Minifilter Driver
|
||||
description: Demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: SwapBuffer File System Minifilter Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,19 +17,16 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617657
|
||||
--->
|
||||
|
||||
|
||||
SwapBuffer File System Minifilter Driver
|
||||
========================================
|
||||
# SwapBuffer File System Minifilter Driver
|
||||
|
||||
The SwapBuffers minifilter demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters because they have to encrypt data before writing it to disk and decrypt it after reading it from disk. Because encryption/decryption has to be done transparently, you cannot use system-supplied buffers directly, so intermediate buffers have to be introduced.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The *SwapBuffers* minifilter introduces a new buffer before a read/write or directory control operations. The corresponding operation is then performed on the new buffer instead of the buffer that was originally provided. After the operation completes, the contents of the new buffer are copied back in to the original buffer.
|
||||
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540402) section in the Installable File Systems Design Guide.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: SwapBuffer File System Minifilter Driver
|
||||
description: Demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /filesys/miniFilter/swapBuffers/swapBuffers.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: DHCU - Driver package installation toolkit for universal drivers
|
||||
description: Illustrates DCHU principles of universal driver design.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: DHCU - Driver package installation toolkit for universal drivers
|
||||
platform: UMDF2
|
||||
|
|
@ -7,18 +17,17 @@
|
|||
samplefwlink: https://aka.ms/sceeqq
|
||||
--->
|
||||
|
||||
|
||||
# Driver package installation toolkit for universal drivers
|
||||
|
||||
This sample illustrates the DCHU principles of universal driver design. The sample uses the [OSR FX2 learning kit](http://store.osr.com/product/osr-usb-fx2-learning-kit-v2/). For a detailed code walkthrough, see [Universal Driver Scenarios](https://docs.microsoft.com/windows-hardware/drivers/develop/universal-driver-scenarios).
|
||||
|
||||
There are three Visual Studio solutions in this sample. Each one represents a single submission on the [Windows Hardware Dev Center dashboard](https://developer.microsoft.com/windows/hardware/dashboard-sign-in). The solutions are split into the following subdirectories:
|
||||
|
||||
* `osrfx2_DCHU_base` : The driver for the OSR FX2 Learning Kit. This includes the device driver, an upper filter driver for the device (a no-op), a Win32 User Service that controls lights on the device, and a console app that can control the device.
|
||||
* `osrfx2_DCHU_base` : The driver for the OSR FX2 Learning Kit. This includes the device driver, an upper filter driver for the device (a no-op), a Win32 User Service that controls lights on the device, and a console app that can control the device.
|
||||
|
||||
* `osrfx2_DCHU_extension_loose`: An extension INF for the OSR FX2 device. This extension modifies some registry settings originally specified by the base driver (`osrfx2_DCHU_base`) and also uses AddComponent to create a Software Component. There is also a component INF project that would be a separate submission to DevCenter, which runs some simple software. These two projects are loosely coupled, and can be installed in any order on the machine.
|
||||
* `osrfx2_DCHU_extension_loose`: An extension INF for the OSR FX2 device. This extension modifies some registry settings originally specified by the base driver (`osrfx2_DCHU_base`) and also uses AddComponent to create a Software Component. There is also a component INF project that would be a separate submission to DevCenter, which runs some simple software. These two projects are loosely coupled, and can be installed in any order on the machine.
|
||||
|
||||
* `osrfx2_DCHU_extension_tight`: An extension INF for the OSR FX2 device. This extension mimics the behavior of `osrfx2_DCHU_extension_loose`; however, it does so in a tightly coupled manner. Using CopyINF, both the extension and component INF are placed into one driver package (and one submission to DevCenter). Here there is less flexibility with the base/component/extension relationship, but it ensures that the component INF is applied at the same time as the extension.
|
||||
* `osrfx2_DCHU_extension_tight`: An extension INF for the OSR FX2 device. This extension mimics the behavior of `osrfx2_DCHU_extension_loose`; however, it does so in a tightly coupled manner. Using CopyINF, both the extension and component INF are placed into one driver package (and one submission to DevCenter). Here there is less flexibility with the base/component/extension relationship, but it ensures that the component INF is applied at the same time as the extension.
|
||||
|
||||
Both `osrfx2_DCHU_extension_loose` and `osrfx2_DCHU_extension_tight` provide the same functionality, so installing both on the same OSR FX2 device is unnecessary. They are intended to show a different way to use extension and component INF's depending on a project's needs.
|
||||
|
||||
|
|
@ -33,9 +42,8 @@ To install these driver packages, make sure that the target machine is in Test M
|
|||
Then, use `pnputil /i /a <PATHTOINF>` to install each of the desired driver packages. They should
|
||||
be installed in the following order:
|
||||
|
||||
* `osrfx2_DCHU_base`
|
||||
* `osrfx2_DCHU_extension`
|
||||
* `osrfx2_DCHU_component`
|
||||
* `osrfx2_DCHU_base`
|
||||
* `osrfx2_DCHU_extension`
|
||||
* `osrfx2_DCHU_component`
|
||||
|
||||
Technically the order of `osrfx2_DCHU_extension` and `osrfx2_DCHU_component` doesn't matter, but the software within `osrfx2_DCHU_component` will read the registry set by the extension to show that an extension INF's settings are applied *after* the base INF's.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: DHCU - Driver package installation toolkit for universal drivers
|
||||
description: Illustrates DCHU principles of universal driver design.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: PLX9x5x PCI Driver
|
||||
description: Demonstrates how to write a driver for a generic PCI device using Windows Driver Frameworks (WDF).
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: PLX9x5x PCI Driver
|
||||
platform: KMDF
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617719
|
||||
--->
|
||||
|
||||
|
||||
PLX9x5x PCI Driver
|
||||
==================
|
||||
# PLX9x5x PCI Driver
|
||||
|
||||
This sample demonstrates how to write driver for a generic PCI device using Windows Driver Framework. The target hardware for this driver is PLX9656/9653RDK-LITE board. The product kit and the hardware specification are available at <http://www.plxtech.com>.
|
||||
|
||||
|
|
@ -17,17 +25,14 @@ For more information, see [Peripheral Component Interconnect (PCI) Bus Drivers](
|
|||
|
||||
The device is a PCI device with port, memory, interrupt and DMA resources. Device can be stopped and started at run-time and also supports low power states. The driver is capable of doing concurrent read and write operations to the device but it can handle only one read or write request at any time. The following lists the driver framework interfaces demonstrated in this sample:
|
||||
|
||||
- Handling PnP & Power Events
|
||||
- Registering a Device Interface
|
||||
- Hardware resource mapping: Port, Memory & Interrupt
|
||||
- DMA Interfaces
|
||||
- Serialized Default Queue for Write requests
|
||||
- Serialized custom Queue for Read requests
|
||||
- Handling Interrupt & DPC
|
||||
- Handling PnP & Power Events
|
||||
- Registering a Device Interface
|
||||
- Hardware resource mapping: Port, Memory & Interrupt
|
||||
- DMA Interfaces
|
||||
- Serialized Default Queue for Write requests
|
||||
- Serialized custom Queue for Read requests
|
||||
- Handling Interrupt & DPC
|
||||
|
||||
To test the driver, run the PLX.EXE test application.
|
||||
|
||||
This sample driver is a minimal driver meant to demonstrate the usage of the Windows Driver Framework. It is not intended for use in a production environment.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: PLX9x5x PCI Driver
|
||||
description: Demonstrates how to write a driver for a generic PCI device using Windows Driver Frameworks (WDF).
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/PLX9x5x/PLX9x5x.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: System DMA sample
|
||||
description: Demonstrates how a driver could use a system DMA controller to write data to a hardware location using V3 System DMA.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: System DMA sample
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617722
|
||||
--->
|
||||
|
||||
|
||||
System DMA
|
||||
==========
|
||||
# System DMA
|
||||
|
||||
This sample demonstrates the usage of V3 System DMA. It shows how a driver could use a system DMA controller supported by Windows to write data to a hardware location using DMA.
|
||||
|
||||
|
|
@ -17,8 +25,6 @@ The sample consists of a legacy device driver and a Win32 console mode test appl
|
|||
|
||||
**Note** This sample driver is not a PnP driver. This is a minimal driver meant to demonstrate an OS feature. Neither it nor its sample programs are intended for use in a production environment. Rather, they are intended for educational purposes and as a skeleton driver.
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
## Run the sample
|
||||
|
||||
To test this driver, copy the test app, SystemDmaApp.exe, and the driver to the same directory, and run the application. The application will automatically load the driver if it's not already loaded and interact with the driver. When you exit the app, the driver will be stopped, unloaded and removed. Because no system DMA controller exists for Windows which uses the advertised DRQ, the sample driver will not proceed any further than failing to acquire a system DMA adapter.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: System DMA sample
|
||||
description: Demonstrates how a driver could use a system DMA controller to write data to a hardware location using V3 System DMA.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/SystemDma/wdm/SystemDma.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: WinHEC 2017 Lab
|
||||
description: WinHEC 2017 Lab
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: WinHEC 2017 Lab
|
||||
platform: KMDF
|
||||
|
|
@ -9,3 +19,4 @@
|
|||
|
||||
# WinHEC 2017 Lab
|
||||
|
||||
Toaster samples from the WinHEC 2017 Lab: Toaster Driver, PlugInToaster, and Toaster Support App.
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: WinHEC 2017 Lab
|
||||
description: WinHEC 2017 Lab
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Cancel-Safe IRP Queue Sample
|
||||
description: Demonstrates the use of the cancel-safe queue routines.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Cancel-Safe IRP Queue Sample
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617705
|
||||
--->
|
||||
|
||||
|
||||
Cancel-Safe IRP Queue Sample
|
||||
============================
|
||||
# Cancel-Safe IRP Queue Sample
|
||||
|
||||
This sample demonstrates the use of the cancel-safe queue routines [**IoCsqInitialize**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549054), [**IoCsqInsertIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549066), [**IoCsqRemoveIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549070), [**IoCsqRemoveNextIrp**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff549072). These routines were introduced in Windows for queuing IRPs in the driver's internal device queue. By using these routines, driver developers do not have to worry about IRP cancellation race conditions. A common problem with cancellation of IRPs in a driver is synchronization between the cancel lock or the InterlockedExchange in the I/O Manager with the driver's queue lock. The **IoCsq*Xxx*** routines abstract the cancel logic while allowing the driver to implement the queue and associated synchronization.
|
||||
|
||||
|
|
@ -23,13 +31,10 @@ Look in the Startio directory for another version of the sample driver that show
|
|||
|
||||
For more information, see [Cancel-Safe IRP Queues](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540755).
|
||||
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
## Run the sample
|
||||
|
||||
To test this driver, run Testapp.exe, which is a simple Win32 multithreaded console application. The driver will automatically load and start. When you exit the application, the driver will stop and be removed.
|
||||
|
||||
`Usage: testapp <NumberOfThreads>`
|
||||
|
||||
**Note** The `NumberOfThreads` command-line parameter is limited to a maximum of 10 threads; the default value if no parameter is specified is 1. The main thread waits for user input. If you press Q, the application exits gracefully; otherwise, it exits the process abruptly and forces all the threads to be terminated and all pending I/O operations to be canceled. Other threads perform I/O asynchronously in a loop. After every overlapped read, the thread goes into an alertable sleep and wakes as soon as the completion routine runs, which occurs when the driver completes the read IRP. You should run multiple instances of the application to stress test the driver.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Cancel-Safe IRP Queue Sample
|
||||
description: Demonstrates the use of the cancel-safe queue routines.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/cancel/cancel.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: KMDF Echo Sample
|
||||
description: Demonstrates how to use a sequential queue to serialize read and write requests presented to the driver.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: KMDF Echo Sample
|
||||
platform: KMDF
|
||||
|
|
@ -7,24 +17,21 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617706
|
||||
--->
|
||||
|
||||
|
||||
KMDF Echo Sample
|
||||
================
|
||||
# KMDF Echo Sample
|
||||
|
||||
The ECHO (KMDF) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver.
|
||||
|
||||
It also shows how to synchronize execution of these events with other asynchronous events such as request cancellation and DPC.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
## Related technologies
|
||||
|
||||
[Kernel-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544396)
|
||||
|
||||
Code Tour
|
||||
---------
|
||||
## Code Tour
|
||||
|
||||
DriverEntry - Creates a framework driver object.
|
||||
|
||||
|
|
@ -40,8 +47,7 @@ EvtIoRead: Retrieves request memory buffer and copies the data from the buffer c
|
|||
|
||||
Since the queue is a sequential queue, only one request is outstanding in the driver.
|
||||
|
||||
Testing
|
||||
-------
|
||||
## Testing
|
||||
|
||||
**Usage:**
|
||||
|
||||
|
|
@ -51,8 +57,7 @@ Echoapp.exe -Async --- Send 100 reads and writes asynchronously
|
|||
|
||||
Exit the app anytime by pressing Ctrl-C
|
||||
|
||||
File Manifest
|
||||
-------------
|
||||
## File Manifest
|
||||
|
||||
File
|
||||
|
||||
|
|
@ -91,4 +96,3 @@ This file merely redirects to the real makefile that is shared by all the driver
|
|||
Sources
|
||||
|
||||
Generic file that lists source files and all the build options.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: KMDF Echo Sample
|
||||
description: Demonstrates how to use a sequential queue to serialize read and write requests presented to the driver.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/echo/kmdf/kmdfecho.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Echo Sample (UMDF Version 1)
|
||||
description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Echo Sample (UMDF Version 1)
|
||||
platform: UMDF1
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617707
|
||||
--->
|
||||
|
||||
|
||||
Echo Sample (UMDF Version 1)
|
||||
============================
|
||||
# Echo Sample (UMDF Version 1)
|
||||
|
||||
This sample demonstrates how to use User-Mode Driver Framework (UMDF) version 1 to write a driver and demonstrates best practices.
|
||||
|
||||
|
|
@ -17,7 +25,6 @@ It also demonstrates the use of a default Serial Dispatch I/O Queue, its request
|
|||
|
||||
This sample driver is a minimal driver meant to demonstrate the usage of the User-Mode Driver Framework. It is not intended for use in a production environment.
|
||||
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
|
||||
|
|
@ -30,7 +37,7 @@ To test the Echo driver, you can run echoapp.exe which is built from \\echo\\exe
|
|||
|
||||
First install the device as described above. Then run echoapp.exe.
|
||||
|
||||
```
|
||||
```cmd
|
||||
D:\>echoapp /?
|
||||
Usage:
|
||||
Echoapp.exe --- Send single write and read request synchronously
|
||||
|
|
@ -124,4 +131,3 @@ File Manifest
|
|||
|
||||
- This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session.
|
||||
- These GUIDs must remain in sync with the trace control GUIDs defined in internal.h.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Echo Sample (UMDF Version 1)
|
||||
description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/echo/umdf/echo.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Echo Sample (UMDF Version 2)
|
||||
description: Demonstrates how to use UMDF 2 to write a driver and to employ best practices.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Echo Sample (UMDF Version 2)
|
||||
platform: UMDF2
|
||||
|
|
@ -7,14 +17,14 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617708
|
||||
--->
|
||||
|
||||
Echo Sample (UMDF Version 2)
|
||||
============================
|
||||
# Echo Sample (UMDF Version 2)
|
||||
|
||||
The ECHO (UMDF version 2) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver.
|
||||
|
||||
It also shows how to synchronize execution of these events with other asynchronous events such as request cancellation and DPC.
|
||||
|
||||
## Universal Windows Driver Compliant
|
||||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Related technologies
|
||||
|
|
@ -22,7 +32,6 @@ Related technologies
|
|||
|
||||
[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456)
|
||||
|
||||
|
||||
Open the driver solution in Visual Studio
|
||||
-----------------------------------------
|
||||
|
||||
|
|
@ -31,13 +40,12 @@ In Microsoft Visual Studio, open the solution file (umdf2echo.sln). Choose **Sol
|
|||
Set the configuration and platform in Visual Studio
|
||||
---------------------------------------------------
|
||||
|
||||
In Visual Studio, in Solution Explorer, right click **Solution**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes.
|
||||
|
||||
In Visual Studio, in Solution Explorer, right click **Solution**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes.
|
||||
|
||||
Locate the built driver package
|
||||
-------------------------------
|
||||
|
||||
In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform.
|
||||
In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform.
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
|
|
@ -50,16 +58,16 @@ The process of moving the driver package to the target computer and installing t
|
|||
|
||||
Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/).
|
||||
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\ECHO** for the hardware ID. Click **OK**.
|
||||
3. On the **Build** menu, choose **Build Solution**.
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\ECHO** for the hardware ID. Click **OK**.
|
||||
1. On the **Build** menu, choose **Build Solution**.
|
||||
|
||||
### Manual deployment (root enumerated)
|
||||
|
||||
Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571).
|
||||
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2echoPkg).
|
||||
2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\umdf2echoPkg).
|
||||
1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
|
||||
|
||||
**devcon install echoum.inf root\\ECHO**
|
||||
|
||||
|
|
@ -77,4 +85,3 @@ As an alternative to building the driver sample in Visual Studio, you can build
|
|||
**msbuild /p:configuration="Release" /p:platform="Win32" umdf2echo.sln**
|
||||
|
||||
For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Echo Sample (UMDF Version 2)
|
||||
description: Demonstrates how to use UMDF 2 to write a driver and to employ best practices.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/echo/umdf2/umdf2echo.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: UMDF SocketEcho Sample (UMDF Version 1)
|
||||
description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: UMDF SocketEcho Sample (UMDF Version 1)
|
||||
platform: UMDF1
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617709
|
||||
--->
|
||||
|
||||
|
||||
UMDF SocketEcho Sample (UMDF Version 1)
|
||||
=======================================
|
||||
# UMDF SocketEcho Sample (UMDF Version 1)
|
||||
|
||||
The UMDF SocketEcho sample demonstrates how to use the User-Mode Driver Framework (UMDF) to write a driver and demonstrates best practices.
|
||||
|
||||
|
|
@ -38,13 +46,13 @@ To test this sample, you must have a test computer. This test computer can be a
|
|||
|
||||
To install the UMDF Echo sample driver from the command line, do the following:
|
||||
|
||||
1. Copy the driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.)
|
||||
1. Copy the driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.)
|
||||
|
||||
2. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\<architecture\> directory to the same directory (for example, C:\\socketechoSample).
|
||||
1. Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\<architecture\> directory to the same directory (for example, C:\\socketechoSample).
|
||||
|
||||
**Note** You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0.
|
||||
|
||||
3. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows:
|
||||
1. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows:
|
||||
|
||||
`devcon.exe install socketecho.inf WUDF\\socketecho`
|
||||
|
||||
|
|
@ -52,21 +60,21 @@ To install the UMDF Echo sample driver from the command line, do the following:
|
|||
|
||||
To update the socketecho driver after you make any changes, do the following:
|
||||
|
||||
1. Increment the version number in the INF file. This change is not necessary, but it will help ensure that Plug and Play (PnP) selects your new driver as a better match for the device.
|
||||
1. Increment the version number in the INF file. This change is not necessary, but it will help ensure that Plug and Play (PnP) selects your new driver as a better match for the device.
|
||||
|
||||
2. Copy the updated driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.)
|
||||
1. Copy the updated driver binary and the socketecho.inf file to a directory on your test computer (for example, C:\\ socketechoSample.)
|
||||
|
||||
3. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\ socketechoSample), and run devcon.exe as follows:
|
||||
1. Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\ socketechoSample), and run devcon.exe as follows:
|
||||
|
||||
`devcon.exe update socketecho.inf WUDF\\socketecho`
|
||||
|
||||
To test this sample drivers on a checked operating system that you have installed (in contrast to the standard retail installations), you must modify the INF file to use the checked version of the UMDF co-installer. That is, you must do the following:
|
||||
|
||||
1. In the INX file, replace all occurrences of WudfUpdate\_*MMmmmm*.dll with WudfUpdate\_*MMmmmm*\_chk.dll.
|
||||
1. In the INX file, replace all occurrences of WudfUpdate\_*MMmmmm*.dll with WudfUpdate\_*MMmmmm*\_chk.dll.
|
||||
|
||||
2. Copy the WudfUpdate\_*MMmmmm*\_chk.dll file from the \\redist\\wdf\\\<architecture\> directory to your driver package instead of WudfUpdate\_*MMmmmm*.dll.
|
||||
1. Copy the WudfUpdate\_*MMmmmm*\_chk.dll file from the \\redist\\wdf\\\<architecture\> directory to your driver package instead of WudfUpdate\_*MMmmmm*.dll.
|
||||
|
||||
3. If WdfCoinstaller*MMmmmm*.dll or WinUsbCoinstaller.dll is included in your driver package, repeat step 1 and step 2 for them.
|
||||
1. If WdfCoinstaller*MMmmmm*.dll or WinUsbCoinstaller.dll is included in your driver package, repeat step 1 and step 2 for them.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
|
@ -79,7 +87,8 @@ First, you must install the device as described earlier. Then, run socketechoser
|
|||
|
||||
Usage
|
||||
------
|
||||
```
|
||||
|
||||
```cmd
|
||||
socketechoserver Display Usage
|
||||
|
||||
socketechoserver -h Display Usage
|
||||
|
|
@ -167,5 +176,3 @@ File Manifest
|
|||
-------------
|
||||
|
||||
**Dllsup.cpp**: The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: UMDF SocketEcho Sample (UMDF Version 1)
|
||||
description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/echo/umdfSocketEcho/umdfsocketecho.sln
|
||||
|
|
@ -1,4 +1,14 @@
|
|||
<!---
|
||||
---
|
||||
topic: sample
|
||||
name: Hardware Event Sample
|
||||
description: Demonstrates different ways a kernel-mode driver can notify an application about a hardware event.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Hardware Event Sample
|
||||
platform: WDM
|
||||
language: cpp
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617711
|
||||
--->
|
||||
|
||||
|
||||
Hardware Event Sample
|
||||
=====================
|
||||
# Hardware Event Sample
|
||||
|
||||
This sample demonstrates two different ways a Windows kernel-mode driver can notify an application about a hardware event. One way uses an event-based method, and the other uses an IRP-based method. Because the sample driver is not talking to any real hardware, it uses a timer DPC to simulate hardware events. The test application informs the driver whether it wants to be notified by signaling an event or by completing the pending IRP. Additionally, the test application specifies a relative time at which the DPC timer must fire.
|
||||
|
||||
|
|
@ -21,9 +29,7 @@ There are two advantages of IRP-based approach over the event-based approach. Fi
|
|||
|
||||
**Note** This sample driver is not a Plug and Play driver. This is a minimal driver meant to demonstrate a feature of the operating system. Neither this driver nor its sample programs are intended for use in a production environment. Rather, they are intended for educational purposes and as a skeleton driver.
|
||||
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
## Run the sample
|
||||
|
||||
To test this driver, copy the test application, event.exe, and the driver to the same directory, and run the application. The application will automatically load the driver, if it's not already loaded, and interact with the driver. When you exit the app, the driver will be stopped, unloaded, and removed.
|
||||
|
||||
|
|
@ -32,4 +38,3 @@ To run the test application, enter the following command in the command window:
|
|||
`C:\>event.exe <Delay> <0|1>`
|
||||
|
||||
The first command-line parameter, `Delay`, equals the time, in seconds, to delay the event signal. For the second command-line parameter, specify 0 for IRP-based notification and 1 for event-based notification.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Hardware Event Sample
|
||||
description: Demonstrates different ways a kernel-mode driver can notify an application about a hardware event.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/event/eventsample.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: File History Sample
|
||||
description: A console application that starts the file history service, if it is stopped, and schedules regular backups.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: File History Sample
|
||||
platform: WDM
|
||||
|
|
@ -7,17 +17,13 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617712
|
||||
--->
|
||||
|
||||
|
||||
File History Sample
|
||||
==================
|
||||
# File History Sample
|
||||
|
||||
The FileHistory sample is a console application that starts the file history service, if it is stopped, and schedules regular backups. The application requires, as a command-line parameter, the path name of a storage device to use as the default backup target.
|
||||
|
||||
This sample application uses the [File History API](http://msdn.microsoft.com/en-us/library/windows/hardware/hh829789). The File History API enables third parties to automatically configure the File History feature on a Windows platform and customize it in accordance with their unique needs.
|
||||
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
## Run the sample
|
||||
|
||||
The name of the built sample application is Fhsetup.exe. To run this application, open a command window and enter a command that has the following format:
|
||||
|
||||
|
|
@ -30,4 +36,3 @@ The `path` command-line parameter is the path name of a storage device to use as
|
|||
`fhsetup \\server\share`
|
||||
|
||||
If the specified target is inaccessible, read-only, an invalid drive type (such as a CD), already being used for file history, or part of the protected namespace, the application fails the request and does not enable file history on the target.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: File History Sample
|
||||
description: A console application that starts the file history service, if it is stopped, and schedules regular backups.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/filehistory/filehistory.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Non-PnP Driver Sample
|
||||
description: Demonstrates how to write a non-PnP driver using the Kernel Mode Driver Framework.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Non-PnP Driver Sample
|
||||
platform: KMDF
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620307
|
||||
--->
|
||||
|
||||
|
||||
Non-PnP Driver Sample
|
||||
====================
|
||||
# Non-PnP Driver Sample
|
||||
|
||||
This sample is primarily meant to demonstrate how to write a NON-PNP driver using the Kernel Mode Driver Framework.
|
||||
|
||||
|
|
@ -19,25 +27,23 @@ This sample would be useful for writing a driver that does not interact with any
|
|||
|
||||
(Examples: FileMon, Regmon, DeviceTree are examples of tools that use this type of driver.)
|
||||
|
||||
- How to Write a NON PNP driver
|
||||
- How to Write a NON PNP driver
|
||||
|
||||
- How to register EvtPreProcessCallback to handle requests in the context of the calling thread
|
||||
- How to register EvtPreProcessCallback to handle requests in the context of the calling thread
|
||||
|
||||
- Show how to probe and lock buffers in the preprocess callback for METHOD\_NEITHER IOCTL requests
|
||||
- Show how to probe and lock buffers in the preprocess callback for METHOD\_NEITHER IOCTL requests
|
||||
|
||||
- Also show how to handle other 3 types of IOCTLs (METHOD\_BUFFERED, METHOD\_IN\_DIRECT & METHOD\_OUT\_DIRECT)
|
||||
- Also show how to handle other 3 types of IOCTLs (METHOD\_BUFFERED, METHOD\_IN\_DIRECT & METHOD\_OUT\_DIRECT)
|
||||
|
||||
- How to open a file in Kernel-mode and Read & Write to it
|
||||
- How to open a file in Kernel-mode and Read & Write to it
|
||||
|
||||
- Finally show event tracing and dumping variable length data in the tracelog using HEXDUMP format.
|
||||
- Finally show event tracing and dumping variable length data in the tracelog using HEXDUMP format.
|
||||
|
||||
The sample is accompanied by a simple multithreaded Win32 console application to test the driver.
|
||||
|
||||
*Disclaimer*: This is a minimal driver meant to demonstrate an OS feature. Neither it nor its sample programs are intended for use in a production environment. Rather, they are intended for educational purposes and as a skeleton driver.
|
||||
|
||||
|
||||
Build the sample
|
||||
----------------
|
||||
## Build the sample
|
||||
|
||||
For information on how to build a driver solution using Microsoft Visual Studio, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644).
|
||||
|
||||
|
|
@ -70,4 +76,3 @@ KmdfService = \<your driver service name here\>, \<driver service install subsec
|
|||
KmdfLibraryVersion = \<version bound to here, in Major.minor format\>
|
||||
|
||||
For example, for V1.0 KmdfLibraryVersion is "1.0"
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Non-PnP Driver Sample
|
||||
description: Demonstrates how to write a non-PnP driver using the Kernel Mode Driver Framework.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/ioctl/kmdf/ioctl.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: IOCTL
|
||||
description: Demonstrates usage of four different types of IOCTLs.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: IOCTL
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617715
|
||||
--->
|
||||
|
||||
|
||||
IOCTL
|
||||
=====
|
||||
# IOCTL
|
||||
|
||||
This sample demonstrates the usage of four different types of IOCTLs (METHOD\_IN\_DIRECT, METHOD\_OUT\_DIRECT, METHOD\_NEITHER, and METHOD\_BUFFERED).
|
||||
|
||||
|
|
@ -19,9 +27,6 @@ The sample consists of a legacy device driver and a Win32 console test applicati
|
|||
|
||||
**Note** This sample driver is not a Plug and Play driver. This is a minimal driver meant to demonstrate a feature of the operating system. Neither this driver nor its sample programs are intended for use in a production environment. Instead, they are intended for educational purposes and as a skeleton driver.
|
||||
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
# Run the sample
|
||||
|
||||
To test this driver, copy the test app, Ioctlapp.exe, and the driver to the same directory, and run the application. The application will automatically load the driver, if it's not already loaded, and interact with the driver. When you exit the application, the driver will be stopped, unloaded and removed.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: IOCTL
|
||||
description: Demonstrates usage of four different types of IOCTLs
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/ioctl/wdm/ioctl.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: ObCallback Callback Registration Driver
|
||||
description: Demonstrates the use of registered callbacks for process protection.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: ObCallback Callback Registration Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,15 +17,11 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617716
|
||||
--->
|
||||
|
||||
|
||||
ObCallback Callback Registration Driver
|
||||
=======================================
|
||||
# ObCallback Callback Registration Driver
|
||||
|
||||
The ObCallback sample driver demonstrates the use of registered callbacks for process protection. The driver registers control callbacks which are called at process creation.
|
||||
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
The sample exercises both the [**PsSetCreateProcessNotifyRoutineEx**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff559951) and the [**ObRegisterCallbacks**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff558692) routines. The first example uses the **ObRegisterCallbacks** routine and a callback to restrict requested access rights during a open process action. The second example uses the **PsSetCreateProcessNotifyRoutineEx** routine to reject a process creation by examining the command line.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: ObCallback Callback Registration Driver
|
||||
description: Demonstrates the use of registered callbacks for process protection.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/obcallback/obcallback.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: PCIDRV - WDF Driver for PCI Device
|
||||
description: Demonstrates how to write a KMDF driver for a PCI device.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: PCIDRV - WDF Driver for PCI Device
|
||||
platform: KMDF
|
||||
|
|
@ -7,43 +17,39 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617717
|
||||
--->
|
||||
|
||||
|
||||
PCIDRV - WDF Driver for PCI Device
|
||||
==================================
|
||||
# PCIDRV - WDF Driver for PCI Device
|
||||
|
||||
This sample demonstrates how to write a KMDF driver for a PCI device. The sample works with the Intel 82557/82558 based PCI Ethernet Adapter (10/100) and Intel compatibles.
|
||||
|
||||
This adapter supports scatter-gather DMA, wake on external event (Wait-Wake), and idle power down. The hardware specification is publicly available, and the source code to interface with the hardware is included in the WDK.
|
||||
|
||||
|
||||
Overview
|
||||
--------
|
||||
## Overview
|
||||
|
||||
The following is a list of key KMDF interfaces demonstrated in this sample:
|
||||
|
||||
- Handling PnP & Power Events
|
||||
- Handling PnP & Power Events
|
||||
|
||||
- Registering Device Interface
|
||||
- Registering Device Interface
|
||||
|
||||
- Hardware resource mapping: Port, Memory & Interrupt
|
||||
- Hardware resource mapping: Port, Memory & Interrupt
|
||||
|
||||
- DMA Interfaces
|
||||
- DMA Interfaces
|
||||
|
||||
- Parallel default queue for write requests. If the write cannot be satisfied immediately, the request is put into a manual parallel queue.
|
||||
- Parallel default queue for write requests. If the write cannot be satisfied immediately, the request is put into a manual parallel queue.
|
||||
|
||||
- Parallel manual queue for Read requests
|
||||
- Parallel manual queue for Read requests
|
||||
|
||||
- Parallelc default queue for IOCTL requests. If the ioctl cannot be satisfied immediately, the request is put into a manual parallel queue.
|
||||
- Parallelc default queue for IOCTL requests. If the ioctl cannot be satisfied immediately, the request is put into a manual parallel queue.
|
||||
|
||||
- Request cancelation
|
||||
- Request cancelation
|
||||
|
||||
- Handling Interrupt & DPC
|
||||
- Handling Interrupt & DPC
|
||||
|
||||
- Watchdog Timer DPC to monitor the device state.
|
||||
- Watchdog Timer DPC to monitor the device state.
|
||||
|
||||
- Event Tracing & HEXDUMP
|
||||
- Event Tracing & HEXDUMP
|
||||
|
||||
- Reading & Writing to the registry
|
||||
- Reading & Writing to the registry
|
||||
|
||||
Note: This sample provides an example of a minimal driver intended for educational purposes. Neither the driver nor its sample test programs are intended for use in a production environment.
|
||||
|
||||
|
|
@ -65,8 +71,7 @@ Intel(R) PRO/100 VM Network Connection | PCI\VEN_8086&DEV_1031&REV_42
|
|||
Intel(R) PRO/100 VE Network Connection | PCI\VEN_8086&DEV_1038&REV_41
|
||||
Intel(R) PRO/100 SR Mobile Adapter | PCI\VEN_8086&DEV_1229
|
||||
|
||||
Using this sample as a standalone driver
|
||||
----------------------------------------
|
||||
## Using this sample as a standalone driver
|
||||
|
||||
```
|
||||
---------------------
|
||||
|
|
@ -98,8 +103,7 @@ You can install the driver as a standalone driver of a custom setup class, calle
|
|||
|
||||
The PCIDRV sample acts as a power policy owner of the device and implements all the wait-wake and idle detection logic.
|
||||
|
||||
INSTALLATION
|
||||
------------
|
||||
## INSTALLATION
|
||||
|
||||
The driver can be installed as a Net class driver or as a standalone driver (user defined class). The KMDF versions of the INF files are dynamically generated from .INX file. In addition to the driver files, you have to include the WDF coinstaller DLL from the \\redist\\wdf folder of the WDK.
|
||||
|
||||
|
|
@ -109,65 +113,60 @@ You can obtain redistributable framework updates by downloading the *wdfcoinstal
|
|||
|
||||
To test standalone driver configuration: You should use the specially developed ping application, called MYPING that comes with the sample. The Ping.exe provided in the system will not work because in this configuration, the test card is not bound to any network protocol - it's not seen as Net device by the system. Currently the test application doesn't have ability to get an IP address from a network DHCP server. As a result, it is better to connect the network device to a private hub and ping another machine connected to that hub. For example, let us say you have a test machine A and another machine B (development box).
|
||||
|
||||
- Connect machine A and Machine B to a local hub.
|
||||
- Connect machine A and Machine B to a local hub.
|
||||
|
||||
- Assign a static IP address, say 128.0.0.1 to the NIC on machine B.
|
||||
- Assign a static IP address, say 128.0.0.1 to the NIC on machine B.
|
||||
|
||||
- Clear the ARP table on machine B by running **Arp -d** on the command line
|
||||
- Clear the ARP table on machine B by running **Arp -d** on the command line
|
||||
|
||||
- Now run Myping.exe. This application enumerates GUID\_DEVINTERFACE\_PCIDRV and displays the name of the devices with an index number. This number will be used in identifying the interface when you invoke ping dialog.
|
||||
- Now run Myping.exe. This application enumerates GUID\_DEVINTERFACE\_PCIDRV and displays the name of the devices with an index number. This number will be used in identifying the interface when you invoke ping dialog.
|
||||
|
||||
- In the ping dialog specify the following and click okay:
|
||||
- In the ping dialog specify the following and click okay:
|
||||
|
||||
- Device Index: 1 \<- number displayed in the list window
|
||||
- Device Index: 1 \<- number displayed in the list window
|
||||
|
||||
- Source Ip Address: 128.0.0.4 \<- You can make up any valid IP address for test Machine A
|
||||
- Source Ip Address: 128.0.0.4 \<- You can make up any valid IP address for test Machine A
|
||||
|
||||
- Destination IP Address: 128.0.0.1 \<- IP address of machine B
|
||||
- Destination IP Address: 128.0.0.1 \<- IP address of machine B
|
||||
|
||||
- Packet Size: 1428 \<- Default max size of ping payload. Minimum value is 32 bytes.
|
||||
- Packet Size: 1428 \<- Default max size of ping payload. Minimum value is 32 bytes.
|
||||
|
||||
If the machine B has more than one adapter and if the second adapter is connected to the internet (Corporate Network), instead of assigning static IP address to the adapter that's connected to the test machine, you can install Internet Connection Sharing (ICS) on it and get an IP address for ICS. This would let you use the test machine to browse the internet when the sample is installed in the miniport configuration and also in the standalone mode without making up or stealing somebody's IP address. For example, let us say the machine B has two adapters NIC1 and NIC2. NIC1 is connected to the CorpNet and NIC2 is connected to the private hub. Install ICS on NIC2 as described below:
|
||||
|
||||
- Select the NIC2 in the Network Connections Applet.
|
||||
- Select the NIC2 in the Network Connections Applet.
|
||||
|
||||
- Click the **Properties** button.
|
||||
- Click the **Properties** button.
|
||||
|
||||
- Go to the Advanced Tab and Check the box "Allow Other network users to connect through this computers internet connection" in the Internet Connection Sharing choice.
|
||||
- Go to the Advanced Tab and Check the box "Allow Other network users to connect through this computers internet connection" in the Internet Connection Sharing choice.
|
||||
|
||||
- This will assign 192.168.0.1 IP address to NIC2.
|
||||
- This will assign 192.168.0.1 IP address to NIC2.
|
||||
|
||||
- Now on machine B, you can assume 192.168.0.2 as the local IP address and run Myping.exe . Or, you can install the sample in the miniport configuration and browse the internet.
|
||||
- Now on machine B, you can assume 192.168.0.2 as the local IP address and run Myping.exe . Or, you can install the sample in the miniport configuration and browse the internet.
|
||||
|
||||
Other menu options of myping applications are:
|
||||
|
||||
- Reenumerate All Device: This command lets you terminate active ping threads and close handle to all the device and reenumerate the devices again and display their names with index numbers. This might cause the devices to have new index numbers.
|
||||
- Reenumerate All Device: This command lets you terminate active ping threads and close handle to all the device and reenumerate the devices again and display their names with index numbers. This might cause the devices to have new index numbers.
|
||||
|
||||
- Cleanup: This command terminates ping threads and closes handles to all the devices.
|
||||
- Cleanup: This command terminates ping threads and closes handles to all the devices.
|
||||
|
||||
- Clear Display: Clears the window.
|
||||
- Clear Display: Clears the window.
|
||||
|
||||
- Verbose: Let you get more debug messages.
|
||||
- Verbose: Let you get more debug messages.
|
||||
|
||||
- Exit: Terminate the application.
|
||||
- Exit: Terminate the application.
|
||||
|
||||
**Note** You can use this application only on a device installed in the standalone configuration. If you run it on a device that's installed as a miniport, you will get an error message. For such devices, you can use the system provided ping.exe.
|
||||
|
||||
RESOURCES
|
||||
---------
|
||||
## RESOURCES
|
||||
|
||||
For the latest release of the Windows Driver Kit, see http://www.microsoft.com/whdc/.
|
||||
For the latest release of the Windows Driver Kit, see [Download the Windows Driver Kit (WDK)](https://docs.microsoft.com/windows-hardware/drivers/download-the-wdk).
|
||||
|
||||
If you have questions on using or adapting this sample for your project, you can either contact Microsoft Technical Support or post your questions in the Microsoft driver development newsgroup.
|
||||
|
||||
FILE MANIFEST
|
||||
-------------
|
||||
## FILE MANIFEST
|
||||
|
||||
File | Description
|
||||
-----|------------
|
||||
KMDF | Contains the driver.
|
||||
KMDF\HW | Contains hardware specific code.
|
||||
TEST | Contains source of test application (MYPING).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: PCIDRV - WDF Driver for PCI Device
|
||||
description: Demonstrates how to write a KMDF driver for a PCI device.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/pcidrv/pcidrv.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Kernel Counter Sample (Kcs)
|
||||
description: Demonstrates the use of the kernel-mode performance library.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Kernel Counter Sample (Kcs)
|
||||
platform: WDM
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617718
|
||||
--->
|
||||
|
||||
|
||||
Kernel Counter Sample (Kcs)
|
||||
===========================
|
||||
# Kernel Counter Sample (Kcs)
|
||||
|
||||
The Kcs sample driver demonstrates the use of the [kernel-mode performance library](http://msdn.microsoft.com/en-us/library/windows/hardware/ff548159). The sample driver does not control any hardware; it simply provides example code that demonstrates how to provide counter data from a kernel-mode driver. The code contains comments to explain what each function does. The sample creates geometric wave and trigonometric wave counter sets.
|
||||
|
||||
|
|
@ -18,6 +26,3 @@ This module contains sample code to demonstrate how to provide counter data from
|
|||
This sample driver should not be used in a production environment.
|
||||
|
||||
The Microsoft Windows operating system allows system components and third parties to expose performance metrics in a standard way by using [Performance Counters](http://msdn.microsoft.com/en-us/library/windows/hardware/aa373083). Kernel-mode PCW providers are installed in the system as Performance Counter Library (PERFLIB) (Version 2 providers), which allows their counters to be browsed, and allows for data collection and instance enumeration. Consumers can query KM PCW providers by using PDH and PERFLIB Version 1 without any modification to the consumer code.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Kernel Counter Sample (Kcs)
|
||||
description: Demonstrates the use of the kernel-mode performance library.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/perfcounters/kcs/kcs.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: RegFltr Sample Driver
|
||||
description: Demonstrates how to write a registry filter driver.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: RegFltr Sample Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,25 +17,22 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617720
|
||||
--->
|
||||
|
||||
|
||||
RegFltr Sample Driver
|
||||
=====================
|
||||
# RegFltr Sample Driver
|
||||
|
||||
The RegFltr sample shows how to write a [registry filter driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545879).In addition to providing some basic examples, this sample demonstrates the following:
|
||||
|
||||
- How to handle transactional registry operations.
|
||||
- How and when to capture input parameters.
|
||||
- Issues and workarounds for version 1.0 of registry filtering.
|
||||
- Changes in version 1.1 of registry filtering.
|
||||
- How to use version 1 of the [**REG\_CREATE\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560920) and [**REG\_OPEN\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560957) data structures.
|
||||
- How to handle transactional registry operations.
|
||||
- How and when to capture input parameters.
|
||||
- Issues and workarounds for version 1.0 of registry filtering.
|
||||
- Changes in version 1.1 of registry filtering.
|
||||
- How to use version 1 of the [**REG\_CREATE\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560920) and [**REG\_OPEN\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560957) data structures.
|
||||
|
||||
The RegFltr sample contains several examples of user-mode and kernel-mode registry-filtering operations. Each example comes with its own corresponding registry callback routine, and performs the following steps:
|
||||
|
||||
1. Does some setup work.
|
||||
2. Registers the callback routine.
|
||||
3. Performs one or more registry operations.
|
||||
4. Unregisters the callback routine.
|
||||
5. Verifies that the sample completed correctly.
|
||||
1. Does some setup work.
|
||||
1. Registers the callback routine.
|
||||
1. Performs one or more registry operations.
|
||||
1. Unregisters the callback routine.
|
||||
1. Verifies that the sample completed correctly.
|
||||
|
||||
The sample driver is a minimal driver that is not intended to be used on production systems. To keep the samples simple, the registry callback routines provided do not check for all possible situations and error conditions. This sample is designed to demonstrate typical scenarios and no other registry filtering driver is expected to be active.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: RegFltr Sample Driver
|
||||
description: Demonstrates how to write a registry filter driver.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/registry/regfltr/regfltr.sln
|
||||
|
|
@ -106,7 +106,7 @@ Return Value:
|
|||
// CallbackCtx.
|
||||
//
|
||||
|
||||
if (Argument2 == NULL) {
|
||||
if (Argument2 == NULL) {
|
||||
|
||||
//
|
||||
// This should never happen but the sal annotation on the callback
|
||||
|
|
|
|||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Toaster Sample Driver
|
||||
description: An iterative series of samples that demonstrate KDMF and UDMF1 driver development.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Toaster Sample Driver
|
||||
platform: KMDF UMDF1
|
||||
|
|
@ -7,24 +17,22 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620309
|
||||
--->
|
||||
|
||||
# Toaster Sample Driver
|
||||
|
||||
Toaster Sample Driver
|
||||
=====================
|
||||
The Toaster collection is an iterative series of samples that demonstrate fundamental aspects of Windows driver development for both Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) version 1.
|
||||
|
||||
All the samples work with a hypothetical toaster bus, over which toaster devices can be connected to a PC.
|
||||
|
||||
The Toaster sample collection comprises driver projects (.vcxproj files) that are contained in the toaster.sln solution file (in general\\toaster\\toastdrv).
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
## Related technologies
|
||||
|
||||
[Windows Driver Frameworks](http://msdn.microsoft.com/en-us/library/windows/hardware/ff557565)
|
||||
|
||||
For detailed descriptions and code walkthroughs of each project, see [Sample Toaster Driver Programming Tour](http://msdn.microsoft.com/en-us/library/windows/hardware/dn569312). To learn how to build and run the samples, read on.
|
||||
|
||||
## Run the sample
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*.
|
||||
|
||||
The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy components of the Toaster Sample automatically or manually. Here, we install the wdfsimple driver on the target computer.
|
||||
|
|
@ -33,25 +41,25 @@ The process of moving the driver package to the target computer and installing t
|
|||
|
||||
Before doing this, you should back up your package.vcxproj file, located in your sample directory, for example C:\\Toaster\\C++\\Package.
|
||||
|
||||
1. In the Properties for the package project, navigate to **Common Properties \> References**.
|
||||
2. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.)
|
||||
1. In the Properties for the package project, navigate to **Common Properties \> References**.
|
||||
1. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.)
|
||||
|
||||
### Automatic deployment (root enumerated)
|
||||
|
||||
Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/).
|
||||
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**.
|
||||
3. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**.
|
||||
4. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references).
|
||||
5. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment.
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**.
|
||||
1. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**.
|
||||
1. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references).
|
||||
1. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment.
|
||||
|
||||
### Manual deployment (root enumerated)
|
||||
|
||||
Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571).
|
||||
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage).
|
||||
2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage).
|
||||
1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
|
||||
|
||||
**devcon install WdfSimple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster**
|
||||
|
||||
|
|
@ -61,8 +69,7 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De
|
|||
|
||||
In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Microsoft WDF Simple Toaster (No Class Installer)** as a child of the root node of the device tree.
|
||||
|
||||
Build the sample using MSBuild
|
||||
------------------------------
|
||||
## Build the sample using MSBuild
|
||||
|
||||
As an alternative to building the Toaster sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Toaster.sln. Use the MSBuild command to build the solution. Here are some examples:
|
||||
|
||||
|
|
@ -72,8 +79,8 @@ As an alternative to building the Toaster sample in Visual Studio, you can build
|
|||
|
||||
For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644).
|
||||
|
||||
UMDF Toaster File Manifest
|
||||
--------------------------
|
||||
## UMDF Toaster File Manifest
|
||||
|
||||
#### WUDFToaster.idl
|
||||
Component Interface file
|
||||
|
||||
|
|
@ -105,8 +112,8 @@ Sample INF for installing the sample WUDF Toaster driver under the Toaster class
|
|||
This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session.
|
||||
These GUIDs must remain in sync with the trace control guids defined in internal.h.
|
||||
|
||||
Toastmon File Manifest
|
||||
----------------------
|
||||
## Toastmon File Manifest
|
||||
|
||||
#### comsup.cpp & comsup.h
|
||||
Boilerplate COM Support code - specifically base classes which provide implementations for the standard COM interfaces IUnknown and IClassFactory which are used throughout the sample.
|
||||
The implementation of IClassFactory is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file.
|
||||
|
|
@ -141,4 +148,3 @@ This file defines resource information for the ToastMon sample driver.
|
|||
|
||||
#### UMDFToastMon.inf
|
||||
Sample INF for installing the Skeleton driver to control a root enumerated device with a hardware ID of UMDFSamples\\ToastMon
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Toaster Sample Driver
|
||||
description: An iterative series of samples that demonstrate KDMF and UDMF1 driver development.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/toaster/toastDrv/toaster.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Toaster Package Sample Driver
|
||||
description: Simulates hardware-first and software-first installation of the toaster sample driver.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Toaster Package Sample Driver
|
||||
platform: WDM
|
||||
|
|
@ -7,24 +17,22 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617723
|
||||
--->
|
||||
|
||||
# Toaster Package Sample Driver
|
||||
|
||||
Toaster Package Sample Driver
|
||||
=============================
|
||||
The Toaster collection is an iterative series of samples that demonstrate fundamental aspects of Windows driver development for both Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) version 1.
|
||||
|
||||
All the samples work with a hypothetical toaster bus, over which toaster devices can be connected to a PC.
|
||||
|
||||
The Toaster sample collection comprises driver projects (.vcxproj files) that are contained in the toaster.sln solution file (in general\\toaster\\toastdrv).
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
## Related technologies
|
||||
|
||||
[Windows Driver Frameworks](http://msdn.microsoft.com/en-us/library/windows/hardware/ff557565)
|
||||
|
||||
For detailed descriptions and code walkthroughs of each project, see [Sample Toaster Driver Programming Tour](http://msdn.microsoft.com/en-us/library/windows/hardware/dn569312). To learn how to build and run the samples, read on.
|
||||
|
||||
## Run the sample
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*.
|
||||
|
||||
The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy components of the Toaster Sample automatically or manually. Here, we install the wdfsimple driver on the target computer.
|
||||
|
|
@ -33,25 +41,25 @@ The process of moving the driver package to the target computer and installing t
|
|||
|
||||
Before doing this, you should back up your package.vcxproj file, located in your sample directory, for example C:\\Toaster\\C++\\Package.
|
||||
|
||||
1. In the Properties for the package project, navigate to **Common Properties \> References**.
|
||||
2. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.)
|
||||
1. In the Properties for the package project, navigate to **Common Properties \> References**.
|
||||
1. Remove all references except WdfSimple. (Use the **Remove Reference** button at the bottom.)
|
||||
|
||||
### Automatic deployment (root enumerated)
|
||||
|
||||
Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/).
|
||||
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**.
|
||||
3. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**.
|
||||
4. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references).
|
||||
5. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment.
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click the **package** project (within the package folder), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, use the drop down to select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **{b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster** for the hardware ID. (You can find this value in the WdfSimple.inx file.) Click **Apply** and **OK**.
|
||||
1. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**.
|
||||
1. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references).
|
||||
1. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment.
|
||||
|
||||
### Manual deployment (root enumerated)
|
||||
|
||||
Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571).
|
||||
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage).
|
||||
2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\WdfSimplePackage).
|
||||
1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter the following command:
|
||||
|
||||
**devcon install WdfSimple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171}\\MsToaster**
|
||||
|
||||
|
|
@ -61,8 +69,7 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De
|
|||
|
||||
In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Microsoft WDF Simple Toaster (No Class Installer)** as a child of the root node of the device tree.
|
||||
|
||||
Build the sample using MSBuild
|
||||
------------------------------
|
||||
## Build the sample using MSBuild
|
||||
|
||||
As an alternative to building the Toaster sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Toaster.sln. Use the MSBuild command to build the solution. Here are some examples:
|
||||
|
||||
|
|
@ -72,8 +79,8 @@ As an alternative to building the Toaster sample in Visual Studio, you can build
|
|||
|
||||
For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644).
|
||||
|
||||
UMDF Toaster File Manifest
|
||||
--------------------------
|
||||
## UMDF Toaster File Manifest
|
||||
|
||||
#### WUDFToaster.idl
|
||||
Component Interface file
|
||||
|
||||
|
|
@ -105,8 +112,8 @@ Sample INF for installing the sample WUDF Toaster driver under the Toaster class
|
|||
This file lists the WPP trace control GUID(s) for the sample driver. This file can be used with the tracelog command's -guid flag to enable the collection of these trace events within an established trace session.
|
||||
These GUIDs must remain in sync with the trace control guids defined in internal.h.
|
||||
|
||||
Toastmon File Manifest
|
||||
----------------------
|
||||
## Toastmon File Manifest
|
||||
|
||||
#### comsup.cpp & comsup.h
|
||||
Boilerplate COM Support code - specifically base classes which provide implementations for the standard COM interfaces IUnknown and IClassFactory which are used throughout the sample.
|
||||
The implementation of IClassFactory is designed to create instances of the CMyDriver class. If you should change the name of your base driver class, you would also need to modify this file.
|
||||
|
|
@ -141,4 +148,3 @@ This file defines resource information for the ToastMon sample driver.
|
|||
|
||||
#### UMDFToastMon.inf
|
||||
Sample INF for installing the Skeleton driver to control a root enumerated device with a hardware ID of UMDFSamples\\ToastMon
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Toaster Package Sample Driver
|
||||
description: Simulates hardware-first and software-first installation of the toaster sample driver.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/toaster/toastpkg/toastpkg.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Toaster Sample (UMDF version 2)
|
||||
description: An iterative series of samples that demonstrate driver development using UMDF version 2.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Toaster Sample (UMDF version 2)
|
||||
platform: UMDF2
|
||||
|
|
@ -7,21 +17,18 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620310
|
||||
--->
|
||||
|
||||
# Toaster Sample (UMDF Version 2)
|
||||
|
||||
Toaster Sample (UMDF Version 2)
|
||||
===============================
|
||||
The Toaster (UMDF version 2) sample is an iterative series of samples that demonstrate fundamental aspects of Windows driver development.
|
||||
|
||||
The Toaster sample collection is comprised of driver projects (.vcxproj files) that are contained in the umdf2toaster.sln solution file.
|
||||
|
||||
## Related technologies
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456)
|
||||
|
||||
## Run the sample
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
The computer where you install the driver is called the *target computer* or the *test computer*. Typically this is a separate computer from where you develop and build the driver package. The computer where you develop and build the driver is called the *host computer*.
|
||||
|
||||
The process of moving the driver package to the target computer and installing the driver is called *deploying the driver*. You can deploy a driver sample automatically or manually.
|
||||
|
|
@ -30,18 +37,18 @@ The process of moving the driver package to the target computer and installing t
|
|||
|
||||
Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Configuring a Computer for Driver Deployment, Testing, and Debugging](http://msdn.microsoft.com/en-us/library/windows/hardware/).
|
||||
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
2. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\toaster** for the hardware ID. Click **OK**.
|
||||
3. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**.
|
||||
4. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references).
|
||||
5. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment.
|
||||
1. On the host computer, in Visual Studio, in Solution Explorer, right click **package** (lower case), and choose **Properties**. Navigate to **Configuration Properties \> Driver Install \> Deployment**.
|
||||
1. Check **Enable deployment**, and check **Remove previous driver versions before deployment**. For **Target Computer Name**, select the name of a target computer that you provisioned previously. Select **Hardware ID Driver Update**, and enter **root\\toaster** for the hardware ID. Click **OK**.
|
||||
1. Because this solution contains many projects, you may find it easier to remove some of them before you build and deploy a driver package. To do so, right click **package** (lower case), and choose **Properties**. Navigate to **Common Properties-\>References** and click **Remove Reference** to remove projects you don't want. (You can add them back later by using **Add New Reference**.) Click **OK**.
|
||||
1. On the **Build** menu, choose **Build Solution** or **Rebuild Solution** (if you removed references).
|
||||
1. If you removed references and deployment does not succeed, try deleting the contents of the c:\\DriverTest\\Drivers folder on the target machine, and then retry deployment.
|
||||
|
||||
### Manual deployment (root enumerated)
|
||||
|
||||
Before you manually deploy a driver, you must turn on test signing and install a certificate on the target computer. You also need to copy the [DevCon](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544707) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265571).
|
||||
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\Umdf2toaster).
|
||||
2. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter a command such as:
|
||||
1. Copy all of the files in your driver package to a folder on the target computer (for example, c:\\Umdf2toaster).
|
||||
1. On the target computer, open a Command Prompt window as Administrator. Navigate to your driver package folder, and enter a command such as:
|
||||
|
||||
**devcon install wdfsimpleum.inf root\\toaster**
|
||||
|
||||
|
|
@ -51,11 +58,10 @@ On the target computer, in a Command Prompt window, enter **devmgmt** to open De
|
|||
|
||||
In Device Manager, on the **View** menu, choose **Devices by connection**. Locate **Sample WDF Toaster Service + Filter** as a child of the root node of the device tree.
|
||||
|
||||
Build the sample using MSBuild
|
||||
------------------------------
|
||||
## Build the sample using MSBuild
|
||||
|
||||
As an alternative to building the driver sample in Visual Studio, you can build it in a Visual Studio Command Prompt window. In Visual Studio, on the **Tools** menu, choose **Visual Studio Command Prompt**. In the Visual Studio Command Prompt window, navigate to the folder that has the solution file, Umdf2toaster.sln. Use the MSBuild command to build the solution. Here is an example:
|
||||
|
||||
**msbuild /p:configuration="Release" /p:platform="Win32" Umdf2toaster.sln**
|
||||
|
||||
For more information about using MSBuild to build a driver package, see [Building a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Toaster Sample (UMDF version 2)
|
||||
description: An iterative series of samples that demonstrate driver development using UMDF version 2.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/toaster/umdf2/umdf2toaster.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: System Trace Control
|
||||
description: Demonstrates how to use event tracing control APIs to collect events from the system trace provider.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: System Trace Control
|
||||
platform: Application
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617725
|
||||
--->
|
||||
|
||||
|
||||
SystemTraceProvider
|
||||
===================
|
||||
# SystemTraceProvider
|
||||
|
||||
This sample application demonstrates how to use event tracing control APIs to collect events from the system trace provider.
|
||||
|
||||
|
|
@ -18,4 +26,3 @@ The sample code provided shows how to start an [Event Tracing](http://msdn.micro
|
|||
You can process the Systemtrace.etl file using Tracerpt.exe, a command-line trace tool included in Windows that formats trace events. It also analyzes the events and generates summary reports. For more information about how to use this tool, see [Tracerpt](http://go.microsoft.com/fwlink/p/?linkid=179389) topic on the TechNet website.
|
||||
|
||||
You can also process the file using the [Windows Performance Toolkit](http://go.microsoft.com/fwlink/p/?linkid=250774) (WPT), which is available in the SDK.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: System Trace Control
|
||||
description: Demonstrates how to use event tracing control APIs to collect events from the system trace provider.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/tracing/SystemTraceControl/SystemTraceControl.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Eventdrv
|
||||
description: Demonstrates the use of the Event Tracing for Windows (ETW) API in a driver.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Eventdrv
|
||||
platform: Application
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617724
|
||||
--->
|
||||
|
||||
|
||||
Eventdrv
|
||||
========
|
||||
# Eventdrv
|
||||
|
||||
Eventdrv is a sample kernel-mode trace provider and driver. The driver does not control any hardware; it simply generates trace events. It is designed to demonstrate the use of the [Event Tracing for Windows (ETW)](http://msdn.microsoft.com/en-us/library/windows/hardware/ff545699) API in a driver.
|
||||
|
||||
|
|
@ -17,41 +25,39 @@ Evntdrv registers as a provider by calling the [**EtwRegister**](http://msdn.mic
|
|||
|
||||
**Note** The Windows Pre-Processor (WPP) Tracing tools such as TraceView.exe cannot be used to start, stop, or view traces.
|
||||
|
||||
## Run the sample
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
|
||||
1. Install the manifest (Evntdrv.xml), which is located in the Evntdrv\\Eventdrv folder. Open a Visual Studio Command window (Run as administrator) and use the following command:
|
||||
1. Install the manifest (Evntdrv.xml), which is located in the Evntdrv\\Eventdrv folder. Open a Visual Studio Command window (Run as administrator) and use the following command:
|
||||
|
||||
```
|
||||
wevtutil im evntdrv.xml
|
||||
```
|
||||
|
||||
Installing the manifest creates registry keys that enable tools to find the resource and message files that contain event provider information. For further details about the WevtUtil.exe tool, see the MSDN Library.
|
||||
|
||||
|
||||
**Note** Using a Visual Studio Command windows sets up the environment variables you need to run the tracing tools for this sample.
|
||||
|
||||
2. Make a folder in the system directory called ETWDriverSample (for example, C:\\ETWDriverSample).
|
||||
1. Make a folder in the system directory called ETWDriverSample (for example, C:\\ETWDriverSample).
|
||||
|
||||
Copy Eventdrv.sys and Evntctrl.exe to the ETWDriverSample folder.
|
||||
|
||||
The ETWDriverSample directory must be created because the path to the resource file that is specified in the evntdrv.xml manifest points to the %SystemRoot%\\ETWDriverSample folder. If this folder is not created and the Eventdrv.sys binary is not copied, decoding tools cannot find the event information to decode the trace file.
|
||||
|
||||
3. Use Tracelog to start a trace session that is called "TestEventdrv." The following command starts the trace session and creates a trace log file, Eventdrv.etl, in the local directory.
|
||||
1. Use Tracelog to start a trace session that is called "TestEventdrv." The following command starts the trace session and creates a trace log file, Eventdrv.etl, in the local directory.
|
||||
|
||||
```
|
||||
Tracelog -start TestEventdrv -guid #b5a0bda9-50fe-4d0e-a83d-bae3f58c94d6 -f Eventdrv.etl
|
||||
```
|
||||
|
||||
4. To generate trace messages, run Evntctrl.exe. Each time you type a character other than **Q** or **q**, Evntctrl sends an IOCTL to the driver that signals it to generate trace messages. To stop Evntctrl, type **Q** or **q**.
|
||||
1. To generate trace messages, run Evntctrl.exe. Each time you type a character other than **Q** or **q**, Evntctrl sends an IOCTL to the driver that signals it to generate trace messages. To stop Evntctrl, type **Q** or **q**.
|
||||
|
||||
5. To stop the trace session, run the following command:
|
||||
1. To stop the trace session, run the following command:
|
||||
|
||||
```
|
||||
tracelog -stop TestEventdrv
|
||||
```
|
||||
|
||||
6. To display the traces collected in the Tracedrv.etl file, run the following command:
|
||||
1. To display the traces collected in the Tracedrv.etl file, run the following command:
|
||||
|
||||
```
|
||||
tracerpt Eventdrv.etl
|
||||
|
|
@ -59,14 +65,12 @@ Run the sample
|
|||
|
||||
This command creates two files: Summary.txt and Dumpfile.xml. Dumpfile.xml will contain the event information in an XML format.
|
||||
|
||||
7. To uninstall the manifest, run the following command:
|
||||
1. To uninstall the manifest, run the following command:
|
||||
|
||||
```
|
||||
wevtutil um evntdrv.xml
|
||||
```
|
||||
|
||||
Notes
|
||||
-----
|
||||
## Notes
|
||||
|
||||
If you are building the Eventdrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Eventdrv
|
||||
description: Demonstrates the use of the Event Tracing for Windows (ETW) API in a driver.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/tracing/evntdrv/eventdrv.sln
|
||||
|
|
@ -1,3 +1,13 @@
|
|||
---
|
||||
topic: sample
|
||||
name: Tracedrv
|
||||
description: A sample driver instrumented for software tracing.
|
||||
languages:
|
||||
- cpp
|
||||
products:
|
||||
- windows
|
||||
---
|
||||
|
||||
<!---
|
||||
name: Tracedrv
|
||||
platform: Application
|
||||
|
|
@ -7,9 +17,7 @@
|
|||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617726
|
||||
--->
|
||||
|
||||
|
||||
Tracedrv
|
||||
========
|
||||
# Tracedrv
|
||||
|
||||
Tracedrv is a sample driver instrumented for software tracing. The driver does not control any hardware; it simply generates trace messages. It is designed to show how to use WPP software tracing macros in a driver.
|
||||
|
||||
|
|
@ -17,23 +25,22 @@ Tracedrv initializes tracing (by using WPP\_INIT\_TRACING) and, when it receives
|
|||
|
||||
While examining Tracedrv, read the [WPP Software Tracing](http://msdn.microsoft.com/en-us/library/windows/hardware/ff556204) in the Windows Driver Kit (WDK). This section includes a reference section that describes the directives, macros, and calls required for WPP software tracing.
|
||||
|
||||
Run the sample
|
||||
--------------
|
||||
## Run the sample
|
||||
|
||||
To test the Tracedrv event tracing provider, use the following procedure.
|
||||
|
||||
1. Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracedrv\\*platform*).
|
||||
2. Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command:
|
||||
1. Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracedrv\\*platform*).
|
||||
1. Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command:
|
||||
|
||||
**tracepdb -f tracedrv.pdb**
|
||||
|
||||
3. In the same Tracedrv target build directory, create a control GUID file for Tracedrv by opening a text file, adding the following content, and saving the file as Tracedrv.ctl.
|
||||
1. In the same Tracedrv target build directory, create a control GUID file for Tracedrv by opening a text file, adding the following content, and saving the file as Tracedrv.ctl.
|
||||
|
||||
```txt
|
||||
d58c126f-b309-11d1-969e-0000f875a5bc
|
||||
```
|
||||
|
||||
4. Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory.
|
||||
1. Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory.
|
||||
|
||||
```
|
||||
tracelog -start TestTracedrv -guid tracedrv.ctl -f tracedrv.etl -flag 1
|
||||
|
|
@ -41,14 +48,14 @@ To test the Tracedrv event tracing provider, use the following procedure.
|
|||
|
||||
**Note** Without the -flag parameter, Tracedrv will not generate any trace messages.
|
||||
|
||||
5. To generate trace messages, run Tracectl.exe. This executable file is built when you build the solution. Each time you type a character, other than **Q** or **q**, Tracectl sends an IOCTL to the driver that signals it to generate trace messages. To stop Tracectl, type **Q** or **q**.
|
||||
6. To stop the trace session, use the following Tracelog command.
|
||||
1. To generate trace messages, run Tracectl.exe. This executable file is built when you build the solution. Each time you type a character, other than **Q** or **q**, Tracectl sends an IOCTL to the driver that signals it to generate trace messages. To stop Tracectl, type **Q** or **q**.
|
||||
1. To stop the trace session, use the following Tracelog command.
|
||||
|
||||
```
|
||||
tracelog -stop TestTracedrv
|
||||
```
|
||||
|
||||
7. To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command:
|
||||
1. To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command:
|
||||
|
||||
```
|
||||
tracefmt tracedrv.etl -p . -o Tracedrv.out
|
||||
|
|
@ -56,8 +63,7 @@ To test the Tracedrv event tracing provider, use the following procedure.
|
|||
|
||||
The resulting Tracedrv.out file is a human-readable text file of the Tracedrv trace messages. To interpret the trace messages, in the Tracedrv.c file, search for the [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918) macros.
|
||||
|
||||
Notes
|
||||
-----
|
||||
## Notes
|
||||
|
||||
This sample driver should not be used in a production environment.
|
||||
|
||||
|
|
@ -66,4 +72,3 @@ Also, because it is not a Plug and Play driver, Tracedrv does not demonstrate tr
|
|||
Tracedrv demonstrates the basic elements required for software tracing. It does not demonstrate more advanced tracing techniques, such as writing customized tracing calls (variations of [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918)), or the use of WMI calls for software tracing.
|
||||
|
||||
If you are building the Tracedrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202).
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +0,0 @@
|
|||
### YamlMime:Sample
|
||||
sample:
|
||||
- name: Tracedrv
|
||||
description: A sample driver instrumented for software tracing.
|
||||
generateZip: true
|
||||
preserveParentHierarchy: true
|
||||
author: windows-driver-samples
|
||||
languages:
|
||||
- cpp
|
||||
technologies:
|
||||
- windows
|
||||
vssolution: /general/tracing/tracedriver/tracedrv.sln
|
||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче