--- title: "A method for diagnosing remote access faults" description: "Most remote access faults are diagnosed badly for the same reason: people start changing settings before they know which layer is broken." canonical_url: https://rmm247connect.app/troubleshooting section: "Troubleshooting" product: 247connect product_website: https://www.247connect.cloud/ site: "247connect Knowledge Hub" author: "247connect Marketing Team" date_published: 2026-02-02 date_modified: 2026-08-27 language: en-GB license: Quotation and citation permitted with attribution to 247connect. --- # A method for diagnosing remote access faults ## Key figures - **Isolation model:** 4 layers - **Most common cause:** Network - **Second most common:** Agent state - **Typical time to isolate:** Minutes ## Work down the layers, not through the settings Most remote access faults are diagnosed badly for the same reason: people start changing settings before they know which layer is broken. A black screen, a session that drops, and a device that never comes back after a reboot are three different problems, but they get the same scattergun response of toggling options until something changes. That fixes the symptom occasionally and teaches you nothing. A faster method is to isolate in a fixed order. Confirm the network path first, because it explains the largest share of failures. Then the agent: is it installed, running, and reporting? Then the session: does it establish and stay up? Only then the display and input layer, which is where black screens, cursor problems and multi-monitor oddities live. Each step is a question with a yes or no answer, so you always know where you are. - Network: can the endpoint reach the broker at all, and is anything inspecting or blocking the traffic? - Agent: is the service running, is it a current version, and did it survive the last reboot or update? - Session: does it establish, authenticate, and stay connected under load? - Display and input: is the screen being captured, and are keyboard and mouse events reaching the desktop? ## The causes that account for most tickets Across the failures documented in these guides, a small set of causes recur. Security software that inspects or blocks the agent's traffic after an update. Power settings that suspend a machine before anyone tries to connect. A session running against a secure desktop or a locked screen that the agent is not permitted to capture. Graphics drivers and hardware acceleration on machines that have just been updated. And a device that came back from a reboot without the service starting because it was installed for a user rather than for the machine. None of these are exotic, which is the point. Isolating the layer first turns a vague fault into one of a handful of known causes, and each of those has a specific fix rather than a workaround. ## Record the fix, not just the outcome The difference between a team that gets faster at this and one that does not is whether the resolution is written down in a form the next person can search. A ticket that says resolved teaches nobody. A ticket that says the endpoint agent was blocked by an endpoint protection update, and the fix was an allow rule for the agent service, prevents the next four tickets. The guides here are structured to be reusable in exactly that way. ## The isolation sequence 1. **Confirm the endpoint is powered, awake and online** — Check the last check-in time rather than assuming. A device that is asleep, hibernating or off the network looks identical to a broken agent from the console. 2. **Check the agent service state and version** — Confirm the service is running under the machine rather than a user, and that it is a supported version. Reboots and updates are the two events that most often change this. 3. **Test whether the session establishes at all** — A session that never starts points at network, authentication or agent state. One that starts then drops points at bandwidth, power management or an inspecting security product. 4. **Only then look at display and input** — Black screens, frozen cursors and missing monitors are almost always capture-permission, driver or secure-desktop issues, not connectivity problems. ## Frequently asked questions ### Why does a remote desktop session keep disconnecting? Most repeated drops come from three causes: unstable or saturated upstream bandwidth at the endpoint, power management suspending the network adapter or the machine, or a security product inspecting and eventually interrupting the agent's connection. Isolate by testing on a wired connection with sleep disabled before changing anything else. ### Why do I get a black screen in a remote session? A black screen almost always means the session connected but the agent cannot capture what is on the display. Common causes are a secure desktop such as a login or elevation prompt, hardware-accelerated graphics after a driver update, or a monitor that is powered down on a physical machine. It is a capture problem, not a connectivity one. ### Why is a device offline after a reboot? The agent did not start with the machine. That usually means it was installed in a user context rather than as a machine-level service, an update left the service disabled, or the device requires a sign-in before networking is available. Check the service startup type before reinstalling. ### How do I tell a network fault from an agent fault? Test something else on the same endpoint. If other traffic from that device works while the agent stays offline, the fault is local to the agent or to something filtering it. If nothing reaches out, it is the network path, and no agent setting will fix it. ## Where 247connect fits 247connect reduces the agent-state class of failure with reboot and automatic reconnect, plus hardware inventory and check-in times in the console, so you can see whether a device is offline or simply asleep. --- Source page: https://rmm247connect.app/troubleshooting Product website: https://www.247connect.cloud/