User guide

Use in-application help

Open Help and Documentation to browse every installed application guide and an individual article for each discovered module. Search covers tool names, immutable module IDs, categories, parameters, tags, symptoms described by module authors, and the full application guides. Select a category and article in the topic tree to read it without leaving the toolkit.

Module articles always include purpose, how to launch the tool, parameters, local and remote support, risk, permissions, confirmation behavior, timeout, transports, and result-review guidance. Modules may also contribute detailed Markdown about evidence, interpretation, limitations, and follow-up actions. The Module developer guide and Help article authoring topics explain how to build modules and integrate future help content.

Remote dashboard actions

When a remote target is selected, the dashboard displays Remote control, Restart, and Shut down shortcuts. Remote control asks for confirmation, discovers Configuration Manager’s CmRcViewer.exe, and launches it with the selected device address. Power controls launch the same installed modules as the Troubleshooting Modules page: parameters are reviewed first and a separate confirmation is required before any power request is sent. Restart and shutdown enforce at least a 30-second warning period.

Startup and logon timing traces

Run Windows Startup and Logon Trace Management with install for the affected local or remote device. After confirmation, it stages a runner under C:\TEMP\WindowsLogonTimingTrace and registers a bounded all-users At Log On task. The next sign-in records shell arrival, user-session process snapshots, startup items, mapped resources, relevant scheduled tasks, Group Policy/profile/Winlogon and startup-performance events, and a GPResult report. The default observation window is five minutes.

After reproducing the slow sign-in and waiting for the observation window to complete, open Log Collection and run Windows Startup and Logon Trace Collection. The collector downloads the trace files and focused EVTX channels, then adds Findings for delayed or missing Explorer, logon warning/error events, incomplete network context, and the highest CPU-growth startup processes. Use the management module’s status action to check the latest run or remove to unregister the task. Removal preserves existing logs by default.

Find and run modules

The Troubleshooting Modules page groups modules into category tabs. Choose All or a category, then use search and risk filters within that tab. Tiles still display category, risk, version, source, and hover help; selecting a tile opens any parameters and required confirmation before it runs.

Active Directory user report

Run Active Directory User and Session Report for a local or connected remote target. By default it uses the interactive user reported by the selected machine; a user override can be supplied. The report runs on the technician workstation because that is where RSAT is expected. If the ActiveDirectory PowerShell module is missing, the result explains that the RSAT AD DS/LDS tools must be installed. Returned findings summarize contact/organization fields, two leadership levels, account/password/logon state, direct groups, and loaded-profile/session evidence without modifying AD.

Collect logs and use CMTrace

Open Log Collection, select a category-focused collector, and choose the lookback and maximum archive size. Completed archives appear on the task result’s Attachments tab. Exporting a ZIP support bundle also includes those archives. Use Open local log in CMTrace to select a local .log or .txt file; the toolkit discovers CMTrace from the managed-client and admin-console paths. Log-collector results also include a Log Files tab. Double-click a file or select it and use the open button. Saved Windows Event Logs (.evtx) open in Windows Event Viewer. For other collected files, the toolkit uses CMTrace when detected and falls back to Windows Notepad otherwise. Collected ZIP archives are saved persistently in C:\TEMP by default. This machine-scoped location avoids profile and ownership mismatches when the toolkit is launched with an alternate elevated account. The effective directory is shown on the Log Collection and Application Settings pages.

Windows system, endpoint management, networking, printing, CrowdStrike, and GlobalProtect collectors run locally or against a connected WinRM target. Remote collection occurs on the selected endpoint; the bounded ZIP returns through the remoting channel and is expanded inside the protected local task workspace for the Log Files tab. The interactive Chrome diagnostic session remains local-only because WinRM does not provide access to the signed-in user’s browser desktop.

Administrators can override the archive directory with paths.downloads in enterprise.json or machine.json; users can set it in preferences.json when the setting is not enterprise-locked. An empty value selects C:\TEMP on Windows. Absolute paths are recommended. Configuration may use ${ENV:USERPROFILE} because USERPROFILE is included in the default environment allowlist. Restart the application after changing this path.

The Chrome collector asks for confirmation because it opens a visible browser and makes outbound requests. It uses a temporary profile, visits only the destinations shown in the confirmation and result metadata, and captures both a verbose Chrome log and a bounded network log. The dashboard’s Chrome cards summarize registry policy names and locally installed extensions without displaying policy values. In the run dialog, enter optional additional troubleshooting destinations one per line. Only complete HTTP or HTTPS URLs are accepted; duplicate and built-in destinations are removed. Avoid URLs containing credentials or sensitive query values because requested URLs can appear in the logs.

Chrome NetLog uses intermediate segment files while capture is active. The toolkit requests a normal browser close so Chrome can create the final JSON file. If shutdown is interrupted, the toolkit attempts to stitch those segments automatically and clearly reports whether the network log is complete or only partially recovered.

After capture, the Chrome collector performs deterministic local analysis. It recognizes a conservative set of actionable signals such as PAC fallback, deprecated external-extension deployment, denied access to machine extension sources, unsuccessful configured destinations, and a NetLog that reached its size ceiling. Each configured HTTP/HTTPS destination receives an individual test result. Generic error counts remain summary evidence because Chrome pages routinely produce harmless component, advertising, and shutdown errors. Log contents are not sent to a cloud service, and findings do not expose full URLs, query values, registry values, tokens, or raw log lines.

Start and choose a target

Run python -m muon_insight from a prepared source checkout, or launch Muon Insight from the Start menu or MuonInsight.exe from the portable distribution. Choose This computer for local work or enter a computer name/FQDN for a managed remote Windows device. The toolkit automatically tests DNS, the configured WinRM port, WS-Management, and remote PowerShell authorization using the signed-in Windows identity. Open Connection Tests for the individual results and evidence.

Remote support requires enterprise WinRM policy and an account authorized for PowerShell remoting on the target. The toolkit does not enable WinRM, add TrustedHosts entries, change firewall rules, or ask for/store a Windows administrator password. Prefer a computer name or FQDN on a domain network; Kerberos authentication to a raw IP address is normally unavailable. A successful connection populates the dashboard with a read-only remote Windows, capacity, uptime, Chrome-policy, and accessible-extension summary. Remote CPU and memory are periodic snapshots rather than continuous performance-counter streams; the default refresh interval is 30 seconds and can be set from 10 to 300 seconds with remote.refresh_interval_seconds. The top-bar Refresh button requests a complete snapshot immediately.

Only modules whose manifests explicitly declare both remote support and the winrm transport are staged and run remotely. Other modules fail closed instead of running against the technician’s computer. ServiceNow continues to use selected-target API context and does not require WinRM.

The bundled General System Health and Group Policy Troubleshooting packs are remote-ready. Their read-only modules collect and evaluate evidence on the selected WinRM target. Actions remain separate: Force Group Policy Refresh is intentionally local-only and is never included implicitly.

For packaged releases, copy the versioned ZIP as a single file and extract the complete MuonInsight folder before launching the executable. Do not copy the executable by itself or launch it while a cloud-sync client is still materializing the folder. The adjacent .sha256 file can be used to verify the ZIP before extraction.

The top bar always shows target locality, connection state, current user, and elevation context. Use Change target at any time. The dashboard refreshes local CPU and memory every three seconds; pause monitoring when sampling is unwanted.

The ServiceNow Asset Intelligence integration is target-context aware: it can query either the local computer or a selected remote computer without connecting to Windows on that device. Before first use, open Application Settings and store an API-authorized ServiceNow account. The password is saved in Windows Credential Manager for the current Windows user. The enterprise instance and CMDB table remain centrally configured; collection membership is not used.

The dashboard places overall health in a full-width summary banner. When attention is required, the banner names the actual conditions—such as low disk space, a pending restart, a Device Manager error, or degraded battery capacity—instead of asking you to inspect the remaining cards. The Health checks card shows the individual bounded checks and, on portable hardware, current charge and full-charge capacity compared with design capacity. The Current user card uses RSAT on the technician workstation to show the interactive user’s selected AD contact, role, manager chain, and account state. Missing RSAT, no interactive user, or unavailable firmware telemetry is labeled explicitly and is not treated as an endpoint failure. Chrome, extended health, battery, and directory details are collected asynchronously so the rest of the dashboard remains responsive. Both light and dark themes use the same grouped layout.

Run a module

Open Troubleshooting Modules and select a module tile to run it. Hover for about two seconds to see a short, bounded description. Search by name, description, or tag, and combine the category and risk filters to narrow the tile view. Log collectors are intentionally excluded from this page and appear only under Log Collection. An action or volatile module shows the affected target, risk, restart/disconnection information, reversibility note, and required permissions. Read the warning before confirming.

When a module declares parameters, the toolkit displays a single parameter dialog using the controls specified by its manifest. Parameters may be numbers, text, one-item-per-line lists, checkboxes, or choices. Defaults and limits are owned by the module manifest, so installed third-party modules use the same UI and validation as included modules.

For Group Policy issues, run Group Policy Health first locally or against a connected WinRM target. It checks domain and secure-channel posture, policy shares, services, reboot/time state, AVD indicators, and recent correlated events without making changes. Force Group Policy Refresh is a separate confirmed action because policy reapplication can run organization-defined scripts, software deployment, and client-side extensions. It requires an elevated local administrator and does not automatically reboot or log off the user.

For Windows integrity issues, start with Windows Servicing Readiness because it is fast and does not require elevation for its available evidence. Run the DISM, SFC, or CHKDSK module individually when the symptom warrants a longer elevated scan. These diagnostics intentionally perform verification only: they do not repair the component store, replace system files, modify the file system, schedule an offline repair, restart Windows, or alter services. Review their findings before choosing a separately authorized remediation workflow.

For endpoint administration, begin with the new read-only modules: Device Driver Health, HOSTS File Diagnostics, Windows Installer Diagnostics, Windows Update Diagnostics, and Intune and SCCM Co-management Diagnostics. Their Findings cards expose the individual problem devices, active HOSTS overrides, service/policy/reboot state, relevant management artifacts, and bounded recent events. They do not install drivers, edit HOSTS, scan/install updates, change enrollment, or repair services.

The matching Installer and Windows Update repairs are separate confirmed actions. Update repair can rename SoftwareDistribution and catroot2 to timestamped rollback paths, but never deletes the old caches or starts a scan, installation, or reboot. Managed Application Uninstall loads a searchable, UninstallView-style inventory from the selected device. It shows application, version, publisher, uninstall GUID, type, and remote-safety status. Double-click a selectable row or choose it and press Select. MSI entries are resolved by their exact product-code GUID and removed through Windows Installer. For EXE entries, the toolkit inspects the registered install location for a credible vendor uninstall utility and requires a matching registered quiet command. Unsupported EXE rows remain visible with an explanation but cannot be selected. Protected products and stale identities are refused again immediately before execution.

Move Computer to Active Directory OU loads a searchable, hierarchical OU tree through local RSAT. The tree begins at the enterprise-approved move root and contains only that OU and its descendants; expand its nodes, then select the destination like ADUC. The action independently refuses any selected or crafted destination outside that scope. Manage Local Administrator Membership loads all qualifying users visible on the selected device, including the interactive user, enabled local accounts, profile-backed users, and direct Administrators members. Its account field is read-only and can only be filled by the picker. Both actions read the result back before reporting success, and local Administrators changes retain critical confirmation.

Resource lists are loaded in the background and are refreshed for the currently selected target each time the action is opened. These live selections are deliberately available only for individual module runs; the application does not store a potentially stale application, user, or OU selection in a pack.

The first-wave hardware and repair modules are all target-aware. Battery Health, SSD and Physical Disk Health, and DNS Registration and Mismatch Check are read-only and can be included safely in packs. Repair DNS Cache and Registration, Trigger Configuration Manager Client Actions, and Clear Print Spooler Queue remain separate confirmed actions. The spooler action permanently discards queued jobs; the Configuration Manager action never triggers software inventory; the DNS action never resets adapters or renews DHCP.

Running Tasks shows status, progress, current stage, target, and controls. Cancel requests a safe cooperative stop. Use Force stop only after cancellation does not complete; it terminates the child process tree. View opens summary, findings/evidence, and raw structured output.

Run a pack

Open Troubleshooting Packs, review scope and included modules, then run it. Dependency-ready modules can execute in parallel. A failed prerequisite causes its dependent modules to be skipped, not run with incomplete input.

Select New pack to create a per-user troubleshooting pack, or select a bundled pack and choose Customize selected to create an editable override. The editor lists every installed diagnostic, action, integration, analyzer, and log-collection module. Check any combination to include it; use the module filter to narrow the list. Select Configure selected module to store non-secret parameter values such as lookback days, collection size, or optional Chrome destinations in the pack. Modules that require a live target resource selection are labeled Run individually and cannot be added to a pack.

Pack risk is calculated from the selected modules and cannot be lowered manually. Running a pack that contains an action, volatile module, explicitly confirmed module, or high/critical-risk module displays a pack-level confirmation before anything is queued. Normal module authorization, target support, timeouts, cancellation, and result handling still apply to each module in the pack.

Custom definitions are stored under the current user’s toolkit data directory in packs. Editing a built-in pack does not change the packaged JSON; it creates an override with the same pack ID. Choose Restore built-in pack to remove that override. Packs created with New pack can be removed with Delete custom pack.

The pack details show whether the complete installed pack supports local targets, remote targets, or both. The editor also shows target support for every module. A pack containing any local-only module, including interactive Chrome log collection, is local-only; the application blocks it before queuing work on a remote target. It never substitutes the technician’s computer for an unsupported remote module.

Export a report

After modules complete, open Reports and select HTML, JSON, CSV, or ZIP. HTML is a standalone branded report; CSV contains findings; JSON retains normalized data; ZIP includes all three plus a SHA-256 manifest. Saved credentials are never included. The default privacy profile redacts secrets; administrators can enable additional email, IP, and path redaction.

Interpret findings

Findings are deterministic correlations, not cloud-AI conclusions. Read the evidence and validate the recommendation against the reported symptom. Every completed structured module now includes an Assessment overview in the Findings tab. When a module does not publish its own findings, the app also promotes up to three important test results into concise findings and summarizes partial-data limitations. Module-authored findings remain the authoritative remediation guidance, while the generated entries make healthy results, informational integrations, and log collections easier to interpret. The raw module output is not changed by this display and reporting layer. Wording such as “possible contributor” intentionally avoids claiming an unconfirmed root cause. Use the task correlation ID when escalating an error.

Run one check across several computers

Multi-Target Run answers questions about a group rather than a machine: whether a patch is missing across a floor, or whether a fault a user reports is theirs alone.

Choose a module, paste the computer names one per line, and run. Only modules that genuinely execute against a named remote computer are offered, because a local-only module would evaluate this machine once per name and look like agreement.

Each computer produces its own task and its own result, so one unreachable machine neither hides nor blocks the others. Results appear in Running Tasks, are recorded in Task History, and can be selected there and exported into a single report for comparison.

Compare results across computers

In Task History, select several runs of the same module and choose Compare selected. Rows are the module’s own checks and columns are the computers, so a check that disagrees stands out instead of having to be remembered while reading each result in turn. Rows that do not agree are highlighted, and a check one computer never reported shows as missing rather than being dropped – an absent check is itself worth seeing.

Comparison lines up one module’s checks, so the selection must be of a single module.

Check what you are allowed to run

Application Settings shows your effective access under Access and permissions: who you are signed in as, whether the toolkit is running as administrator, whether you administer this computer, and which modules are unavailable, with the reason.

It is recalculated whenever the target changes, because access depends on where the work runs. The toolkit always runs as administrator on this computer. On a remote computer, modules run under the account used to connect, and modules that change that computer confirm it has administrator rights there before making any change.