High CPU
Complaint: “My computer is crawling.”
Evidence gathered: current load as a percentage per process (not cumulative CPU seconds, which is a common misreading), kernel time against user time, interrupt and DPC load, and recent errors in the System log.
Typical outcomes: a servicing or antivirus scan that should be left to finish, a runaway application to restart after the user saves, or a driver problem it hands to a person. It does not end security software or system processes. The full procedure is published, along with process-specific write-ups for lms.exe, LocalServiceNoNetworkFirewall and csrss.exe.
A service that will not stay running
Complaint: an application reports it cannot connect, or a feature silently stopped.
Evidence gathered: the service's state, start mode and dependencies, the Service Control Manager entries explaining why it stopped, and whether anything it depends on is down.
Typical outcomes: start the dependency first, correct a start mode that was left on Manual, or report a crash loop with the faulting module. After the fix it checks the service stays up, not just that the start command succeeded.
“The internet is down”
Complaint: no website loads.
Evidence gathered: adapter and link state, whether a raw IP address is reachable, whether names resolve, and which resolver the machine is actually asking.
Typical outcomes: correct a resolver that points at nothing, renew a lease, or report that the fault is upstream. There is a real unedited example with timestamps, and a step-by-step guide.
Printers
Complaint: jobs are queued and nothing prints.
Evidence gathered: spooler state, the queue contents, the printer's port and whether it answers, and driver errors in the event log.
Typical outcomes: clear a stuck queue after warning that queued documents are lost, or point at a driver or sharing-permission fault that needs a person. See the print spooler guide.
Windows Update that will not finish
Complaint: an update fails or the machine reports a pending restart forever.
Evidence gathered: the real pending-restart indicators, the update history, the servicing logs and the error code. Many of these alerts turn out to describe something that already resolved, and a stale alert is reported as exactly that instead of being “fixed”.
Typical outcomes: a restart scheduled with a visible warning rather than an immediate one when someone is signed in, or a hand-off when the error needs a servicing repair a person should oversee.
What it cannot do from a distance
Failing memory, a dying disk and a bad cable all look like software problems from the inside. The agent recognises the patterns that suggest hardware, says so, and recommends the physical check instead of looping through software fixes.