Update README.md (#407)7914479143791427914179140791397913879137791367913579134

12 files changed, 194 insertions, 188 deletions

diff --git a/avstream/avshws/README.md b/avstream/avshws/README.md
index 4310bf3c..a67f71ca 100644
--- a/avstream/avshws/README.md
+++ b/avstream/avshws/README.md
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: AVStream simulated hardware sample driver (Avshws)
     platform: WDM
@@ -20,76 +19,77 @@ products:
 
 # 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.
+The AVStream simulated hardware sample driver (Avshws) provides a pin-centric [AVStream](http://msdn.microsoft.com/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.
 
 This sample features enhanced parameter validation and overflow detection.
 
-Provision a target computer
----------------------------
+## Provision a target computer
 
 After you've installed the sample on your host computer, run Visual Studio, and from the **File** menu, select **Open**, then **Project/Solution...**, navigate to the directory where you've copied the Avshws sample, then to the C++ folder, and select **avshws.vcxproj** (the VC++ Project).
 
-In the **Solution Explorer** pane in Visual Studio, at the top is **Solution 'avshws'**. Right-click this and select **Configuration Manager**. Follow the instructions in [Building a Driver with the WDK](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554644) to set the platform, operating system, and debug configuration you want to use, and to build the sample. This sample project will automatically sign the driver package.
+In the **Solution Explorer** pane in Visual Studio, at the top is **Solution 'avshws'**. Right-click this and select **Configuration Manager**. Follow the instructions in [Building a Driver with the WDK](http://msdn.microsoft.com/library/windows/hardware/ff554644) to set the platform, operating system, and debug configuration you want to use, and to build the sample. This sample project will automatically sign the driver package.
 
-Provision your target computer using instructions in, for example, [Preparing a Computer for Provisioning](http://msdn.microsoft.com/en-us/library/windows/hardware/dn265573). Ensure that in the **Network and Sharing Center** control panel your target computer has **Network Discovery** and **File and Printer Sharing** enabled.
+Provision your target computer using instructions in, for example, [Preparing a Computer for Provisioning](http://msdn.microsoft.com/library/windows/hardware/dn265573). Ensure that in the **Network and Sharing Center** control panel your target computer has **Network Discovery** and **File and Printer Sharing** enabled.
 
-Deploy the driver to the target computer
-----------------------------------------
+## Deploy the driver to the target computer
 
-Now you can deploy the Avshws driver that you've just built to the target computer, using guidance in [Deploying a Driver to a Test Computer](http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834). Specifically, find the package file under the **Package** folder in the Avshws solution. Right-click **package** and select **Properties**. Under Configuration Properties, click **Driver install** and then **Deployment**. Here you must click the check box for **Enable deployment**, and then click the button to the right of **\<Configure Computer...\>**. In the next dialog you enter the **Target Computer Name** and can let the host computer automatically provision the target computer and set up debugger options.
+Now you can deploy the Avshws driver that you've just built to the target computer, using guidance in [Deploying a Driver to a Test Computer](https://docs.microsoft.com/windows-hardware/drivers/develop/deploying-a-driver-to-a-test-computer). Specifically, find the package file under the **Package** folder in the Avshws solution. Right-click **package** and select **Properties**. Under Configuration Properties, click **Driver install** and then **Deployment**. Here you must click the check box for **Enable deployment**, and then click the button to the right of **\<Configure Computer...\>**. In the next dialog you enter the **Target Computer Name** and can let the host computer automatically provision the target computer and set up debugger options.
 
 Finally, in Visual Studio, from the **Build** menu select **Deploy Solution** to deploy the sample to the target computer. On the target computer, you can see the deployed package in the **%Systemdrive%\\drivertest\\drivers** folder.
 
-Install the driver
-------------------
+## Install the driver
 
 On the target computer, open Device Manager, and follow these steps:
 
-1.  In the **Action** menu, click **Add Legacy Hardware**, and the **Add Hardware Wizard** appears. Click **Next** and then **Next** again.
-2.  In the **Add Hardware** window, select **Show All Devices**.
-3.  In the **Manufacturer** list in the left pane, click **Microsoft**.
-4.  You should see the **AVStream Simulated Hardware Sample** in the **Model** pane on the right. Click this and then click **Next**.
-5.  Click **Next** again to install the driver, and then click **Finish** to exit the wizard.
+1. In the **Action** menu, click **Add Legacy Hardware**, and the **Add Hardware Wizard** appears. Click **Next** and then **Next** again.
+
+1. In the **Add Hardware** window, select **Show All Devices**.
+
+1. In the **Manufacturer** list in the left pane, click **Microsoft**.
+
+1. You should see the **AVStream Simulated Hardware Sample** in the **Model** pane on the right. Click this and then click **Next**.
+
+1. Click **Next** again to install the driver, and then click **Finish** to exit the wizard.
 
 The sample driver now appears in the Device Manager console tree under **Sound, video and game controllers**. The Avshws INF file will be on the system drive at, for example, **...windows\\System32\\DriverStore\\FileRepository\\**.
 
-Sample code hierarchy
----------------------
+## Sample code hierarchy
 
-[**DriverEntry**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff558717) in Device.cpp is the initial point of entry into the driver. This routine passes control to AVStream by calling the [**KsInitializeDriver**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff562683) function. In this call, the minidriver passes the device descriptor, an AVStream structure that recursively defines the AVStream object hierarchy for a driver. This is common behavior for an AVStream minidriver.
+[**DriverEntry**](https://docs.microsoft.com/previous-versions//ff558717(v=vs.85)) in Device.cpp is the initial point of entry into the driver. This routine passes control to AVStream by calling the [**KsInitializeDriver**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/nf-ks-ksinitializedriver) function. In this call, the minidriver passes the device descriptor, an AVStream structure that recursively defines the AVStream object hierarchy for a driver. This is common behavior for an AVStream minidriver.
 
-At device start time, a simulated piece of capture hardware is created (the **CHardwareSimulation** class), and a DMA adapter is acquired from the operating system and is registered with AVStream by calling the [**KsDeviceRegisterAdapterObject**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff561687) function. This call is required for a sample that performs DMA access directly into the capture buffers, instead of using DMA access to write to a common buffer. The driver creates the [KS Filter](http://msdn.microsoft.com/en-us/library/windows/hardware/ff567644) for this device dynamically by calling the [**KsCreateFilterFactory**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff561650) function.
+At device start time, a simulated piece of capture hardware is created (the **CHardwareSimulation** class), and a DMA adapter is acquired from the operating system and is registered with AVStream by calling the [**KsDeviceRegisterAdapterObject**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/nf-ks-ksdeviceregisteradapterobject) function. This call is required for a sample that performs DMA access directly into the capture buffers, instead of using DMA access to write to a common buffer. The driver creates the [KS Filter](https://docs.microsoft.com/windows-hardware/drivers/stream/ks-filters) for this device dynamically by calling the [**KsCreateFilterFactory**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/nf-ks-kscreatefilterfactory) function.
 
-Filter.cpp is where the sample lays out the [**KSPIN\_DESCRIPTOR\_EX**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff563534) structure for the single video pin. In addition, a [**KSFILTER\_DISPATCH**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff562554) structure and a [**KSFILTER\_DESCRIPTOR**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff562553) structure are provided in this source file. The filter dispatch provides only a create dispatch, a routine that is included in Filter.cpp. The process dispatch is provided on the pin because this is a pin-centric sample.
+Filter.cpp is where the sample lays out the [**KSPIN\_DESCRIPTOR\_EX**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_kspin_descriptor_ex) structure for the single video pin. In addition, a [**KSFILTER\_DISPATCH**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_ksfilter_dispatch) structure and a [**KSFILTER\_DESCRIPTOR**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_ksfilter_descriptor) structure are provided in this source file. The filter dispatch provides only a create dispatch, a routine that is included in Filter.cpp. The process dispatch is provided on the pin because this is a pin-centric sample.
 
-Capture.cpp contains source for the video capture pin on the capture filter. This is where the [**KSPIN\_DISPATCH**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff563535) structure for the unique pin is provided. This dispatch structure specifies a *Process* callback routine, also defined in this source file. This routine is where stream pointer manipulation and cloning occurs.
+Capture.cpp contains source for the video capture pin on the capture filter. This is where the [**KSPIN\_DISPATCH**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_kspin_dispatch) structure for the unique pin is provided. This dispatch structure specifies a *Process* callback routine, also defined in this source file. This routine is where stream pointer manipulation and cloning occurs.
 
 The process callback is one of two routines of interest in Capture.cpp that demonstrate how to perform DMA transfers with AVStream functionality. The other is the **CCapturePin::CompleteMappings** method. These two methods show how to use the queue, obtain clone pointers, use scatter/gather lists, and perform other DMA-related tasks.
 
 For more information, see the comments in all .cpp files.
 
-Run the sample
---------------
+## Run the sample
 
 Follow these steps to see how the sample driver functions:
 
-1.  After installation has completed, access the driver through the Graphedt tool. Graphedt.exe is available in the *tools* directory of the WDK.
-2.  Before running GraphEdit, use the regsvr32 utility to register the proppage.dll DLL and to enable GraphEdit to display property pages for some of the built-in Microsoft DirectShow filters. Open an elevated command window with Administrator privileges, and navigate to the WDK or SDK *tools* directory that contains proppage.dll.
-3.  On the command line, type regsvr32 proppage.dll. If the registration succeeds, you'll get a message, "DllRegisterServer in proppage.dll succeeded." Click OK.
-4.  In the Graphedt tool, click the **Graph** menu and click **Insert Filters**. The sample appears under "WDM Streaming Capture Devices" as "avshws Source."
-5.  Click **Insert Filter**. The sample appears in the graph as a single filter labeled, "avshws Source." There is one output pin, which is the video capture pin. This pin emits video in YUY2 format.
-6.  Attach this filter to either a DirectShow Video Renderer or to the VMR default video renderer. Then click **Play**.
+1. After installation has completed, access the driver through the Graphedt tool. Graphedt.exe is available in the *tools* directory of the WDK.
+
+1. Before running GraphEdit, use the regsvr32 utility to register the proppage.dll DLL and to enable GraphEdit to display property pages for some of the built-in Microsoft DirectShow filters. Open an elevated command window with Administrator privileges, and navigate to the WDK or SDK *tools* directory that contains proppage.dll.
+
+1. On the command line, type regsvr32 proppage.dll. If the registration succeeds, you'll get a message, "DllRegisterServer in proppage.dll succeeded." Click OK.
+
+1. In the Graphedt tool, click the **Graph** menu and click **Insert Filters**. The sample appears under "WDM Streaming Capture Devices" as "avshws Source."
+
+1. Click **Insert Filter**. The sample appears in the graph as a single filter labeled, "avshws Source." There is one output pin, which is the video capture pin. This pin emits video in YUY2 format.
+
+1. Attach this filter to either a DirectShow Video Renderer or to the VMR default video renderer. Then click **Play**.
 
 The output that is produced by the sample is a 320 x 240 pixel image of standard EIA-189-A color bars. In the middle of the image near the bottom, a clock appears over the image. This clock displays the elapsed time since the graph was introduced into the run state following the last stop. The clock display format is MINUTES:SECONDS.HUNDREDTHS.
 
 In the upper-left corner of the image, a counter counts the number of frames that have been dropped since the graph was introduced into the run state after the last stop.
 
-Code tour
----------
-
-### File Manifest
+## File manifest
 
-File | Description
------|------------
-Avshws.h | Main header file for the sample
-Avshws.inf | Sample installation file
+| File | Description |
+| --- | --- |
+| Avshws.h | Main header file for the sample |
+| Avshws.inf | Sample installation file |
diff --git a/avstream/avssamp/README.md b/avstream/avssamp/README.md
index c8110667..ec11091b 100644
--- a/avstream/avssamp/README.md
+++ b/avstream/avssamp/README.md
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: AVStream filter-centric simulated capture sample driver (Avssamp)
     platform: WDM
@@ -20,49 +19,49 @@ products:
 
 # 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.
+The AVStream filter-centric simulated capture sample driver (Avssamp) provides a filter-centric [AVStream](https://docs.microsoft.com/windows-hardware/drivers/stream/avstream-overview) 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.
+
+## Installation instructions
+
+1. Copy AVssamp.inf to a directory, for example, C:\\Avstream\\.
+
+1. In this directory, create a new subdirectory named objfre\_x86 if the target operating system is x86-based, or objfre\_amd64 for an x64-based target operating system, for example, C:\\AVstream\\objfre\_x86\\.
 
-Installation instructions
--------------------------
+1. Copy the processor-appropriate Avssamp.sys file to the objfre\_\* directory.
 
-1.  Copy AVssamp.inf to a directory, for example, C:\\Avstream\\.
-2.  In this directory, create a new subdirectory named objfre\_x86 if the target operating system is x86-based, or objfre\_amd64 for an x64-based target operating system, for example, C:\\AVstream\\objfre\_x86\\.
-3.  Copy the processor-appropriate Avssamp.sys file to the objfre\_\* directory.
-4.  Start a command prompt with administrator privilege and run the processor-specific WDK tool Devcon.exe to launch the installation. For example:
+1. Start a command prompt with administrator privilege and run the processor-specific WDK tool Devcon.exe to launch the installation. For example:
 
     `C:\WinDDK\7600.16384.0\tools\devcon\i386\devcon.exe install C:\AVstream\avssamp.inf SW\{20698827-7099-4c4e-861A-4879D639A35F}`
 
-Programming Tour
-----------------
+## Programming tour
 
-[**DriverEntry**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff558717) in Avssamp.cpp is the initial point of entry into the driver. This routine passes control to AVStream by calling [**KsInitializeDriver**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff562683). In this call, the minidriver passes the device descriptor, an AVStream structure that recursively defines the AVStream object hierarchy for a driver. This is common behavior for an AVStream minidriver.
+[**DriverEntry**](https://docs.microsoft.com/previous-versions//ff558717(v=vs.85)) in Avssamp.cpp is the initial point of entry into the driver. This routine passes control to AVStream by calling [**KsInitializeDriver**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/nf-ks-ksinitializedriver). In this call, the minidriver passes the device descriptor, an AVStream structure that recursively defines the AVStream object hierarchy for a driver. This is common behavior for an AVStream minidriver.
 
-Filter.cpp is where the sample lays out the [**KSPIN\_DESCRIPTOR\_EX**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff563534) structure for the single capture pin. Audio.cpp contains the **KSPIN\_DESCRIPTOR\_EX** structure for the audio capture pin. This pin is dynamically created only if C:\\avssamp.wav exists and is a valid and readable PCM format wave file.
+Filter.cpp is where the sample lays out the [**KSPIN\_DESCRIPTOR\_EX**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_kspin_descriptor_ex) structure for the single capture pin. Audio.cpp contains the **KSPIN\_DESCRIPTOR\_EX** structure for the audio capture pin. This pin is dynamically created only if C:\\avssamp.wav exists and is a valid and readable PCM format wave file.
 
-The filter dispatch structure [**KSFILTER\_DISPATCH**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff562554) in Filter.cpp provides dispatches to create and process data. The **DispatchProcess** method is defined inline in Filter.h. It calls the **Process** method in Filter.cpp in the context of the **CCaptureFilter** class. Be aware that the process dispatch is provided in **KSFILTER\_DISPATCH** because this sample is filter-centric.
+The filter dispatch structure [**KSFILTER\_DISPATCH**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_ksfilter_dispatch) in Filter.cpp provides dispatches to create and process data. The **DispatchProcess** method is defined inline in Filter.h. It calls the **Process** method in Filter.cpp in the context of the **CCaptureFilter** class. Be aware that the process dispatch is provided in **KSFILTER\_DISPATCH** because this sample is filter-centric.
 
-Audio.cpp lays out a [**KSPIN\_DISPATCH**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff563535) pin dispatch structure, which contains the dispatch table for the audio pin. Be aware that the **Process** member of this structure is **NULL** because the sample is filter-centric. Similarly, Video.cpp contains the **KSPIN\_DISPATCH** structure for the video capture pin, again with the **Process** member set to **NULL**.
+Audio.cpp lays out a [**KSPIN\_DISPATCH**](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/ks/ns-ks-_kspin_dispatch) pin dispatch structure, which contains the dispatch table for the audio pin. Be aware that the **Process** member of this structure is **NULL** because the sample is filter-centric. Similarly, Video.cpp contains the **KSPIN\_DISPATCH** structure for the video capture pin, again with the **Process** member set to **NULL**.
 
 For more information, see the comments in all .cpp files.
 
-File Manifest
--------------
+## File manifest
 
-File | Description 
------|----------
-Audio.cpp | Audio capture pin implementation.
-Audio.h | Header file for Audio.cpp.
-Avssamp.cpp | Main file for the AVStream filter-centric sample.
-Avssamp.h | Main header for the AVStream filter-centric sample.
-Avssamp.inf | Installation information for the AVStream sample driver (avssamp.sys).
-Capture.cpp | Capture pin implementation for all capture pins on the sample filter.
-Capture .h | Capture pin level header for all capture pins on the sample filter.
-Filter.cpp | Capture filter implementation (including frame synthesis) for the fake capture filter.
-Filter.h | Filter level header for the filter-centric capture filter.
-Image.cpp | Image synthesis and overlay code. These objects provide image synthesis (pixel, color-bar, etc) onto RGB24 and UYVY buffers as well as software string overlay into these buffers.
-Image.h | Image synthesis and overlay header.
-Purecall.h | _purecall stub necessary for virtual function usage in drivers.
-Video.cpp | Video capture pin implementation.
-Video.h | Video capture pin header.
-Wave.cpp | Wave object implementation
-Wave.h | Wave object header
+| File | Description |
+| --- | --- |
+| Audio.cpp | Audio capture pin implementation |
+| Audio.h | Header file for Audio.cpp |
+| Avssamp.cpp | Main file for the AVStream filter-centric sample. |
+| Avssamp.h | Main header for the AVStream filter-centric sample. |
+| Avssamp.inf | Installation information for the AVStream sample driver (avssamp.sys). |
+| Capture.cpp | Capture pin implementation for all capture pins on the sample filter. |
+| Capture .h | Capture pin level header for all capture pins on the sample filter. |
+| Filter.cpp | Capture filter implementation (including frame synthesis) for the fake capture filter. |
+| Filter.h | Filter level header for the filter-centric capture filter. |
+| Image.cpp | Image synthesis and overlay code. These objects provide image synthesis (pixel, color-bar, etc) onto RGB24 and UYVY buffers as well as software string overlay into these buffers. |
+| Image.h | Image synthesis and overlay header |
+| Purecall.h | _purecall stub necessary for virtual function usage in drivers. |
+| Video.cpp | Video capture pin implementation |
+| Video.h | Video capture pin header |
+| Wave.cpp | Wave object implementation |
+| Wave.h | Wave object header |
diff --git a/biometrics/README.md b/biometrics/README.md
index dfafbc22..e8d376e1 100644
--- a/biometrics/README.md
+++ b/biometrics/README.md
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: Windows Biometric Driver Samples (UMDF Version 1)
     platform: UMDF1
@@ -30,31 +29,26 @@ This sample implements the Windows Biometric Driver Interface (WBDI). It contain
 *Windows Biometric Service Adapters*
 These samples provide skeleton code that developers can use as a basis for writing Sensor, Engine, and Storage Adapters for the Windows Biometric Service. Note that the stubs in these samples are non-functional, and Adapter writers will need to follow the programming guidelines in the WinBio Service documentation in order produce a working Adapter component.
 
-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).
+## Build the sample
 
-**Note** You can obtain the co-installers by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396).
+For information on how to build a driver solution using Microsoft Visual Studio, see [Building a Driver with Visual Studio and the WDK](https://docs.microsoft.com/windows-hardware/drivers/develop/building-a-driver).
 
-Run the sample
---------------
+> [!NOTE]
+> You can obtain the co-installers by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](https://go.microsoft.com/fwlink/p/?LinkID=253170).
 
-Installation
-------------
+## Installation
 
-### Windows Biometric Driver Interface
+### Windows Biometric Driver Interface installation
 
 The sample requires the use of a suitable fingerprint sensor. It does not capture real data, but it does create a biometric unit in the Windows Biometric Framework.
 
-### Windows Biometric Service Adapters
+### Windows Biometric Service Adapters installation
 
 To write and test an Adapter plug-in, it will be necessary to have a biometric device and a working WBDI driver for the device.
 
 Adapters are generally installed along with the WBDI driver for the corresponding device. Consult the WinBio Service documentation for information on the INF file commands used for installing Adapters. Note that Adapters are trusted plug-in components, so they can only be installed using a privileged account.
 
-Design and Operation
---------------------
+## Design and operation
 
 ### Windows Biometric Driver Interface
 
diff --git a/filesys/miniFilter/NameChanger/README.md b/filesys/miniFilter/NameChanger/README.md
index 0afa23c4..dd25409d 100644
--- a/filesys/miniFilter/NameChanger/README.md
+++ b/filesys/miniFilter/NameChanger/README.md
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: NameChanger File System Minifilter Driver
     platform: WDM
@@ -22,69 +21,66 @@ products:
 
 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.
 
-Build the sample
-----------------
+## Build the sample
 
 You can build the sample in two ways: using Microsoft Visual Studio or the command line (*MSBuild*).
 
-Building a Driver Using Visual Studio
--------------------------------------
+### Building a driver using Visual Studio
 
 You build a driver the same way you build any project or solution in Visual Studio. When you create a new driver project using a Windows driver template, the template defines a default (active) project configuration and a default (active) solution build configuration. When you create a project from existing driver sources or convert existing driver code that was built with previous versions of the WDK, the conversion process preserves the target version information (operating systems and platform).
 
 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 *filtername*.sln or *filtername*.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.  Open the driver project or solution in Visual Studio (find *filtername*.sln or *filtername*.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. From the Build menu, click **Build Solution** (Ctrl+Shift+B).
 
-Building a Driver Using the Command Line (MSBuild)
---------------------------------------------------
+### Building a driver from 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
+#### To select a configuration and build a driver from the command line
 
-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: **msbuild /t:clean /t:build .\\***filtername***.vcxproj**.
+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.
 
-Run the sample
---------------
+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: **msbuild /t:clean /t:build .\\***filtername***.vcxproj**.
 
-Installation
-------------
+## Installation
 
 The minifilter samples come with an INF file that will install the minifilter. To install the minifilter, do the following:
 
-1.  Make sure that *filtername*.sys and *filtername*.inf are in the same directory.
+1. Make sure that *filtername*.sys and *filtername*.inf are in the same directory.
 
-    **Note** This installation will make the necessary registry updates to register the minifilter service and place *filtername*.sys in the %SystemRoot%\\system32\\drivers directory.
+    > [!NOTE]
+    > This installation will make the necessary registry updates to register the minifilter service and place *filtername*.sys in the %SystemRoot%\\system32\\drivers directory.
 
-2.  In Windows Explorer, right-click *filtername*.inf, and click **Install**.
+1. In Windows Explorer, right-click *filtername*.inf, and click **Install**.
 
-3.  To load the minifilter, run **fltmc load** *filtername* or **net start** *filtername*.
+1. To load the minifilter, run **fltmc load** *filtername* or **net start** *filtername*.
 
-Design and Operation
---------------------
+## Design and operation
 
 The *NameChanger* minifilter illustrates how to make one part of a volume's namespace appear as though it belongs to part of another namespace. It accomplishes this by altering the names of files that reside beneath a particular path (called the "real mapping") to appear as though they actually reside beneath a different path (called the "user mapping"). The .inf file supplied with the sample defines the real and user mappings in the *[Strings]* section. The three strings used for the mappings are:
 
-String | Description
--------|-------------
-UserMapping | The location where files will appear to be in when the filter is attached
-UserMappingFinalComponentShort | The "short" (DOS-compliant 8.3-format) name for the final component of the UserMapping path.
-RealMapping | The actual location where the files reside.
+| String | Description |
+| --- | --- |
+| UserMapping | The location where files will appear to be in when the filter is attached. |
+| UserMappingFinalComponentShort | The "short" (DOS-compliant 8.3-format) name for the final component of the UserMapping path. |
+| RealMapping | The actual location where the files reside. |
 
 Before attaching the minifilter to a volume, you must set up the user and real paths. By default the .inf defines the mapping paths like in the following manner:
 
-String | Mapping
--------|--------
-UserMapping | "\X\Y"
-UserMappingFinalComponentShort | "Y"
-RealMapping | "\A\B"
+| String | Mapping |
+| --- | --- |
+| UserMapping | "\X\Y" |
+| UserMappingFinalComponentShort | "Y" |
+| RealMapping | "\A\B" |
 
 To successfully attach the filter to a volume you must first create a couple of directories. For example, to attach the *NameChanger* minifilter to the F: volume, first create the RealMapping directory (the F:\\A\\B directory). Next, create the parent of the UserMapping path (the F:\\X directory). The following directories are be created:
 
@@ -100,4 +96,4 @@ F:\\X\\Y
 
 After the minifilter attaches, the "B" subdirectory of F:\\A is no longer visible. Its contents now appear under the "Y" subdirectory of F:\\X.
 
-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.
\ No newline at end of file
+For more information on file system minifilter design, see [File System Minifilter Drivers](https://docs.microsoft.com/windows-hardware/drivers/ifs/file-system-minifilter-drivers).
diff --git a/gnss/ReadMe.md b/gnss/ReadMe.md
index 4421ae3e..09adccf2 100644
--- a/gnss/ReadMe.md
+++ b/gnss/ReadMe.md
@@ -1,5 +1,5 @@
 ---
-topic: sample
+page_type: sample
 description: "Provides base sample driver that IHVs and partners can use to extend to build their custom Windows GPS/GNSS drivers."
 languages:
 - cpp
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: GPS/GNSS UMDF Sample Driver (UMDF Version 2)
     platform: UMDF2
@@ -26,37 +25,49 @@ Provides a base sample driver that IHVs and partners can use to extend to build
 
 ### What is covered
 
-* This is a sample that adheres to GNSS driver design for Windows 10 outlined in the [GNSS driver design guide for Windows 10](https://docs.microsoft.com/windows-hardware/drivers/gnss/gnss-driver-design-guide-for-windows-10).
-* Serves as base sample driver that IHVs and partners can use as a template and guidance to extend to build their custom Windows GNSS drivers.
-* Follows the WDF guidelines and best practices around PnP device arrival/removal, power management and driver installation/uninstallation.
-* Supports the GNSS DDI mandatory requirements.
-* This driver successfully passes HLK tests and WDF tests provided by Visual studio.
+- This is a sample that adheres to GNSS driver design for Windows 10 outlined in the [GNSS driver design guide for Windows 10](https://docs.microsoft.com/windows-hardware/drivers/gnss/gnss-driver-design-guide-for-windows-10).
+
+- Serves as base sample driver that IHVs and partners can use as a template and guidance to extend to build their custom Windows GNSS drivers.
+
+- Follows the WDF guidelines and best practices around PnP device arrival/removal, power management and driver installation/uninstallation.
+
+- Supports the GNSS DDI mandatory requirements.
+
+- This driver successfully passes HLK tests and WDF tests provided by Visual studio.
 
 ### What is not covered
 
-* This sample currently doesn't support Geofence, SUPL, and AGNSS, as this is not mandatory GNSS DDI functionality.
-* SUPL and AGNSS are mandatory only if required by mobile operator, and the sample does not support them currently.
-* Not a production driver.
+- This sample currently doesn't support Geofence, SUPL, and AGNSS, as this is not mandatory GNSS DDI functionality.
+- SUPL and AGNSS are mandatory only if required by mobile operator, and the sample does not support them currently.
+- Not a production driver.
 
 ### What a Partner needs to do
 
-* Customer can install WDK and run Location HLK tests to validate their driver. All test cases should be either pass or skip without failure.
-* Partner owns the following:
-  * Installing the driver.
-  * Adding certificate and driver signing.
-  * Updating manufacturer name driver version etc. (the code has comments to update).
-* The GNSS sample code has "FIX ME" comments. Partner should update them accordingly.
+- Customer can install WDK and run Location HLK tests to validate their driver. All test cases should be either pass or skip without failure.
+
+- Partner owns the following:
+
+  - Installing the driver.
+
+  - Adding certificate and driver signing.
+
+  - Updating manufacturer name driver version etc. (the code has comments to update).
+
+- The GNSS sample code has "FIX ME" comments. Partner should update them accordingly.
 
 ## Design
 
-* The sample demonstrates a very basic software only driver that meets the minimum requirements from the GNSS DDI.
-* The sample currently always returns a fake hardcoded location. Driver developers can extend this to fetch fake positions from a file or inject through a custom IOCTL or instead implement getting real positions from GNSS hardware.
-* Driver developer can extend this to pull the fake positions from a file or through custom IOCTLs if needed.
+- The sample demonstrates a very basic software only driver that meets the minimum requirements from the GNSS DDI.
+
+- The sample currently always returns a fake hardcoded location. Driver developers can extend this to fetch fake positions from a file or inject through a custom IOCTL or instead implement getting real positions from GNSS hardware.
+
+- Driver developer can extend this to pull the fake positions from a file or through custom IOCTLs if needed.
 
 ## Trace Logging
 
-* The sample code provides Trace logging WPRP file.
-* To capture trace log, copy GnssUmdfSampleDriver.wprp in the solution folder into the device under test. On command line (MyLog.etl is an example file name below):
+- The sample code provides Trace logging WPRP file.
+
+- To capture trace log, copy GnssUmdfSampleDriver.wprp in the solution folder into the device under test. On command line (MyLog.etl is an example file name below):
 
     ```cmd
     wpr -start GnssUmdfSampleDriver.wprp -filemode
@@ -64,7 +75,7 @@ Provides a base sample driver that IHVs and partners can use to extend to build
     wpr -stop MyLog.etl
     ```
 
-* Inspect MyLog.etl with trace file analyzer. Note that corresponding PDB file is needed to decode the logging information.
+- Inspect MyLog.etl with trace file analyzer. Note that corresponding PDB file is needed to decode the logging information.
 
 ## Test Plan
 
@@ -72,29 +83,42 @@ Customer should validate their driver after customizing it.
 
 ### Test method 1
 
-* This tests WDF fundamental functionality (PnP etc.), rather than Location-specific features.
-* Run Visual studio built-in run-time test for WDF.
-* General information available at [](https://docs.microsoft.com/windows-hardware/drivers/develop/testing-a-driver-at-runtime).
-* Expected result / Pass criteria: Pass rate 100%
+- This tests WDF fundamental functionality (PnP etc.), rather than Location-specific features.
+
+- Run Visual studio built-in run-time test for WDF.
+
+- General information available at [](https://docs.microsoft.com/windows-hardware/drivers/develop/testing-a-driver-at-runtime).
+
+- Expected result / Pass criteria: Pass rate 100%
 
 ### Test method 2
 
-* This tests Location-specific functionality (Getting fix etc.).
-* Run [HLK](https://docs.microsoft.com/windows-hardware/test/hlk/windows-hardware-lab-kit) tests with existing and standard GNSS driver tests.
-* Run "TE.exe GNSSDriverTest.dll".
-* Expected result / Pass criteria: Pass rate 100%
-* Note that this sample does not support AGNSS, SUPL and Geofencing currently. Based on the capability of driver, HLK skips them automatically.
+- This tests Location-specific functionality (Getting fix etc.).
+
+- Run [HLK](https://docs.microsoft.com/windows-hardware/test/hlk/windows-hardware-lab-kit) tests with existing and standard GNSS driver tests.
+
+- Run "TE.exe GNSSDriverTest.dll".
+
+- Expected result / Pass criteria: Pass rate 100%
+
+- Note that this sample does not support AGNSS, SUPL and Geofencing currently. Based on the capability of driver, HLK skips them automatically.
 
 ### Test method 3
 
-* Test the [Windows Geolocation API](https://docs.microsoft.com/windows/desktop/locationapi/windows-location-api-portal) layer on real apps.
-* Get current location by clicking on "Show my location" from the In-box Windows Maps app.
-* Run the tracking scenario from the [Geolocation Sample app](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Geolocation).
-* Get current location by clicking on "Start" from GPS Satellite app in Windows Store.
+- Test the [Windows Geolocation API](https://docs.microsoft.com/windows/desktop/locationapi/windows-location-api-portal) layer on real apps.
+
+- Get current location by clicking on "Show my location" from the In-box Windows Maps app.
+
+- Run the tracking scenario from the [Geolocation Sample app](https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Geolocation).
+
+- Get current location by clicking on "Start" from GPS Satellite app in Windows Store.
 
 ## Resources
 
-* [GNSS DDI reference](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/gnssdriver/index)
-* [Getting started with Windows drivers](https://docs.microsoft.com/windows-hardware/drivers/gettingstarted)
-* [Windows Driver Kit documentation](https://docs.microsoft.com/windows-hardware/drivers)
-* [NMEA format documentation](http://navspark.mybigcommerce.com/content/NMEA_Format_v0.1.pdf)
+[GNSS DDI reference](https://docs.microsoft.com/windows-hardware/drivers/ddi/content/gnssdriver/index)
+
+[Getting started with Windows drivers](https://docs.microsoft.com/windows-hardware/drivers/gettingstarted)
+
+[Windows Driver Kit documentation](https://docs.microsoft.com/windows-hardware/drivers)
+
+[NMEA format documentation](http://navspark.mybigcommerce.com/content/NMEA_Format_v0.1.pdf)
diff --git a/sensors/ADXL345Acc/readme.md b/sensors/ADXL345Acc/readme.md
index d82dec2c..5346295e 100644
--- a/sensors/ADXL345Acc/readme.md
+++ b/sensors/ADXL345Acc/readme.md
@@ -1,5 +1,5 @@
 ---
-topic: sample
+page_type: sample
 description: "Demonstrates how to write a UMDF v2 driver to control an ADXL345 accelerometer chip."
 languages:
 - cpp
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: ADXL345 Accelerometer Sample Driver
     platform: UMDF2
@@ -20,4 +19,4 @@ products:
 
 # ADXL345 Accelerometer Sample Driver
 
-The ADXL345 accelerometer sample shows how to write a UMDF v2 driver to control an ADXL345 accelerometer chip.
\ No newline at end of file
+The ADXL345 accelerometer sample shows how to write a UMDF v2 driver to control an ADXL345 accelerometer chip.
diff --git a/sensors/Activity/readme.md b/sensors/Activity/readme.md
index caeeffac..2b905f43 100644
--- a/sensors/Activity/readme.md
+++ b/sensors/Activity/readme.md
@@ -1,5 +1,5 @@
 ---
-topic: sample
+page_type: sample
 description: "Demonstrates how to write a UMDF v2 driver to control an activity sensor."
 languages:
 - cpp
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: Activity Sensor Driver Sample
     platform: UMDF2
diff --git a/sensors/CustomSensors/readme.md b/sensors/CustomSensors/readme.md
index 984038ab..54e8d3ee 100644
--- a/sensors/CustomSensors/readme.md
+++ b/sensors/CustomSensors/readme.md
@@ -1,5 +1,5 @@
 ---
-topic: sample
+page_type: sample
 description: "Demonstrates how to write a UMDF v2 driver to control a custom sensor."
 languages:
 - cpp
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: Custom Sensor Driver Sample
     platform: UMDF2
@@ -20,4 +19,4 @@ products:
 
 # Custom Sensor Driver Sample
 
-The CustomSensor sample shows how to write a UMDF v2 driver to control a custom sensor.
\ No newline at end of file
+The CustomSensor sample shows how to write a UMDF v2 driver to control a custom sensor.
diff --git a/sensors/Fusion/readme.md b/sensors/Fusion/readme.md
index 7f0c41f8..0eeaa5df 100644
--- a/sensors/Fusion/readme.md
+++ b/sensors/Fusion/readme.md
@@ -1,5 +1,5 @@
 ---
-topic: sample
+page_type: sample
 description: "Demonstrates how to write a UMDF v2 driver to control a virtual FusionSensor sensor."
 languages:
 - cpp
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: Fusion Sensor Driver Sample
     platform: UMDF2
@@ -20,4 +19,4 @@ products:
 
 # Fusion Sensor Driver Sample
 
-The FusionSensor sample shows how to write a UMDF v2 driver to control a virtual FusionSensor sensor.
\ No newline at end of file
+The FusionSensor sample shows how to write a UMDF v2 driver to control a virtual FusionSensor sensor.
diff --git a/sensors/Pedometer/readme.md b/sensors/Pedometer/readme.md
index 8bb94bd6..b94fac76 100644
--- a/sensors/Pedometer/readme.md
+++ b/sensors/Pedometer/readme.md
@@ -1,6 +1,6 @@
 ---
-topic: sample
-description: "Demonstrates how to write a UMDF v2 driver to control a virtual Pedometer sensor."
+page_type: sample
+description: "Demonstrates how to write a UMDF v2 driver to control a virtual pedometer sensor."
 languages:
 - cpp
 products:
@@ -8,16 +8,15 @@ products:
 - windows-wdk
 ---
 
-
 <!---
-    name: Pedometer Sensor Sample
+    name: Pedometer sensor sample
     platform: UMDF2
     language: cpp
     category: Sensors
-    description: Demonstrates how to write a UMDF v2 driver to control a virtual Pedometer sensor.
+    description: Demonstrates how to write a UMDF v2 driver to control a virtual pedometer sensor.
     samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617959
 --->
 
-# Pedometer Sensor Sample
+# Pedometer sensor sample
 
-The Pedometer sample shows how to write a UMDF v2 driver to control a virtual Pedometer sensor.
+The Pedometer sample shows how to write a UMDF v2 driver to control a virtual pedometer sensor.
diff --git a/sensors/SensorsComboDriver/readme.md b/sensors/SensorsComboDriver/readme.md
index ed53a158..6dca7ff1 100644
--- a/sensors/SensorsComboDriver/readme.md
+++ b/sensors/SensorsComboDriver/readme.md
@@ -1,5 +1,5 @@
 ---
-topic: sample
+page_type: sample
 description: "Demonstrates how to write UMDF v2 drivers to control various types of virtual sensors."
 languages:
 - cpp
@@ -8,7 +8,6 @@ products:
 - windows-wdk
 ---
 
-
 <!---
     name: Sensors Combo Driver Sample
     platform: UMDF2
@@ -20,4 +19,4 @@ products:
 
 # Sensors Combo Driver Sample
 
-The sensors combo driver sensor sample shows how to write UMDF v2 drivers to control various types of virtual sensors such as Ambient Light, Barometer, Gyroscope, Magnetometer, Geomagnetic, Gravity Vector, Proximity, Linear Accelerometer and Relative Fusion.
\ No newline at end of file
+The sensors combo driver sensor sample shows how to write UMDF v2 drivers to control various types of virtual sensors such as ambient light, barometer, gyroscope, magnetometer, geomagnetic, gravity vector, proximity, linear accelerometer and relative fusion.
diff --git a/sensors/SimpleDeviceOrientationSensor/readme.md b/sensors/SimpleDeviceOrientationSensor/readme.md
index a008e17b..371e75cd 100644
--- a/sensors/SimpleDeviceOrientationSensor/readme.md
+++ b/sensors/SimpleDeviceOrientationSensor/readme.md
@@ -1,6 +1,6 @@
 ---
 topic: sample
-description: "Demonstrates how to write a UMDF v2 sensor driver to output Simple Device Orientation values."
+description: "Demonstrates how to write a UMDF v2 sensor driver to output simple device orientation values."
 languages:
 - cpp
 products:
@@ -8,16 +8,15 @@ products:
 - windows-wdk
 ---
 
-
 <!---
-    name: Simple Device Orientation Sensor Sample
+    name: Simple device orientation sensor sample
     platform: UMDF2
     language: cpp
     category: Sensors
-    description: Demonstrates how to write a UMDF v2 sensor driver to output Simple Device Orientation values.
+    description: Demonstrates how to write a UMDF v2 sensor driver to output simple device orientation values.
     samplefwlink: http://go.microsoft.com/fwlink/p/?LinkId=617960
 --->
 
-# Simple Device Orientation Sensor Sample
+# Simple device orientation sensor sample
 
-The SimpleDeviceOrientationSensor sample shows how to write a UMDF v2 sensor driver to output Simple Device Orientation values.
\ No newline at end of file
+The SimpleDeviceOrientationSensor sample shows how to write a UMDF v2 sensor driver to output simple oevice orientation values.