microsoft / busiotools

Tools for debugging and testing io buses for Windows

Bus tools for Windows

This repo contains the scripts and tools to help discover and diagnose issues developers may encounter when making a peripheral work for Windows. The tools and scripts are described in greater detail on our blog.

Directory of Tools

• HMD Validation Kit
• USB, HID and Simple Peripheral Buses- I2C, UART, SPI Tools
• Sensor Tools
• How to collect Bluetooth logs
• Windows Camera Tracing

busiotools's Issues

Wrong links

In https://github.com/Microsoft/busiotools/tree/master/bluetooth/tracing#how-to-collect-bluetooth-logs the two bullets

• Normal Mode (cancels on reboot): Tracing for a single boot session, will not continue tracing after a reboot
• Autologger mode (collects logs across reboots): Tracing for running across reboots until you stop it manually

provide wrong links:

https://github.com/Microsoft/busiotools/tree/master/bluetooth/tracing#Normal-Mode-(cancels-on-reboot) instead of
https://github.com/Microsoft/busiotools/tree/master/bluetooth/tracing#normal-mode-cancels-on-reboot

respectivley:
https://github.com/Microsoft/busiotools/tree/master/bluetooth/tracing#Autologger-mode-(collects-logs-across-reboots) instead of
https://github.com/Microsoft/busiotools/tree/master/bluetooth/tracing#autologger-mode-collects-logs-across-reboots

Autologger mode (collects logs across reboots) not starting the log collection

wget https://github.com/Microsoft/busiotools/raw/master/bluetooth/tracing/BluetoothStack.wprp -UseBasicParsing -outfile .\BluetoothStack.wprp
wpr.exe -boottrace -addboot BluetoothStack.wprp!BluetoothStack -filemode
shutdown -r -f -t 0
The above commands are not starting the log collection even after multiple tries too.
As per the Document, i restarted the platform two times manually, even it doesn't help to collect logs.

PS C:\windows\system32> wpr.exe -boottrace -stopboot BthTracing.etl

    There are no trace profiles running.

    Error code: 0xc5583000

In the below image it shows the commands ran successfully.


OS version details

This is another test

This is another test

A user account is required to confirm the properties of the current Data Collector Set.

Hey,
I'm unable to run usbtrace.cmd

the command

logman update trace -n usbtrace -p Microsoft-Windows-USB-USBXHCI (Default,PartialDataBusTrace,StateMachine)

fails with error

A user account is required to confirm the properties of the current Data Collector Set.
Uma conta de usuário é necessária para confirmar as propriedades do Conjunto de Coletores de Dados atual.

no matter if I run it as administrator or not, but I see that if I run it on a different machine it works.

Works at: Windows Version 1809 (OS Build 17763.737) (en-US)
Fails at: Windows Versão 1903 (Compilação do Sistema Operacional 18990.1) (pt-BR)

Need a readme

All repos should have an explanatory readme that outlines the purpose of the repo as well as how to contribute and get involved.

Bluetooth logging issue

Following the instructions here:

https://github.com/microsoft/busiotools/tree/master/bluetooth/tracing

Trying to run wpr.exe -start BluetoothStack.wprp!BluetoothStack -filemode on Windows 1903 (OS Build 18362.356) or Windows 1809 (build 17763.737)

Results in this error:

The schema for the profile file is not valid.
Element Id: Microsoft.Windows.Bluetooth.BthA2dp
Element Type: EventProvider
Line Number: 669
Column Number: 139
Error code: 0xc5580701

If I roll back the previous version of the wprp file it works fine.
102fd540d7839184ad6d917f7af77562ab562fc6

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Tracing of HCI commands

Hi,
I am pretty new to Windows tools and am playing around with the Bluetooth logger presented in the How to collect Bluetooth logs section. I followed the instructions and noticed the focus on collecting Bluetooth radio information.

My question is if there is a possibility for the WPR to record Windows HCI events and other Bluetooth-related events to for instance the Bthport driver.

Cheers,
Toni Nguyen

How to disable debug mode?

In btvs I once clicked on "Set or Extend Debug Mode" and indeed Windows now uses the debug Diffie-Hellman private / public key pair written at the end of section Core Spec v5.2 Vol 3 Part H Section 2.3.5.6.1.

The problem is that this setting is sticky and, while it can be useful for debugging, keeping this setting afterwards prevents any further pairing on this PC with production devices which implemented the security requirement to not accept this debug key.

Therefore, could you please explain how this sticky setting can be disabled?

Additional related questions/improvements:

• documentation about this button is overall missing (what else does it do?) - probably an information pop-up that is shown when hovering over the button would help.
• how to enable (and disable) this feature directly in WPR?
• rather than a push button, a radio button (or slider) that keeps and shows the current state, and allows to disable this setting, would be welcome.

Does logging persist on sleep/resume?

I have an issue I need to reproduce across sleep/resume and the readme doesn't say if I need to use the "persist on reboot" method or the regular method. Could you add a blurb about which method to use for capturing logs from a sleep/resume state?

SMP Data: first fragments are truncated

The first L2CAP fragments of SMP packets are truncated when capturing HCI logs using WPR or BTVS.

Log 1 (btvs) = DellLatitudeE7240.zip
Captured with Windows 11 on a Dell Latitude E7240 laptop with intel 7260 Bluetooth chip (see report_2021-7-12_19-2-48.txt)
See red and green markers in the HCI overview (Note: because of a sniffer issue they only appear in the Instant Timing view, then one can double click from there on the packet to make them appear in the HCI Injection Overview) : first fragments are truncated, others are not.
Here the air log was captured at the same time and we can map those HCI packets to the L2CAP packets exchanged over the air (yellow markers). Pairing was successful, what was exchanged on HCI was correct, it must be just btvs that truncates the data.

Log 2 (etl) = etl: BthTracing.zip and extracted cfa: BthTracing.btt.zip
Captured with Windows 10 PRO 21H1 on a Dell Vostro 3591 with Qualcomm 11ac QCA 9377 Bluetooth chip, driver version 10.0.0.953
Here we don't have the air logs and this is the problem: we cannot see what the SMP problem was :-(

Note: this is somewhat similar to #85.

This is a test

This is a test.

Dead Link to Microsoft Store

this lists that this is available on the Microsoft store but the link is dead.

How to read the .pnp file exported by PnpUtil?

Is there any document to describe how to read the .pnp file exported by PnpUtil /export-pnpstate?

Thanks.

How can I resolve Provider GUIDs and "<Unknown>" entries in BusesTrace.cmd's InputTrace.etl? (And how do I interpret the saved, but undocumented, events?)

(I am not a hardware developer, I'm using busiotools to investigate weird and sporadic mouse/pointer movement behaviour with USB mice on a couple of my computers - which started in Windows 10 1909 and still affects later Windows 10 builds on multiple machines of mine)

(With respect to the Microsoft Support Policy documented in this repo I have already opened a ($500..., ouch) support ticket with MS Support over this issue, but after months of them being unable to repro the issue at their end they told me to come up with hard, solid, ETL traces that show what I'm observing, so that's why I'm here).

I ran BusesTrace.cmd with the "Input/HID components only" menu option and WPA shows that the saved WPR_initiated_WprApp_InputTrace.etl contains the Microsoft.Windows.Win32kBase.Input/MousePacketLatency and Microsoft.Windows.Win32kBase.Input/MouseLatency events which (as far as I know) show that something ain't right with USB HID mice on my computer judging by the jittery CursorRenderLatency, ProcessMouseInputInputDataLatency, and CursorUpdateLatency field columns for MousePacketLatency events, and the TransferLatency and ProcessInputLatency columns for the MouseLatency events (screenshots below).

However, the saved *.etl file from BusesTrace.cmd is seemingly lacking a lot of human-readable information: only a couple of the named providers have their names resolved, the rest are referenced only by their GUIDs; none of the observed userland processes (as logged by other tracing providers that BusesTrace.cmd added) saved process names, for example; similarly, almost all other Task Names are missing too, so the WPA screen is filled with unhelpful Unknown and <Unknown> strings...

Furthermore, I noticed the MouseLatency and MousePacketLatency events from the Microsoft.Windows.Win32kBase.Input provider aren't documented anywhere (seriously: there are zero Google/Bing/DuckDuckGo search results for the string MousePacketLatency or any of the events' field names like ProcessMouseInputDataLatency), so I'm unsure how to proceed with the data I have from BusesTrace.cmd. I understand that for all kernel ETL events (such as those from Win32kBase) it's possible to capture stack-traces to help narrow-down the cause of certain events, but in this case the data needed for stack-walking isn't included in the ETL - do I need that data to investigate further and if so, how do I capture it? (I did try playing with xperf -on latency -stackwalk Profile but this doesn't play-nice with BusesTrace.cmd - I see that BusesTrace.cmd wraps logman but the whole xperf/logman/wpr/traceview/tracelog/perfview experience is very intimidating and frustrating for the uninitiated - (why so many tools that do the exact same thing?)).

...and as these event types and fields are undocumented how do I interpret it all? (e.g. is ProcessMouseInputDataLatency measured in microseconds or milliseconds or some other unit? How do I interpret the other fields? What is the difference between MousePacketLatency and MouseLatency? How do I combine this with the DWM's SetCursorPosition events in the same WPA timeline?)

---

Update: I tried using tracerpt.exe to export the event definitions, however running tracerpt -l BusesMergedTraces.etl -export busesMergedTraces.xml gave me an almsot empty XML file (with an empty <stringTable> element). Similarly, running tracerpt -l WPR_initiated_WprApp_InputTrace.etl -export WPR_initiated_WprApp_InputTrace.xml gives me only two <template> elements, none of which correspond to the MousePacketLatency and MouseLatency events. I've attached both of those files to this issue (renamed to .txt as GitHub prohibits attaching .xml files for some reason) - see WPR_initiated_WprApp_InputTrace.txt below the screenshots at the bottom.

---

Showing MousePacketLatency events:

Showing MouseLatency events:

---

WPR_initiated_WprApp_InputTrace.txt
busesMergedTraces.txt

ATT data truncated

Issue:
On this PC, all ATT notifications received by the host are truncated when capturing Bluetooth HCI logs via WPR.

Notes:

• this is not an Ellisys import issue because we can already see in the .hci file directly extracted from the .etl file using BTETLParse.exe that the data is already truncated.
• this does not seem to be a BTETLParse.exe issue because, if running BTVS we see the same issue
• this is not an issue with the data being sent: the HID reports in those notifications are well received and interpreted by Windows, so, those ATT packets are complete (we should be able to see that in the air.btt log but here there was an Ellisys sniffer issue)

Let me know if you need additional logs or information.
etl.zip

Add a license

This repo needs to have a clearly identified license (preferably in a file called LICENSE or some such)

MonitorBrightnessApp certificate has expired

https://github.com/microsoft/busiotools/blob/master/sensors/Tools/MonitorBrightnessApp/MonitorBrightnessApp_1.0.40.0_x86_x64_arm.cer

Issued to: jocelynb
Issued by: jocelynb

valid from 3/16/2018 to 3/17/2019

This prevents installation of the monitorbrightnessapp utilities.