1.  The ETW trace from PnP
Manager 

The ETW trace is the easiest method to capture because it
had been available in the released build of OS.

For example, I enabled the ETW trace by following command
(this command requires the cmd.exe to be launched by Run as administrator):

logman create trace
"kernel_pnp_trace" -ow -o c:\kernel_pnp_trace.etl -p
"Microsoft-Windows-Kernel-PnP" 0xffffffffffffffff 0xff -nb 16 16 -bs
1024 -mode Circular -f bincirc -max 4096 -ets

This command will create a new ETW trace session and enable
the provider: Microsoft-Windows-Kernel-PnP which is provided by the Windows
kernel.

Then I attach a USB mouse. And then I stop the trace
session:

logman stop
"kernel_pnp_trace" -ets

Finally, I got an etl file which had recorded the activities
in Windows kernel PnP manger. The etl file is a binary file which need to be
converted to a human readable file. For example, we can covert the etl file to
an XML file:

tracerpt
c:\kernel_pnp_trace.etl -o kernel_pnp_trace.xml -of xml

You can format the display of the xml file by any tools. For
example, following is the original record of the enumeration of a mouse device:

There are lots of Events recorded in the trace file. Based
on the trace file, we may find out what had happened in the PnP Manager.

2.  The Debug Message from the
checked build of PnP Manager

The checked build of PnP
Manager has detailed trace which can be enabled if we can reproduce a PnP issue
with the checked build or checked kernel. Basically, we get the checked (debug)
build of the OS kernel from:

u  WDK
Installation: C:\Program Files (x86)\Windows Kits\8.1\Debug\winv6.3

u  A
checked build of OS from MSDN Subscription

 Then we can copy the
checked kernel to a release build of OS. We need to know which kernel and hal
files currently are used so that the correct files from the checked build are
used. See the https://msdn.microsoft.com/EN-US/library/windows/hardware/ff547188(v=vs.85).aspx
for details.

Then we can Create a new Boot Entry with the checked kernel
files

                bcdedit
/copy {current} /d "Windows 8.1 Checked Build kernel"

                bcdedit
/set GUID kernel ntkrnlmp.chk

                bcdedit
/set GUID hal halmacpi.chk

Note that the ntkrnlmp.chk and halmacpi.chk are from the
checked build or WDK. Please rename these checked build files so that no
existing files in the %SystemRoot%\system32 are overwritten.

After the checked build of PnP Manager is available, we can
enable the output from PnP Manager by:

u  Enable
NTOSPNP flag in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager\Debug Print Filter

                NTOSPNP
(REG_DWORD) = 0xFFFFFFFF

After above change, you should be able to see the debug
messages from a kernel debugger or dbgview.

For example:
 

The information from the checked build has lots of detailed
information which will be helpful for the driver developer.

Thanks,

Jungang Bai

Windows HLK RC
for Windows 10 -- http://go.microsoft.com/fwlink/p/?LinkID=404112

HCK for Windows
8.1 -- http://go.microsoft.com/fwlink/p/?LinkID=317577&clcid=0x409

Windows Logo Kit
1.6 -- https://www.microsoft.com/en-us/download/details.aspx?id=39359

However, the
partners who use the kit may find there are many test cases failed for many
reasons. Especially for those users who run the test kit for the first time.
Beside the normal troubleshooting steps which may be involved to fix the
failure. There are a list of failures which came from the test tool kit itself
or the hardware spec limitation or even the operation system. To unblock
partners from this type of issues, the Windows HLK/HCK and WLK had
published a set of Errata to cover this situation. You may want to know the
details of these Errata so that you can save lots of time to troubleshoot a
test failure.

The Errata of Windows HLK/HCK and WLK includes following
type:

Automatic Errata/Filter
– It is a set of script which can be installed to the DTM Controller and be
applied after the test had been done. The automatic Errata/Filter is able to
change the final test result to PASS if it can be applied. Note that the error
message or failure message are still in the log file, it only changes the final
result. You need to install the latest Errata/Filter package to apply them and
confirm that the final result of a test case is PASS.

Manual Errata –
It is a type of Errata which can’t be applied automatically. The steps to
decide if an error or failure can be covered or not may be very long or complicated.
Or the information in the test result is not enough to decide the application
of the Errata. This is a situation in which you may ask Microsoft Support team
to help verify if there is a manual Errata for the specific error. There are
lots of the manual Errata have an auto-triage
filter which will be installed with the latest Errata/Filter package. The
auto-triage filter will not change the test case to PASS. However, it may
indicate that this is an error which somebody else had encountered before. You
can follow the information or instruction from the auto-triage filter to
troubleshoot a test failure.

Contingency – It is a type of temp Errata which
is approved by Windows Logo team based on the business impact of the issue. The
partners often has a tight schedule and it is impossible to apply a solution in
a very short time. To request a contingency send email to the sysdev@microsoft.com
alias or other contacts you are provided to request the appropriate forms and
instructions.

Thanks,

Jungang Bai   

• 
  Improve Debugging And Performance Tuning With ETW

https://msdn.microsoft.com/en-us/magazine/cc163437.aspx

• 
  ETW (Event Tracing For Windows) – what it is and useful tools

http://blogs.msdn.com/b/oanapl/archive/2009/08/05/etw-event-tracing-for-windows-what-it-is-and-useful-tools.aspx

There are hundreds of inbox ETW providers installed. It became a popular method to troubleshoot Windows issues because collecting ETW trace doesn’t need to install any tools (using logman.exe) or to restart machine. There are lots of document about how to collect and analyze ETW trace file for scenario based problem. There are also many applications and drivers which generates Manifest-based events.

However, to decode the trace file generated from these ETW providers correctly, we have to run Events Consumers (any tools to convert the ETL file to a human readable text file) in the same machine where the ETL file are captured because the Manifest of the ETW providers had been installed to the machine. If an ETL file is
copied from a test machine to another machine, you may encounter situation in which your machine misses the Event Schema or the Manifest of ETW Provider which are only installed in the test machine.

For example, this Microsoft-Windows-wmbclass provider is not installed by default on a Windows 8.1 system until you install a Mobile Broadband device. To decode the ETL file from Microsoft-Windows-wmbclass provider, you must install this provider on your machine or the trace file will not be decoded successfully. The easiest
way is to plug a Mobile Broadband device on your machine and the driver installation will also install this ETW provider properly.

There are scenarios in which we can’t install the ETW provider easily to our working machine. In this case, we have to capture the Schema at the same time when capturing the ETL file. There are tools for this purpose. Tracerpt.exe is an inbox tool to capture the schema which is used to decode Manifest-based events.

For example: we are capturing the trace from an ETW provider which is only installed on a test machine:

Logman.exe start test_trace -o .\test.etl -p "Sample Driver" 0xffffffffffffffff 0xff -nb 16 16 -bs 1024 -mode Circular -f bincirc -max 4096 -ets

Logman.exe stop test_trace -ets

After stopping the trace, we can export the schema which is used to decode those Manifest-based events in the ETL file to a schema file (run this command in the test machine)

Tracerpt.exe .\test.etl -export schema.man

We copied the ETL file and schema.man file to another machine. Then we are able to decode those Manifest-based events successfully by referencing the schema copied from test machine:

Tracerpt.exe .\test.etl -o test.xml -of xml -import schema.man

The current Message Analyzer is able to accept the etl file and man file as the input to show correct messages. see https://technet.microsoft.com/en-us/library/jj674809.aspx for details.

If you check WDK8 header file wdm.h, KGUARDED_MUTEX equals to FAST_MUTEX:

In WDK7.1 wdm.h, KGUARDED_MUTEX is defined as below:

Before Win8, People use guarded mutex, because comparing to fast mutex, guarded mutex is faster, more importantly, it will not raise IRQL to APC_LEVEL, which means the protected code can stay at PASSIVE_LEVEL in synchronization. A code path that is protected by fast mutex runs at IRQL = APC_LEVEL.

The problem is ‘OLD‘ Win7 KGUARDED_MUTEX was implemented based on guarded region, which disables all APCs (Normal Kernel APC and Special Kernel APC). This identical to raise current IRQL to APC_LEVEL.  As such, any APIs that are illegal at APC_LEVEL are also illegal in protection of guarded mutex. Win8 made the conscious choice to unify the code implementation for fast mutex and guarded mutex. They are identical.

Here’s a blog calling out the fact that calling passive level APIs in guarded regions is bad:

http://blogs.technet.com/b/fbsblogs/archive/2008/12/26/failing-io_2700_s-issued-at-apc-level-or-with-special-kernel-apcs-disabled-_2800_except-in-the-case-of-paging-io_2900_.aspx

1. If the driver package is uniform, refer to the following HCK newsletter:

http://msdn.microsoft.com/en-us/windows/hardware/dn320463

Digital signatures available for legacy operating systems in the new Windows HCK for
Windows 8.1

When you successfully complete testing for a client certification of Windows 7, Windows 8, or Windows 8.1, use the Dashboard to create a submission package for uploading - the same process that you’ve used in the past. And, if you’re using a uniform driver that’s properly decorated to include Windows Vista and Windows XP, the dashboard has check boxes for free digital signatures.

2. If the driver package is not uniform. You can run xp and vista test with WLK1.6, and send the submission to sysdev with a special method. Contact sysdev@microsoft.com for the special method details

• Microsoft Windows USB Core Team Blog
  http://blogs.msdn.com/b/usbcoreblog/

1. No Full Memory Dumps option?

   The I/O Manager originally limited the size of a complete memory dump to 2GB, now the fact is Windows support crash dumps larger than 2GB. To workaround this, set \HKLM\System\CCS\Control\CrashControl\CrashDumpEnabled DWORD value to 1

2. No memory.dmp generated after crash?
   Algorithm to decide whether to store/delete memory.dmp file generated after a system crash:
   First report the kernel fault to the Online Crash Analysis Service.
   Then, if machine has a registry setting AlwaysKeepMemoryDump set to 1, store the dump file on disk.
   Else, if machine is a Windows Server SKU, store the dump file on disk.
   Else, if the machine is joined to a domain (i.e. this is a corporate machine), store the dump file on disk.
   Else, if machine is not on a domain (i.e. this is a home user’s machine),
   If free disk space is >= 25GB, store the dump file on disk.
   Else (free disk space is < 25 GB), delete the dump file.
   The exact location of the AlwaysKeepMemoryDump setting in the registry is:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl ! AlwaysKeepMemoryDump Type: REG_DWORD.