I built a lightweight, read-only diagnostic dashboard to investigate intermittent Windows 11 hardware crashes, TPM problems, and Kernel-Power Event ID 41 restarts. The project started after my PC began showing black screens followed by unexpected reboots, and I wanted a faster way to correlate security telemetry, hardware information, and relevant event logs.
The tool uses PowerShell to collect system and security data, clean Measured Boot logs, filter noisy Windows events, and generate a local HTML report using Vue.js 3 and Tailwind CSS. The Measured Boot files can contain null bytes and malformed concatenated JSON objects, which causes standard ConvertFrom-Json processing to fail. The script currently applies regex-based cleanup before parsing the data.
The project runs entirely from source without compiled executables or external network requests. It supports both PowerShell 7 and Windows PowerShell 5.1, copies small local frontend dependencies to the temporary directory, and can export a Markdown report or save the collected session data as JSON.
The main files are Launch-Diagnostics.bat, Run-Dashboard.ps1, and template.html. I designed the architecture and tested the tool locally, using AI assistance while writing parts of the PowerShell code. I would appreciate feedback on the JSON-building approach, Measured Boot cleanup logic, memory-type detection, and any other PowerShell improvements that would make the wrapper more reliable and maintainable.
3 Answers
Avoid assembling the top-level JSON payload by interpolating JSON strings. Build one PowerShell object or hashtable containing the original data objects, then call ConvertTo-Json once at the end with an appropriate depth, such as 10. This handles escaping and nested structures correctly and keeps the data usable for other processing.
It is also worth initializing each section with a fallback value like @{ Error = 'No data' } before querying the system. If a CIM call or event-log query fails, the dashboard can still render a complete response and clearly identify which section was unavailable.
For the TPM section, there is no need to manually construct a hashtable just to serialize the result. You can keep the object returned by Get-Tpm and pass it through ConvertTo-Json, applying the character cleanup only to ManufacturerVersion if needed. That reduces the amount of repetitive mapping code and makes it less likely that a TPM property gets left out later.
Also, the memory type should not be inferred from the clock speed. DDR3, DDR4, and DDR5 speeds can overlap because of overclocking, firmware settings, and reporting differences. Use the SMBIOS memory type value exposed by the memory module data instead. Mapping the SMBIOS numeric codes to names will give you a much more dependable result.
The overall idea is useful, especially having the same collected payload available both to the HTML interface and as a standalone JSON file. I would focus next on making failures explicit and avoiding assumptions about hardware values. A structured payload with consistent defaults will make the frontend much easier to maintain than a collection of partially formed JSON fragments.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures