12 files changed, 92 insertions, 167 deletions
diff --git a/general/cancel/ReadMe.md b/general/cancel/ReadMe.md
index 5baab9b9..c2b09ead 100644
--- a/general/cancel/ReadMe.md
+++ b/general/cancel/ReadMe.md
@@ -1,14 +1,12 @@
 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 XP 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**](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.
 
 The sample is accompanied by a simple multithreaded Win32 console application to stress-test the driver's cancel and cleanup routines.
 
 This driver is written for an hypothetical data-acquisition device that requires polling at a regular interval. The device has some settling period between two successive reads. On a user request, the driver reads data and records the time. When the next read request comes in, the driver checks the interval to see if it's reading the device too soon. If so, it pends the IRP and sleeps for a while, and then tries again. On arrival, IRPs are queued in a cancel-safe queue and a semaphore is signaled. A polling thread that waits indefinitely on the semaphore wakes up to the signal and processes queued IRPs sequentially.
 
-The building and installation instructions given here apply to Windows 2000 and later versions of Windows.
-
 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.
diff --git a/general/echo/umdf/ReadMe.md b/general/echo/umdf/ReadMe.md
index 750d34df..75ae46cd 100644
--- a/general/echo/umdf/ReadMe.md
+++ b/general/echo/umdf/ReadMe.md
@@ -20,7 +20,7 @@ To test the Echo driver, you can run echoapp.exe which is built from src\\genera
 
 First install the device as described above. Then run echoapp.exe.
 
-``` {.syntax xml:space="preserve"}
+```
 D:\>echoapp /?
 Usage:
 Echoapp.exe --- Send single write and read request synchronously
@@ -68,57 +68,50 @@ Note that the reads and writes are performed by independent threads in the echo
 File Manifest
 -------------
 
-File
-
-Description
-
-comsup.cpp & 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
+**comsup.cpp & comsup.h**
 
-DLL Support code - provides the DLL's entry point as well as the single required export (DllGetClassObject).
+- 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.
 
-These depend on comsup.cpp to perform the necessary class creation.
+**dllsup.cpp**
 
-exports.def
+- 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.
 
-This file lists the functions that the driver DLL exports.
+**exports.def**
 
-internal.h
+- This file lists the functions that the driver DLL exports.
 
-This is the main header file for this driver.
+**internal.h**
 
-Driver.cpp and Driver.h
+- This is the main header file for this driver.
 
-DriverEntry and events on the driver object.
+**Driver.cpp and Driver.h**
 
-Device.cpp and Device.h
+- DriverEntry and events on the driver object.
 
-The Events on the device object.
+**Device.cpp and Device.h**
 
-Queue.cpp and Queue.h
+- The Events on the device object.
 
-Contains Events on the I/O Queue Objects.
+**Queue.cpp and Queue.h**
 
-Echo.rc
+- Contains Events on the I/O Queue Objects.
 
-Resource file for the driver.
+**Echo.rc**
 
-WUDFEchoDriver.inx
+- Resource file for the driver.
 
-File that describes the installation of this driver. The build process converts this into an INF file.
+**WUDFEchoDriver.inx**
 
-makefile.inc
+- File that describes the installation of this driver. The build process converts this into an INF file.
 
-A makefile that defines custom build actions. This includes the conversion of the .INX file into a .INF file
+**makefile.inc**
 
-echodriver.ctl
+- A makefile that defines custom build actions. This includes the conversion of the .INX 
 
-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.
+**echodriver.ctl**
 
-These GUIDs must remain in sync with the trace control GUIDs defined in internal.h.
+- 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.
 
diff --git a/general/echo/umdf2/ReadMe.md b/general/echo/umdf2/ReadMe.md
index 3229f61b..bb45c52a 100644
--- a/general/echo/umdf2/ReadMe.md
+++ b/general/echo/umdf2/ReadMe.md
@@ -22,18 +22,18 @@ Click the download button on this page. Click **Save**, and then click **Open Fo
 Open the driver solution in Visual Studio
 -----------------------------------------
 
-Navigate to the folder that has the extracted sample. Double click the solution file (umdf2echo.sln). In Microsoft Visual Studio, locate Solution Explorer. (If this is not already open, choose **Solution Explorer** from the **View** menu.) In Solution Explorer, you can see one solution that contains 3 projects. There is a driver project (Driver-\>AutoSync-\>echo), an application project (Exe-\>echoapp), and a package project named **package** (lower case).
+Navigate to the folder that has the extracted sample. Double click the solution file (umdf2echo.sln). In Microsoft Visual Studio, locate Solution Explorer. (If this is not already open, 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
 ---------------------------------------------------
 
-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. Because this solution uses UMDF version 2, you cannot select a configuration earlier than Windows 8.1.
+In Visual Studio, in Solution Explorer, right click **Solution**, and choose **Configuration Manager**. Set the configuration and the platform. Make sure that the configuration and platform are the same for both the driver project and the package project. Do not check the **Deploy** boxes. 
 
 
 Locate the built driver package
 -------------------------------
 
-In File Explorer, navigate to the folder that contains your built driver package. The location of this folder varies depending on what you set for configuration and platform. For example, if your settings are Win8.1 Debug and x64, the package is in your solution folder under x64\\Win8.1Debug\\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
 --------------
@@ -70,7 +70,7 @@ 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=”Win8 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).
 
diff --git a/general/echo/umdfSocketEcho/ReadMe.md b/general/echo/umdfSocketEcho/ReadMe.md
index 12515365..ed4ce05f 100644
--- a/general/echo/umdfSocketEcho/ReadMe.md
+++ b/general/echo/umdfSocketEcho/ReadMe.md
@@ -13,18 +13,18 @@ Related technologies
 Code Tour
 ---------
 
-Parts of this code sample are generated from the ATL Project Wizard in Microsoft Visual Studio 2005. 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.
+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::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.
+- **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
 ------------
 
 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.
 
-To test this sample, you must have a test computer that is running Windows Vista or later. This test computer can be a second computer or, if necessary, your development computer.
+To test this sample, you must have a test computer. This test computer can be a second computer or, if necessary, your development computer.
 
 To install the UMDF Echo sample driver from the command line, do the following:
 
@@ -32,17 +32,13 @@ To install the UMDF Echo sample driver from the command line, do the following:
 
 2.  Copy the UMDF coinstaller, WUDFUpdate\_*MMmmmm*.dll, from the \\redist\\wdf\\\<architecture\> directory to the same directory (for example, C:\\socketechoSample).
 
-    **Note**  
-
-    You can obtain redistributable framework updates by downloading the *wdfcoinstaller.msi* package from [WDK 8 Redistributable Components](http://go.microsoft.com/fwlink/p/?LinkID=226396). This package performs a silent install into the directory of your Windows Driver Kit (WDK) installation. You will see no confirmation that the installation has completed. You can verify that the redistributables have been installed on top of the WDK by ensuring there is a redist\\wdf directory under the root directory of the WDK, %ProgramFiles(x86)%\\Windows Kits\\8.0.
-
-3.  
+    **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.
 
-    Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\socketechoSample), and run DevCon.exe as follows:
+3.  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).
+  You can find DevCon.exe in the \\tools directory of the WDK (for example, \\tools\\devcon\\i386\\devcon.exe).
 
 To update the socketecho driver after you make any changes, do the following:
 
@@ -52,7 +48,7 @@ To update the socketecho driver after you make any changes, do the following:
 
 3.  Navigate to the directory that contains the INF file and binaries (for example, cd /d c:\\ socketechoSample), and run devcon.exe as follows:
 
-    devcon.exe update socketecho.inf WUDF\\socketecho
+  `devcon.exe update socketecho.inf WUDF\\socketecho`
 
 To test this sample drivers on a checked operating system that you have installed (in contrast to the standard retail installations), you must modify the INF file to use the checked version of the UMDF co-installer. That is, you must do the following:
 
@@ -69,12 +65,11 @@ To test the SocketEcho driver, you can run socketechoserver.exe, which is built
 
 First, you must install the device as described earlier. Then, run socketechoserver.exe from a Command Prompt window.
 
-D:\\\>socketechoserver -h
-
-Usage:
+`D:\\\>socketechoserver -h`
 
+Usage
 ------
-
+```
 socketechoserver Display Usage
 
 socketechoserver -h Display Usage
@@ -154,31 +149,13 @@ 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.
 
 File Manifest
 -------------
 
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">File
-Description</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>Socketecho.htm</p>
-<p>The documentation for this sample.</p></td>
-<td align="left"><p>Dllsup.cpp</p>
-<p>The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject).</p></td>
-</tr>
-</tbody>
-</table>
+**Dllsup.cpp**: The DLL support code that provides the DLL's entry point and the single required export (DllGetClassObject).
 
 
diff --git a/general/filehistory/ReadMe.md b/general/filehistory/ReadMe.md
index 58ebbb46..3e29b08e 100644
--- a/general/filehistory/ReadMe.md
+++ b/general/filehistory/ReadMe.md
@@ -3,7 +3,7 @@ File History Sample
 
 The FileHistory sample is a console application that starts the file history service, if it is stopped, and schedules regular backups. The application requires, as a command-line parameter, the path name of a storage device to use as the default backup target.
 
-This sample application uses the [File History API](http://msdn.microsoft.com/en-us/library/windows/hardware/hh829789), which is available starting with Windows 8.1. The File History API enables third parties to automatically configure the File History feature on a Windows platform and customize it in accordance with their unique needs.
+This sample application uses the [File History API](http://msdn.microsoft.com/en-us/library/windows/hardware/hh829789). The File History API enables third parties to automatically configure the File History feature on a Windows platform and customize it in accordance with their unique needs.
 
 
 Run the sample
diff --git a/general/obcallback/ReadMe.md b/general/obcallback/ReadMe.md
index def34eac..7efc2741 100644
--- a/general/obcallback/ReadMe.md
+++ b/general/obcallback/ReadMe.md
@@ -11,7 +11,7 @@ The sample exercises both the [**PsSetCreateProcessNotifyRoutineEx**](http://msd
 
 The following is a command line usage scenario to exercise access restriction:
 
-``` {.syntax xml:space="preserve"}
+```
 C:\> obcallbacktestctrl.exe  -?                      (for command line help)
 C:\> obcallbacktestctrl.exe  -install                (installs the kernel driver)
 C:\> obcallbacktestctrl.exe  -name  notepad          (specifies that the string “notepad”  will be watched as a protected executable)
@@ -27,13 +27,11 @@ C:\> obcallbacktestctrl.exe  -deprotect              (remove the protections on
 
 C:\> kill –f  2329                                   (attempt to kill off the process – which will succeed)
 C:\> obcallbacktestctrl.exe  -uninstall              (uninstall the kernel driver)
- 
- 
 ```
 
 The following is another sample test you can run to prevent a process from being created:
 
-``` {.syntax xml:space="preserve"}
+```
 C:\> obcallbacktestctrl.exe  -install                (installs the kernel driver)
 C:\> obcallbacktestctrl.exe  -reject  notepad        (specifies that the string “notepad”  will be watched and prevented from starting as a process)
 
diff --git a/general/pcidrv/ReadMe.md b/general/pcidrv/ReadMe.md
index 72898b5b..39d4a2d6 100644
--- a/general/pcidrv/ReadMe.md
+++ b/general/pcidrv/ReadMe.md
@@ -43,31 +43,22 @@ Note that it is still possible to use a subset of KMDF APIs when writing a NDIS
 
 The sample driver has been tested on the following Intel Ethernet controllers:
 
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">Device Desc
-Hardware ID</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>IBM Netfinity 10/100 Ethernet Adapter</p>
-<p>PCI\VEN_8086&amp;DEV_1229&amp;SUBSYS_005C1014&amp;REV_05</p></td>
-<td align="left"><p>Intel(R) PRO/100+ Management Adapter with Alert On LAN</p>
-<p>PCI\VEN_8086&amp;DEV_1229&amp;SUBSYS_000E8086&amp;REV_08</p></td>
-</tr>
-</tbody>
-</table>
+Device Description | Hardware ID
+-------------------|------------
+IBM Netfinity 10/100 Ethernet Adapter |  PCIVEN_8086&DEV_1229&SUBSYS_005C1014&amp;REV_05
+Intel(R) PRO/100+ Management Adapter with Alert On LAN | PCI\VEN_8086&DEV_1229&SUBSYS_000E8086&REV_08
+Intel 8255x-based PCI Ethernet Adapter (10/100) | PCI\VEN_8086&DEV_1229&SUBSYS_00000000&REV_01
+Intel Pro/100 S Server Adapter | PCI\VEN_8086&DEV_1229&SUBSYS_00508086&REV_0D
+Intel 8255x-based PCI Ethernet Adapter (10/100) | PCI\VEN_8086&DEV_1229&SUBSYS_00031179&REV_08
+Intel(R) PRO/100 VE Network Connection | PCI\VEN_8086&DEV_103D&SUBSYS_00011179&REV_83
+Intel(R) PRO/100 VM Network Connection | PCI\VEN_8086&DEV_1031&REV_42
+Intel(R) PRO/100 VE Network Connection | PCI\VEN_8086&DEV_1038&REV_41
+Intel(R) PRO/100 SR Mobile Adapter | PCI\VEN_8086&DEV_1229
 
 Using this sample as a standalone driver
 ----------------------------------------
 
-``` {.syntax xml:space="preserve"}
+```
           ---------------------
          |                     |
          |        MYPING       | <-- Usermode test application
@@ -162,25 +153,11 @@ If you have questions on using or adapting this sample for your project, you can
 FILE MANIFEST
 -------------
 
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">File
-Description</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>KMDF</p>
-<p>Contains the driver.</p></td>
-<td align="left"><p>KMDF\HW</p>
-<p>Contains hardware specific code.</p></td>
-</tr>
-</tbody>
-</table>
+File | Description
+-----|------------
+KMDF | Contains the driver.
+KMDF\HW | Contains hardware specific code.
+TEST | Contains source of test application (MYPING).
+
 
 
diff --git a/general/perfcounters/kcs/ReadMe.md b/general/perfcounters/kcs/ReadMe.md
index 4f28894c..1cbd3ac0 100644
--- a/general/perfcounters/kcs/ReadMe.md
+++ b/general/perfcounters/kcs/ReadMe.md
@@ -7,8 +7,6 @@ This module contains sample code to demonstrate how to provide counter data from
 
 This sample driver should not be used in a production environment.
 
-Kcs is designed for Windows 7 and later versions of Windows.
-
 The Microsoft Windows operating system allows system components and third parties to expose performance metrics in a standard way by using [Performance Counters](http://msdn.microsoft.com/en-us/library/windows/hardware/aa373083). Kernel-mode PCW providers are installed in the system as Performance Counter Library (PERFLIB) (Version 2 providers), which allows their counters to be browsed, and allows for data collection and instance enumeration. Consumers can query KM PCW providers by using PDH and PERFLIB Version 1 without any modification to the consumer code.
 
 
diff --git a/general/registry/regfltr/ReadMe.md b/general/registry/regfltr/ReadMe.md
index 731e8ca3..9e5a0740 100644
--- a/general/registry/regfltr/ReadMe.md
+++ b/general/registry/regfltr/ReadMe.md
@@ -9,8 +9,6 @@ The RegFltr sample shows how to write a [registry filter driver](http://msdn.mic
 -   Changes in version 1.1 of registry filtering.
 -   How to use version 1 of the [**REG\_CREATE\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560920) and [**REG\_OPEN\_KEY\_INFORMATION**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff560957) data structures.
 
-The RegFltr sample demonstrates the registry filtering system on Windows Vista, Windows Server 2008 and later versions of the Windows operating system. It does not work for Windows XP or Windows Server 2003.
-
 The RegFltr sample contains several examples of user-mode and kernel-mode registry-filtering operations. Each example comes with its own corresponding registry callback routine, and performs the following steps:
 
 1.  Does some setup work.
diff --git a/general/tracing/SystemTraceControl/ReadMe.md b/general/tracing/SystemTraceControl/ReadMe.md
index f581e52e..eb044ddb 100644
--- a/general/tracing/SystemTraceControl/ReadMe.md
+++ b/general/tracing/SystemTraceControl/ReadMe.md
@@ -5,7 +5,7 @@ This sample application demonstrates how to use event tracing control APIs to co
 
 The sample code provided shows how to start an [Event Tracing](http://msdn.microsoft.com/en-us/library/windows/hardware/bb968803) for Windows trace session and how to enable system events with stacks. When you build and run the application, it collects the trace data for 30 seconds and then stops. The sample application writes the results to a file, Systemtrace.etl. For more information, see [Tools for Software Tracing](http://msdn.microsoft.com/en-us/library/windows/hardware/ff552961).
 
-You can process the Systemtrace.etl file using Tracerpt.exe. Tracerpt.exe is a command-line trace tool that formats trace events. It also analyzes the events and generates summary reports. Tracerpt is included in Windows XP and later versions of Windows. For more information about how to use this tool, see [Tracerpt](http://go.microsoft.com/fwlink/p/?linkid=179389) topic on the TechNet website.
+You can process the Systemtrace.etl file using Tracerpt.exe, a command-line trace tool included in Windows that formats trace events. It also analyzes the events and generates summary reports. For more information about how to use this tool, see [Tracerpt](http://go.microsoft.com/fwlink/p/?linkid=179389) topic on the TechNet website.
 
 You can also process the file using the [Windows Performance Toolkit](http://go.microsoft.com/fwlink/p/?linkid=250774) (WPT), which is available in the SDK.
 
diff --git a/general/tracing/evntdrv/ReadMe.md b/general/tracing/evntdrv/ReadMe.md
index f5780ef6..a560a0a4 100644
--- a/general/tracing/evntdrv/ReadMe.md
+++ b/general/tracing/evntdrv/ReadMe.md
@@ -13,7 +13,7 @@ Run the sample
 
 1.  Install the manifest (Evntdrv.xml), which is located in the Evntdrv\\Eventdrv folder. Open a Visual Studio Command window (Run as administrator) and use the following command:
 
-    ``` {.syntax xml:space="preserve"}
+    ```
     wevtutil im evntdrv.xml
     ```
 
@@ -29,7 +29,7 @@ Run the sample
 
 3.  Use Tracelog to start a trace session that is called "TestEventdrv." The following command starts the trace session and creates a trace log file, Eventdrv.etl, in the local directory.
 
-    ``` {.syntax xml:space="preserve"}
+    ```
     Tracelog -start TestEventdrv -guid #b5a0bda9-50fe-4d0e-a83d-bae3f58c94d6 -f Eventdrv.etl
     ```
 
@@ -37,13 +37,13 @@ Run the sample
 
 5.  To stop the trace session, run the following command:
 
-    ``` {.syntax xml:space="preserve"}
+    ```
     tracelog -stop TestEventdrv
     ```
 
 6.  To display the traces collected in the Tracedrv.etl file, run the following command:
 
-    ``` {.syntax xml:space="preserve"}
+    ```
     tracerpt Eventdrv.etl
     ```
 
@@ -51,12 +51,12 @@ Run the sample
 
 7.  To uninstall the manifest, run the following command:
 
-    ``` {.syntax xml:space="preserve"}
+    ```
     wevtutil um evntdrv.xml
     ```
 
 Notes
 -----
 
-If you are building the Eventdrv sample to test on a 64-bit version of Windows, you need to sign the driver. Starting with Windows Vista, all 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202).
+If you are building the Eventdrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202).
 
diff --git a/general/tracing/tracedriver/ReadMe.md b/general/tracing/tracedriver/ReadMe.md
index 99c46dd5..3e95d383 100644
--- a/general/tracing/tracedriver/ReadMe.md
+++ b/general/tracing/tracedriver/ReadMe.md
@@ -12,49 +12,37 @@ Run the sample
 
 To test the Tracedrv event tracing provider, use the following procedure.
 
-1.  Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2013\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2013\\Projects\\tracedrv\\tracedrv\\*platform*).
-2.  Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command:
+1.  Copy the Tracectl.exe file that was created when you built the Tracedrv solution from the Tracectl directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracectl\\*platform*) to the Tracedrv directory (for example, \\Documents\\Visual Studio 2015\\Projects\\tracedrv\\tracedrv\\*platform*).
+2.  Use Tracepdb to create a trace message format (TMF) file and a trace message control (TMC) file from the Tracedrv.pdb file. Tracepdb is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The PDB file that is used in this command is created when you the build the solution. Open a Visual Studio Command prompt window and navigate to the target build platform and configuration directory. Type the following command:
 
     **tracepdb -f tracedrv.pdb**
 
 3.  In the same Tracedrv target build directory, create a control GUID file for Tracedrv by opening a text file, adding the following content, and saving the file as Tracedrv.ctl.
 
-    <table>
-    <colgroup>
-    <col width="100%" />
-    </colgroup>
-    <thead>
-    <tr class="header">
-    <th align="left">Text</th>
-    </tr>
-    </thead>
-    <tbody>
-    <tr class="odd">
-    <td align="left"><pre><code>d58c126f-b309-11d1-969e-0000f875a5bc </code></pre></td>
-    </tr>
-    </tbody>
-    </table>
+  ```txt
+  d58c126f-b309-11d1-969e-0000f875a5bc
+  ```
 
-4.  Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory.
+4.  Use Tracelog to start a trace session that is called *TestTracedrv*. Tracelog is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform* directory. The Tracedrv.ctl file that is used in this command was created in the previous step. The following command starts a trace session and creates a trace log file, tracedrv.etl, in the local directory.
 
-    ``` {.syntax xml:space="preserve"}
-    tracelog -start TestTracedrv -guid tracedrv.ctl -f tracedrv.etl -flag 1
-    ```
+  ``` 
+  tracelog -start TestTracedrv -guid tracedrv.ctl -f tracedrv.etl -flag 1
+  ```
 
-    **Note**  Note: Without the -flag parameter, Tracedrv will not generate any trace messages.
+  **Note**  Note: Without the -flag parameter, Tracedrv will not generate any trace messages.
 
 5.  To generate trace messages, run Tracectl.exe. This executable file is built when you build the solution. Each time you type a character, other than **Q** or **q**, Tracectl sends an IOCTL to the driver that signals it to generate trace messages. To stop Tracectl, type **Q** or **q**.
 6.  To stop the trace session, use the following Tracelog command.
 
-    ``` {.syntax xml:space="preserve"}
-    tracelog -stop TestTracedrv
-    ```
+  ``` 
+  tracelog -stop TestTracedrv
+  ```
 
-7.  To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\8.1\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command:
+7.  To display the trace messages in the Tracedrv.etl file, use Tracefmt.exe. Tracefmt.exe is located in the C:\\Program Files (x86)\\Windows Kits\\10\\bin\\*platform*. The TMF file used in this command was created by Tracepdb.exe in step 2. The **-p** option specifies the directory of the TMF file. In this case, the TMF file is in the current directory. Type the following command:
 
-    ``` {.syntax xml:space="preserve"}
-    tracefmt tracedrv.etl -p . -o Tracedrv.out
-    ```
+  ```
+  tracefmt tracedrv.etl -p . -o Tracedrv.out
+  ```
 
 The resulting Tracedrv.out file is a human-readable text file of the Tracedrv trace messages. To interpret the trace messages, in the Tracedrv.c file, search for the [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918) macros.
 
@@ -63,11 +51,9 @@ Notes
 
 This sample driver should not be used in a production environment.
 
-Tracedrv is designed for Windows XP and later versions of Windows. It does not demonstrate how to add WPP software tracing to a Windows 2000 driver. (For information about adding WPP software tracing to a Windows 2000 driver, see the [Software Tracing FAQ](http://msdn.microsoft.com/en-us/library/windows/hardware/ff551795) topic in the Windows DDK documentation.)
-
 Also, because it is not a Plug and Play driver, Tracedrv does not demonstrate tracing in a Plug and Play environment.
 
 Tracedrv demonstrates the basic elements required for software tracing. It does not demonstrate more advanced tracing techniques, such as writing customized tracing calls (variations of [**DoTraceMessage**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff544918)), or the use of WMI calls for software tracing.
 
-If you are building the Tracedrv sample to test on a 64-bit version of Windows, you need to sign the driver. Starting with Windows Vista, all 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202).
+If you are building the Tracedrv sample to test on a 64-bit version of Windows, you need to sign the driver. All 64-bit versions of Windows require driver code to have a digital signature for the driver to load. See [Signing a Driver](http://msdn.microsoft.com/en-us/library/windows/hardware/ff554809) and [Signing a Driver During Development and Testing](http://msdn.microsoft.com/en-us/library/windows/hardware/hh967733). You might also need to configure the test computer so that it can load test-signed kernel mode code, see [The TESTSIGNING Boot Configuration Option](http://msdn.microsoft.com/en-us/library/windows/hardware/ff553484) and [**BCDEdit /set**](http://msdn.microsoft.com/en-us/library/windows/hardware/ff542202).