Update README.md (#417)
This commit is contained in:
Barry Golden
GitHub
Родитель
db43355fe4
Коммит
f064dfb2d9
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: CDFS File System Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: The CD-ROM file system driver (cdfs) sample is a file system driver for removable media.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617642
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: fastfat File System Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: A file system driver based on the Windows inbox FastFAT file system used as a model for new file systems.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=620305
|
||||
--->
|
||||
|
||||
# fastfat File System Driver
|
||||
|
||||
The *fastfat* sample is file system driver that you can use as a model to write new file systems.
|
||||
|
|
@ -28,8 +18,7 @@ The *fastfat* sample is file system driver that you can use as a model to write
|
|||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Build the sample
|
||||
----------------
|
||||
## Build the sample
|
||||
|
||||
You can build the sample in two ways: using Microsoft Visual Studio or the command line (*MSBuild*).
|
||||
|
||||
|
|
@ -39,27 +28,28 @@ You build a driver the same way you build any project or solution in Visual Stud
|
|||
|
||||
The default Solution build configuration is **Debug** and **Win32**.
|
||||
|
||||
**To select a configuration and build a driver**
|
||||
#### To select a configuration and build a driver
|
||||
|
||||
1. Open the driver project or solution in Visual Studio (find fastfat.sln or fastfat.vcxproj).
|
||||
2. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**.
|
||||
3. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) 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).
|
||||
1. Open the driver project or solution in Visual Studio (find fastfat.sln or fastfat.vcxproj).
|
||||
|
||||
1. Right-click the solution in the **Solutions Explorer** and select **Configuration Manager**.
|
||||
|
||||
1. From the **Configuration Manager**, select the **Active Solution Configuration** (for example, Debug or Release) and the **Active Solution Platform** (for example, Win32) that correspond to the type of build you are interested in.
|
||||
|
||||
1. From the Build menu, click **Build Solution** (Ctrl+Shift+B).
|
||||
|
||||
### Building a Driver Using the Command Line (MSBuild)
|
||||
|
||||
You can build a driver from the command line using the Visual Studio Command Prompt window and the Microsoft Build Engine (MSBuild.exe) Previous versions of the WDK used the Windows Build utility (Build.exe) and provided separate build environment windows for each of the supported build configurations. You can now use the Visual Studio Command Prompt window for all build configurations.
|
||||
|
||||
**To select a configuration and build a driver or an application**
|
||||
#### To select a configuration and build a driver or an application
|
||||
|
||||
1. Open a Visual Studio Command Prompt window at the **Start** screen. 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 the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command:
|
||||
1. Open a Visual Studio Command Prompt window at the **Start** screen. From this window you can use MsBuild.exe to build any Visual Studio project by specifying the project (.VcxProj) or solutions (.Sln) file.
|
||||
|
||||
```bash
|
||||
msbuild /t:clean /t:build .\\fastfat.vcxproj
|
||||
```
|
||||
1. Navigate to the project directory and enter the **MSbuild** command for your target. For example, to perform a clean build of a Visual Studio driver project called *filtername*.vcxproj, navigate to the project directory and enter the following MSBuild command:
|
||||
|
||||
Installation
|
||||
------------
|
||||
`msbuild /t:clean /t:build .\\fastfat.vcxproj`
|
||||
|
||||
## Installation
|
||||
|
||||
No INF file is provided with this sample because the *fastfat* file system driver (fastfat.sys) is already part of the Windows operating system. You can build a private version of this file system and use it as a replacement for the native driver.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: Metadata Manager File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: An example of how to use files for storing metadata that corresponds to minifilters.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617650
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -36,4 +26,4 @@ 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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,15 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
<!---
|
||||
name: NameChanger File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: Grafts a directory from one part of a volume's namespace to another part using a mapping.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617652
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: AvScan File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: This filter is a transaction-aware file scanner that examines data in files.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617644
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: CancelSafe File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: A minifilter demonstrating the use of cancel-safe queues.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617645
|
||||
--->
|
||||
|
||||
# CancelSafe File System Minifilter Driver
|
||||
|
||||
The CancelSafe filter is a sample minifilter that you use if you want to use cancel-safe queues.
|
||||
|
|
@ -26,9 +16,8 @@ The CancelSafe filter is a sample minifilter that you use if you want to use can
|
|||
|
||||
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 *CancelSafe* minifilter initializes a cancel-safe queue when it is attached to a volume. When the minifilter is deployed, it monitors read operations that are passing through the I/O stack. If the read operation is being performed on a file named csqdemo.txt, it is queued onto the cancel-safe queue. Queued operations are completed after a brief pause through a separate worker thread that is running in system context.
|
||||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: CDO File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: An example of using a control device object (CDO) with a minifilter.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617646
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -28,9 +18,8 @@ Although the filter manager infrastructure provides a message interface for comm
|
|||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Design and Operation
|
||||
--------------------
|
||||
## Design and Operation
|
||||
|
||||
When the CDO minifilter is deployed, it creates a CDO object named "FileSystem\\Filters\\CdoSample" in the Microsoft Windows object namespace and enables applications to open it and perform certain operations on it.
|
||||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: Change File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: A transaction-aware filter that monitors file changes in real time.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617647
|
||||
--->
|
||||
|
||||
# Change File System Minifilter Driver
|
||||
|
||||
The Change minifilter is a transaction-aware filter that monitors file changes in real time.
|
||||
|
|
@ -33,4 +23,4 @@ The primary tasks of the filter for tracking a transacted file are the following
|
|||
|
||||
## 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.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: Ctx File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: Demonstrates how to attach contexts to instances, files, streams, and stream handles in your minifilter.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617648
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -30,4 +20,4 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
|
|||
|
||||
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.
|
||||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: Delete File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: Demonstrates how to detect deletions of files or streams.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617649
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -30,6 +20,7 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
|
|||
|
||||
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.
|
||||
|
||||
**Note** Because of the way in which the Windows operating system deletes files, it is not possible for the minifilter to detect in advance that a file or stream will be deleted. The minifilter can only detect operations that may cause a deletion, and then determine if the deletion took place after the operation completes.
|
||||
> [!NOTE]
|
||||
> Because of the way in which the Windows operating system deletes files, it is not possible for the minifilter to detect in advance that a file or stream will be deleted. The minifilter can only detect operations that may cause a deletion, and then determine if the deletion took place after the operation completes.
|
||||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: Minispy File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: A tool to monitor and log any I/O and transaction activity that occurs in the system.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617651
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -32,4 +22,4 @@ Minispy consists of both user-mode and kernel-mode components. The kernel-mode c
|
|||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: NullFilter File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: A minifilter that demonstrates registration with the filter manager.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617653
|
||||
--->
|
||||
|
||||
# NullFilter File System Minifilter Driver
|
||||
|
||||
The NullFilter minifilter is a sample minifilter that shows how to register a minifilter with the filter manager.
|
||||
|
|
@ -30,4 +20,4 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
|
|||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: PassThrough File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: Demonstrates how to specify callback functions for different types of I/O requests.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617654
|
||||
--->
|
||||
|
||||
# PassThrough File System Minifilter Driver
|
||||
|
||||
The PassThrough minifilter demonstrates how to specify callback functions for different types of I/O requests.
|
||||
|
|
@ -30,4 +20,4 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
|
|||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: Scanner File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: A file data scanner example. Typically, anti-virus filters are of this type.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617655
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -32,4 +22,4 @@ The Scanner minifilter comprises both kernel-mode and user-mode components. The
|
|||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: SimRep File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: Demonstrates how a file system filter can simulate file-system like reparse-point behavior to redirect a file open to an alternate path.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617656
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -34,4 +24,4 @@ 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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,16 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
<!---
|
||||
name: SwapBuffer File System Minifilter Driver
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: FileSystem
|
||||
description: Demonstrates how to switch buffers between reads and writes of data. This technique is particularly useful for encryption filters.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617657
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -30,4 +20,4 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
|
|||
|
||||
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.
|
||||
For more information on file system minifilter design, start with the [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers) section in the Installable File Systems Design Guide.
|
||||
|
|
|
|||
|
|
@ -8,32 +8,22 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!---
|
||||
name: DHCU - Driver package installation toolkit for universal drivers
|
||||
platform: UMDF2
|
||||
language: cpp
|
||||
category: General DHCU
|
||||
description: Illustrates DCHU principles of universal driver design.
|
||||
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.
|
||||
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 INFs depending on a project's needs.
|
||||
|
||||
NOTE: osrfx2_DCHU_extension_tight will not currently build on Windows 10 version 1703. You will see an error saying that the directive CopyINF does not work from extension INFs. This has been fixed for the Windows 10 Fall Creators Update.
|
||||
> [!NOTE]
|
||||
> Information the user should notice even if skimmingosrfx2_DCHU_extension_tight will not currently build on Windows 10 version 1703. You will see an error saying that the directive CopyINF does not work from extension INFs. This has been fixed for the Windows 10 Fall Creators Update.
|
||||
|
||||
Each of these solutions can be built with the latest WDK on Visual Studio 2015. Additionally, you can also download a [Universal Windows Platform app (UWP)](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/CustomCapability) that controls the OSR FX2 Learning Kit's device. To learn how to pair a UWP app with a device, see [Hardware access for Universal Windows Platform apps](https://docs.microsoft.com/windows-hardware/drivers/devapps/hardware-access-for-universal-windows-platform-apps)
|
||||
|
||||
|
|
@ -41,11 +31,12 @@ The app and the contents of this sample can coexist, but on Windows 10 version 1
|
|||
|
||||
To install these driver packages, make sure that the target machine is in Test Mode, using `bcdedit /set testsigning on`.
|
||||
|
||||
Then, use `pnputil /i /a <PATHTOINF>` to install each of the desired driver packages. They should
|
||||
be installed in the following order:
|
||||
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`
|
||||
|
||||
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.
|
||||
- `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's INF settings are applied *after* the base INFs.
|
||||
|
|
|
|||
|
|
@ -8,20 +8,9 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!---
|
||||
name: Cancel-Safe IRP Queue Sample
|
||||
platform: WDM
|
||||
language: cpp
|
||||
category: General
|
||||
description: Demonstrates the use of the cancel-safe queue routines.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617705
|
||||
--->
|
||||
|
||||
# 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.
|
||||
This sample demonstrates the use of the cancel-safe queue routines [**IoCsqInitialize**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqinitialize), [**IoCsqInsertIrp**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqinsertirp), [**IoCsqRemoveIrp**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqremoveirp), [**IoCsqRemoveNextIrp**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/wdm/nf-wdm-iocsqremovenextirp). 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.
|
||||
|
||||
The sample is accompanied by a simple multithreaded Win32 console application to stress-test the driver's cancel and cleanup routines.
|
||||
|
||||
|
|
@ -29,9 +18,9 @@ This driver is written for an hypothetical data-acquisition device that requires
|
|||
|
||||
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.
|
||||
|
||||
Look in the Startio directory for another version of the sample driver that shows how to use cancel-safe IRP queues to implement I/O queuing functionality similar to the [**IoStartPacket**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550370) and [**IoStartNextPacket**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff550358) routines. The same test application works with this driver as well.
|
||||
Look in the Startio directory for another version of the sample driver that shows how to use cancel-safe IRP queues to implement I/O queuing functionality similar to the [**IoStartPacket**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-iostartpacket) and [**IoStartNextPacket**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-iostartnextpacket) routines. The same test application works with this driver as well.
|
||||
|
||||
For more information, see [Cancel-Safe IRP Queues](http://msdn.microsoft.com/en-us/library/windows/hardware/ff540755).
|
||||
For more information, see [Cancel-Safe IRP Queues](https://docs.microsoft.com/windows-hardware/drivers/kernel/cancel-safe-irp-queues).
|
||||
|
||||
## Run the sample
|
||||
|
||||
|
|
@ -39,4 +28,5 @@ To test this driver, run Testapp.exe, which is a simple Win32 multithreaded cons
|
|||
|
||||
`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.
|
||||
> [!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.
|
||||
|
|
|
|||
|
|
@ -8,17 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!---
|
||||
name: KMDF Echo Sample
|
||||
platform: KMDF
|
||||
language: cpp
|
||||
category: General WDF
|
||||
description: Demonstrates how to use a sequential queue to serialize read and write requests presented to the driver.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617706
|
||||
--->
|
||||
|
||||
# KMDF Echo Sample
|
||||
|
||||
The ECHO (KMDF) sample demonstrates how to use a sequential queue to serialize read and write requests presented to the driver.
|
||||
|
|
@ -31,7 +20,7 @@ This sample builds a Universal Windows Driver. It uses only APIs and DDIs that a
|
|||
|
||||
## Related technologies
|
||||
|
||||
[Kernel-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544396)
|
||||
[Kernel-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/kernel/)
|
||||
|
||||
## Code Tour
|
||||
|
||||
|
|
@ -53,48 +42,29 @@ Since the queue is a sequential queue, only one request is outstanding in the dr
|
|||
|
||||
**Usage:**
|
||||
|
||||
Echoapp.exe --- Send single write and read request synchronously
|
||||
- Echoapp.exe --- Send single write and read request synchronously
|
||||
|
||||
Echoapp.exe -Async --- Send 100 reads and writes asynchronously
|
||||
- Echoapp.exe -Async --- Send 100 reads and writes asynchronously
|
||||
|
||||
Exit the app anytime by pressing Ctrl-C
|
||||
|
||||
## File Manifest
|
||||
|
||||
File
|
||||
|
||||
Description
|
||||
|
||||
Echo.htm
|
||||
|
||||
Documentation for this sample (this file).
|
||||
|
||||
***(The AutoSync and DriverSync versions of the sample each have their own version of the following files)***
|
||||
> [!NOTE]
|
||||
> The AutoSync and DriverSync versions of the sample each have their own version of the following files:
|
||||
|
||||
Driver.h, Driver.c
|
||||
|
||||
DriverEntry and Events on the Driver Object.
|
||||
- DriverEntry and Events on the Driver Object.
|
||||
|
||||
Device.h, Device.c
|
||||
|
||||
Events on the Device Object.
|
||||
- Events on the Device Object.
|
||||
|
||||
Queue.h, Queue.c
|
||||
|
||||
Contains Events on the I/O Queue Objects.
|
||||
- Contains Events on the I/O Queue Objects.
|
||||
|
||||
Echo.inx
|
||||
|
||||
File that describes the installation of this driver. The build process converts this into an INF file.
|
||||
|
||||
Makefile.inc
|
||||
|
||||
A makefile that defines custom build actions. This includes the conversion of the .INX file into a .INF file
|
||||
|
||||
Makefile
|
||||
|
||||
This file merely redirects to the real makefile that is shared by all the driver components of the Windows NT DDK.
|
||||
|
||||
Sources
|
||||
|
||||
Generic file that lists source files and all the build options.
|
||||
- File that describes the installation of this driver. The build process converts this into an INF file.
|
||||
|
|
|
|||
|
|
@ -8,17 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!---
|
||||
name: Echo Sample (UMDF Version 1)
|
||||
platform: UMDF1
|
||||
language: cpp
|
||||
category: General WDF
|
||||
description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617707
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -27,13 +16,11 @@ 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
|
||||
--------------------
|
||||
## Related technologies
|
||||
|
||||
[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456)
|
||||
[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2)
|
||||
|
||||
Testing
|
||||
-------
|
||||
## Testing
|
||||
|
||||
To test the Echo driver, you can run echoapp.exe which is built from \\echo\\exe.
|
||||
|
||||
|
|
@ -45,14 +32,14 @@ Usage:
|
|||
Echoapp.exe --- Send single write and read request synchronously
|
||||
Echoapp.exe -Async --- Send 100 reads and writes asynchronously
|
||||
Exit the app anytime by pressing Ctrl-C
|
||||
|
||||
|
||||
D:\>echoapp
|
||||
DevicePath: \\?\root#sample#0000#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
|
||||
Opened device successfully
|
||||
512 Pattern Bytes Written successfully
|
||||
512 Pattern Bytes Read successfully
|
||||
Pattern Verified successfully
|
||||
|
||||
|
||||
D:\>echoapp -Async
|
||||
DevicePath: \\?\root#sample#0000#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
|
||||
Opened device successfully
|
||||
|
|
@ -84,52 +71,50 @@ Number of bytes written by request number 11 is 1024
|
|||
|
||||
Note that the reads and writes are performed by independent threads in the echo test application. As a result the order of the output may not exactly match what you see above.
|
||||
|
||||
File Manifest
|
||||
-------------
|
||||
## File Manifest
|
||||
|
||||
**comsup.cpp & comsup.h**
|
||||
comsup.cpp and comsup.h
|
||||
|
||||
- COM Support code - specifically base classes which provide implementations for the standard COM interfaces IUnknown and IClassFactory which are used throughout this 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.
|
||||
|
||||
**dllsup.cpp**
|
||||
dllsup.cpp
|
||||
|
||||
- DLL Support code - provides the DLL's entry point as well as the single required export (DllGetClassObject).
|
||||
|
||||
- These depend on comsup.cpp to perform the necessary class creation.
|
||||
|
||||
**exports.def**
|
||||
exports.def
|
||||
|
||||
- This file lists the functions that the driver DLL exports.
|
||||
|
||||
**internal.h**
|
||||
internal.h
|
||||
|
||||
- This is the main header file for this driver.
|
||||
|
||||
**Driver.cpp and Driver.h**
|
||||
Driver.cpp and Driver.h
|
||||
|
||||
- DriverEntry and events on the driver object.
|
||||
|
||||
**Device.cpp and Device.h**
|
||||
Device.cpp and Device.h
|
||||
|
||||
- The Events on the device object.
|
||||
|
||||
**Queue.cpp and Queue.h**
|
||||
Queue.cpp and Queue.h
|
||||
|
||||
- Contains Events on the I/O Queue Objects.
|
||||
|
||||
**Echo.rc**
|
||||
Echo.rc
|
||||
|
||||
- Resource file for the driver.
|
||||
|
||||
**WUDFEchoDriver.inx**
|
||||
WUDFEchoDriver.inx
|
||||
|
||||
- File that describes the installation of this driver. The build process converts this into an INF file.
|
||||
|
||||
**makefile.inc**
|
||||
|
||||
- A makefile that defines custom build actions. This includes the conversion of the .INX
|
||||
|
||||
**echodriver.ctl**
|
||||
echodriver.ctl
|
||||
|
||||
- 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.
|
||||
|
|
|
|||
|
|
@ -8,17 +8,6 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!---
|
||||
name: Echo Sample (UMDF Version 2)
|
||||
platform: UMDF2
|
||||
language: cpp
|
||||
category: General WDF
|
||||
description: Demonstrates how to use UMDF 2 to write a driver and to employ best practices.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617708
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
|
@ -29,28 +18,25 @@ It also shows how to synchronize execution of these events with other asynchrono
|
|||
|
||||
This sample builds a Universal Windows Driver. It uses only APIs and DDIs that are included in OneCoreUAP.
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
## Related technologies
|
||||
|
||||
[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456)
|
||||
[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2)
|
||||
|
||||
Open the driver solution in Visual Studio
|
||||
-----------------------------------------
|
||||
## Build the sample with Visual Studio
|
||||
|
||||
### Open the driver solution in Visual Studio
|
||||
|
||||
In Microsoft Visual Studio, open the solution file (umdf2echo.sln). Choose **Solution Explorer** from the **View** menu. In Solution Explorer, you can see one solution that contains three projects. There is a driver project (Driver-\>AutoSync-\>echo), an application project (Exe-\>echoapp), and a package project named **package** (lower case).
|
||||
|
||||
Set the configuration and platform in Visual Studio
|
||||
---------------------------------------------------
|
||||
### 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.
|
||||
|
||||
Locate the built driver package
|
||||
-------------------------------
|
||||
### 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.
|
||||
|
||||
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*.
|
||||
|
||||
|
|
@ -58,20 +44,23 @@ The process of moving the driver package to the target computer and installing t
|
|||
|
||||
### 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/).
|
||||
Before you automatically deploy a driver, you must provision the target computer. For instructions, see [Provision a computer for driver deployment and testing](https://docs.microsoft.com/windows-hardware/drivers/gettingstarted/provision-a-target-computer-wdk-8-1).
|
||||
|
||||
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](https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/preparing-a-computer-for-manual-driver-deployment).
|
||||
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](https://docs.microsoft.com/windows-hardware/drivers/devtest/devcon) tool to the target computer. For instructions, see [Preparing a Computer for Manual Driver Deployment](https://docs.microsoft.com/windows-hardware/drivers/develop/preparing-a-computer-for-manual-driver-deployment).
|
||||
|
||||
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**
|
||||
`devcon install echoum.inf root\\ECHO`
|
||||
|
||||
### View the root enumerated driver in Device Manager
|
||||
|
||||
|
|
@ -79,11 +68,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 ECHO Driver** 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, umdf2echo.sln. Use the MSBuild command to build the solution. Here is an example:
|
||||
|
||||
**msbuild /p:configuration="Release" /p:platform="Win32" umdf2echo.sln**
|
||||
`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).
|
||||
For more information about using MSBuild to build a driver package, see [MSBuild primer for WDK developers](https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/msbuild-primer-for-wdk-developers).
|
||||
|
|
|
|||
|
|
@ -8,39 +8,27 @@ products:
|
|||
- windows-wdk
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!---
|
||||
name: UMDF SocketEcho Sample (UMDF Version 1)
|
||||
platform: UMDF1
|
||||
language: cpp
|
||||
category: General WDF
|
||||
description: Demonstrates how to use UMDF version 1 to write a driver and demonstrates best practices.
|
||||
samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617709
|
||||
--->
|
||||
|
||||
# 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.
|
||||
|
||||
This sample also demonstrates how to use a default parallel dispatch I/O queue, use a Microsoft Win32 dispatcher, and handle a socket handle by using a Win32 file I/O target.
|
||||
|
||||
Related technologies
|
||||
--------------------
|
||||
## Related technologies
|
||||
|
||||
[User-Mode Driver Framework](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560456)
|
||||
[User-Mode Driver Framework](https://docs.microsoft.com/windows-hardware/drivers/wdf/getting-started-with-umdf-version-2)
|
||||
|
||||
Code Tour
|
||||
---------
|
||||
## Code Tour
|
||||
|
||||
This sample driver is a minimal driver that is intended to demonstrate how to use UMDF. It is not intended for use in a production environment.
|
||||
|
||||
- **CMyDriver::OnInitialize** in **driver.cpp** is called by the framework when the driver loads. This method initiates use of the Winsock Library.
|
||||
- **CMyDriver::OnInitialize** in **driver.cpp** is called by the framework when the driver loads. This method initiates use of the Winsock Library.
|
||||
|
||||
- **CMyDriver::OnDeviceAdd** in **driver.cpp** is called by the framework to install the driver on a device stack. OnDeviceAdd creates a device callback object, and then calls IWDFDriver::CreateDevice to create an framework device object and to associate the device callback object with the framework device object.
|
||||
|
||||
- **CMyQueue::OnCreateFile** in **queue.cpp** is called by the framework to create a socket connection, create a file i/o target that is associated with the socket handle for this connection, and store the socket handle in the file object context.
|
||||
|
||||
Installation
|
||||
------------
|
||||
## Installation
|
||||
|
||||
In Visual Studio, you can press F5 to build the sample and then deploy it to a target machine. For more information, see [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). Alternatively, you can install the sample from the command line.
|
||||
|
||||
|
|
@ -52,11 +40,12 @@ To install the UMDF Echo sample driver from the command line, do the following:
|
|||
|
||||
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.
|
||||
> [!NOTE]
|
||||
> You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](https://go.microsoft.com/fwlink/p/?LinkID=253170). 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.
|
||||
|
||||
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`
|
||||
`devcon.exe install socketecho.inf WUDF\\socketecho`
|
||||
|
||||
You can find DevCon.exe in the \\tools directory of the WDK (for example, \\tools\\devcon\\i386\\devcon.exe).
|
||||
|
||||
|
|
@ -78,8 +67,7 @@ To test this sample drivers on a checked operating system that you have installe
|
|||
|
||||
1. If WdfCoinstaller*MMmmmm*.dll or WinUsbCoinstaller.dll is included in your driver package, repeat step 1 and step 2 for them.
|
||||
|
||||
Testing
|
||||
-------
|
||||
## Testing
|
||||
|
||||
To test the SocketEcho driver, you can run socketechoserver.exe, which is built from the \\echo\\umdfSocketEcho\\Exe directory, and echoapp.exe, which is built from the Kernel-Mode Driver Framework (KMDF) samples in the \\echo\\kmdf directory.
|
||||
|
||||
|
|
@ -87,94 +75,72 @@ First, you must install the device as described earlier. Then, run socketechoser
|
|||
|
||||
`D:\\\>socketechoserver -h`
|
||||
|
||||
Usage
|
||||
------
|
||||
## Usage
|
||||
|
||||
socketechoserver usage
|
||||
|
||||
```cmd
|
||||
socketechoserver Display Usage
|
||||
|
||||
socketechoserver -h Display Usage
|
||||
D:\>socketechoserver -h
|
||||
|
||||
socketechoserver -p Start the app as server listening on default port
|
||||
|
||||
socketechoserver -p [port\#] Start the app as server listening on this port
|
||||
|
||||
D:\\\>socketechoserver -p
|
||||
D:\>socketechoserver -p
|
||||
|
||||
Listening on socket...
|
||||
```
|
||||
|
||||
In another Command Prompt window, run echoapp.exe.
|
||||
|
||||
D:\\\>echoapp
|
||||
```cmd
|
||||
D:\>echoapp
|
||||
|
||||
DevicePath: \\\\?\\root\#sample\#0000\#{ e5e65b0c-82c8-4689-96d4-f77837971990}
|
||||
|
||||
Opened device successfully
|
||||
|
||||
512 Pattern Bytes Written successfully
|
||||
|
||||
512 Pattern Bytes Read successfully
|
||||
|
||||
Pattern Verified successfully
|
||||
|
||||
D:\\\>echoapp -Async
|
||||
D:\>echoapp -Async
|
||||
|
||||
DevicePath: \\\\?\\root\#sample\#0000\#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
|
||||
DevicePath: \\?\root\#sample\#0000\#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
|
||||
|
||||
Opened device successfully
|
||||
|
||||
Starting AsyncIo
|
||||
|
||||
Number of bytes written by request number 0 is 1024
|
||||
|
||||
Number of bytes read by request number 0 is 1024
|
||||
|
||||
Number of bytes written by request number 1 is 1024
|
||||
Number of bytes read by request number 1 is 1024
|
||||
|
||||
Number of bytes written by request number 2 is 1024
|
||||
|
||||
Number of bytes read by request number 2 is 1024
|
||||
|
||||
Number of bytes written by request number 3 is 1024
|
||||
|
||||
Number of bytes read by request number 3 is 1024
|
||||
|
||||
Number of bytes written by request number 4 is 1024
|
||||
|
||||
Number of bytes read by request number 4 is 1024
|
||||
|
||||
Number of bytes written by request number 5 is 1024
|
||||
|
||||
Number of bytes read by request number 5 is 1024
|
||||
|
||||
Number of bytes written by request number 6 is 1024
|
||||
|
||||
Number of bytes read by request number 6 is 1024
|
||||
|
||||
Number of bytes written by request number 7 is 1024
|
||||
|
||||
Number of bytes read by request number 7 is 1024
|
||||
|
||||
Number of bytes written by request number 8 is 1024
|
||||
|
||||
Number of bytes read by request number 8 is 1024
|
||||
|
||||
Number of bytes written by request number 9 is 1024
|
||||
|
||||
Number of bytes read by request number 9 is 1024
|
||||
|
||||
Number of bytes written by request number 10 is 1024
|
||||
|
||||
Number of bytes read by request number 10 is 1024
|
||||
|
||||
Number of bytes written by request number 11 is 1024
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
Note that independent threads perform the reads and writes in the echo test application. As a result, the order of the output might not exactly match what you see in the preceding output.
|
||||
> [!NOTE]
|
||||
> Independent threads perform the reads and writes in the echo test application. As a result, the order of the output might not exactly match what you see in the preceding output example.
|
||||
|
||||
File Manifest
|
||||
-------------
|
||||
## File Manifest
|
||||
|
||||
**Dllsup.cpp**: The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject).
|
||||
|
|
|
|||
Загрузка…
Ссылка в новой задаче