List the Windows event logs that contain records.

Use this to discover which log to query. Names like "System", "Application" and "Microsoft-Windows-Kernel-Power/Operational" are what query_event_log expects.

Args: name_filter: Optional wildcard, e.g. "Kernel" or "Microsoft-Windows-Diag*".

Read events from one log with the usual filters applied.

Args: log_name: Log to read, e.g. "System", "Application", or a channel name such as "Microsoft-Windows-Diagnostics-Performance/Operational". hours: How far back to look. Use a larger window for rare crashes. levels: Severity filter — 1 critical, 2 error, 3 warning, 4 information. event_ids: Restrict to specific event IDs. providers: Restrict to specific event sources, e.g. ["Microsoft-Windows-WHEA-Logger"]. contains: Keep only events whose message contains this text. max_events: Maximum events to return, newest first. message_limit: Characters of each message to keep.

The Security log requires an elevated server process; other logs do not.

Every critical and error event from the System and Application logs, explained.

This is the right first call for "why did my PC crash". It picks up bug checks, unexpected restarts, WHEA hardware errors, display driver resets, disk and file system errors, application crashes and hangs, then labels the ones with a known meaning.

Args: days: How far back to scan. max_events: Maximum events per log. include_noise: Keep entries that are known to be harmless (DCOM 10016).

The data behind Reliability Monitor: crashes, hangs, failed updates and driver problems.

Useful for spotting when trouble started, because it lines up software installs and updates against failures on the same timeline.

Boot and shutdown timings, plus what specifically slowed them down.

Windows measures every boot and records which applications, services and drivers took longer than expected. Slow boots almost always have a named culprit here.

List crash dumps on this machine, newest first.

Covers kernel minidumps (C:\Windows\Minidump), the full dump (MEMORY.DMP), live kernel reports — which are written when a driver hangs and recovers without a blue screen — and application dumps under %LOCALAPPDATA%\CrashDumps and Windows Error Reporting.

Pass a path from here to inspect_crash_dump.

Read a dump file's headers and report what crashed.

For a kernel dump this returns the bug check code, its four parameters and what they mean — the same information the blue screen showed.

For an application dump it returns the exception code, the faulting address, and the module that address belongs to, which is normally the answer. It also flags overlay and anti-cheat modules loaded into the crashed process, since those are a frequent cause of game crashes.

Only header structures are read, so this is fast even on a multi-gigabyte MEMORY.DMP. Full stack analysis still needs WinDbg.

Args: path: Absolute path to a .dmp file, from list_crash_dumps. include_modules: Also return the complete loaded-module list.

List Windows Error Reporting reports, newest first.

Every application crash and hang leaves one of these even when no dump file was kept, so they are often the only remaining record.

Read one Windows Error Reporting report.

Returns the problem signature: the faulting application and version, the faulting module and version, the offset into it, and the exception code with its meaning.

Args: path: Path to a .wer file, from list_error_reports.

Page file configuration and how Windows is told to write crash dumps.

Worth checking whenever a blue screen was reported but no dump exists: a disabled page file, a page file on a different volume, or dump collection set to "none" all prevent one from being written.

What this machine is: Windows edition and build, uptime, CPU, RAM, board and firmware.

Start here. The build number decides which known issues apply, and the uptime tells you whether a "fix" has actually been through a reboot.

Graphics adapters, driver versions and dates, VRAM and the current display mode.

The driver version and date are the first thing to check against a VIDEO_TDR_FAILURE or a game that crashes on launch.

Connected monitors and the resolution and refresh rate each is being driven at.

A monitor running at 60 Hz when it supports more, or a mismatch between monitors, explains a lot of reported "stutter".

Installed RAM modules: size, rated speed, configured speed and part numbers.

Modules running below their rated speed mean XMP/EXPO is off; mixed speeds or a configured speed above the rating point at an overclock, which is the usual suspect behind MEMORY_MANAGEMENT and WHEA bug checks.

Disks, their SMART-derived health counters, and free space per volume.

Wear level, reallocated sectors and read errors here explain KERNEL_DATA_INPAGE_ERROR, stutter during loading screens and failed updates. A system volume below roughly 10% free also blocks crash dumps.

Installed drivers with versions and dates, newest first.

Args: name_filter: Substring matched against device name and provider. device_class: Substring matched against the device class, e.g. "Display", "Net", "System". third_party_only: Exclude drivers provided by Microsoft. unsigned_only: Only drivers without a valid signature. max_items: Maximum rows to return.

A driver dated years before the rest, or an unsigned one, next to a recent bug check is worth investigating first.

Devices Windows reports a problem with, with the Device Manager code decoded.

Code 43 on a GPU, code 10 on a controller and code 28 for a missing driver are the ones that most often explain a hardware failure.

ACPI thermal zone temperatures, throttling state and fan status.

Coverage depends entirely on the firmware. Many desktop boards report nothing, in which case an empty result means "not exposed", not "cool".

An instantaneous read of CPU, memory, disk and GPU utilisation.

Includes the numbers that matter for stutter rather than throughput: time spent in DPCs and interrupts, the processor queue length, hard page faults, disk queue depth and per-engine GPU utilisation.

This is a single sample. Call it a few times while reproducing the problem rather than reading one snapshot as a trend.

Running processes with CPU, memory, I/O and their executable paths.

Args: sort_by: "cpu", "memory" or "handles". top: How many rows to return. name_filter: Substring matched against the process name.

Everything that starts with Windows: Run keys, the Startup folder and logon tasks.

The practical list to work through when boot is slow or something is interfering with games in the background.

Windows services with their state, start mode and the account they run as.

Args: state: "Running", "Stopped" … start_mode: "Auto", "Manual", "Disabled". name_filter: Substring matched against the service and display name. failed_only: Only automatic services that are not running — i.e. things that should have started and did not.

The active power plan and the detail of one of its subgroups.

Processor minimum/maximum state, PCI Express link state power management and USB selective suspend are the settings that most often cost frames or cause devices to drop out.

Args: section: One of processor, pcie, disk, display, sleep, usb, graphics. Use "all" for every subgroup of the active plan (long output).

Which sleep states the firmware supports and what is blocking the others.

Relevant to DRIVER_POWER_STATE_FAILURE and to machines that wake up on their own or fail to resume.

Network adapters, drivers, IP configuration and the latency-relevant settings.

Interrupt moderation, energy-efficient Ethernet, receive-side scaling and TCP auto-tuning all show up here; they matter for online play far more than raw bandwidth does.

The Windows settings that affect games, read from the registry.

Game Mode, Game Bar and background recording, hardware-accelerated GPU scheduling, multiplane overlay, the display driver timeout, variable refresh rate and Auto HDR, the multimedia scheduler's reservations, CPU quantum and power throttling — with each value explained and "not set" distinguished from "set to zero".

Per-application GPU preferences and compatibility shims.

Shows which executables are pinned to a specific GPU and which have fullscreen optimisations, DPI overrides or compatibility modes applied — the usual explanation for one game behaving differently from the rest.

Virtualisation-based security, memory integrity, CPU mitigations and antivirus state.

These are the settings behind "my whole machine got slower after an update". Memory integrity and VBS in particular cost measurable performance in CPU-bound games and are switched on by default on many recent installations.

Installed applications, read from the uninstall registry keys.

Args: name_filter: Substring matched against the name and the publisher. max_items: Maximum rows to return.

Overlay tools, RGB and fan utilities, VPN clients and old antivirus products are the software most likely to be involved in a crash, so it is worth scanning this list when a dump names an unfamiliar module.

Installed updates and recent Windows Update activity, newest first.

Line the install dates up against the date problems started; a cumulative update or a driver delivered through Windows Update is a common trigger.

Read every value under a registry key.

Args: path: Full key path, e.g. "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers". Hives may be abbreviated: HKLM, HKCU, HKCR, HKU, HKCC. view: "native", "64" or "32" to choose the registry view on 64-bit Windows. include_subkeys: Also list the immediate child key names.

The key is opened for reading only. Binary values are returned as hex and truncated. A key that does not exist is reported as such rather than failing, since absence is often the answer.

Read a single registry value.

Args: path: Full key path. name: Value name. Use "" for the key's default value. view: "native", "64" or "32".

Prove that this server cannot modify the machine.

Scans the server's own installed source — every Python module and every PowerShell script it ships — for write APIs, mutating cmdlets, shell escapes and dynamic code execution, and reports what it allows.

Run this if you want to confirm the guarantee against the code that is actually installed rather than take the documentation's word for it.

Whether this server can reach the Windows data sources it needs.

One call that gathers the usual starting point for a diagnosis.

System overview, GPU and drivers, memory modules, storage health, problem devices, crash dumps present, recent critical events, the gaming settings and a performance sample — each section independent, so one unavailable data source does not lose the rest.

Follow up with the specific tools for whatever looks wrong.