Lesson 1: Triage the Whole System

A user says:

My laptop cannot connect to anything.

What domain is that?

Networking?

Maybe.

Mobile hardware?

Possibly.

Windows?

Could be.

Security policy?

Also possible.

The wrong move is deciding the category before you know what connect means in this case.

Triage turns a vague report into a system boundary

Ask:

• Connect to what?
• Over which interface?
• What worked previously?
• What still works now?
• Did anything change?
• Is one user affected or many?
• Is there an approved workaround?
• Is there a safety, data, or security risk that changes the normal workflow?

The goal is not to interrogate the user with twenty questions.

The goal is to stop one vague word from controlling the diagnosis.

Diagrams open at a readable shape-aware scale. Zoom or expand when you need more detail.

Visual reference

See the system before you troubleshoot it

reference sheetEvidence-First Troubleshooting Workflow

System process animation

The technician diagnostic loop

Move from intake to evidence, theory, controlled test, correction, verification, and documentation.

RestartPreviousPlay sequenceNext

1. 1IntakeRestate function, scope, impact, and change.
2. 2BaselineRecord state before modifying it.
3. 3EvidenceCollect observations that separate layers.
4. 4TheoryName one explanation that predicts evidence.
5. 5Controlled testTest one variable with an expected result.
6. 6CorrectApply the least-disruptive authorized fix.
7. 7VerifyRetest original function and dependencies.
8. 8DocumentRecord evidence, outcome, risk, and follow-up.

Technician question: Where does the loop return when a prediction is disproved?

Scope is one of the strongest pieces of evidence you can get quickly

Compare these incidents.

One endpoint fails

one laptop: cannot reach shared printer
other laptops: print normally
printer: healthy for other users

The shared printer and much of the network are already proving useful function.

Start near the affected endpoint.

Everyone fails

all wired and wireless clients: cannot reach shared printer
printer display: offline / network link down

Now the scope shifts toward the printer or its shared network path.

Same user-facing symptom.

Different architecture.

Positive evidence is as important as failure evidence

Technicians often write down what failed and ignore what succeeded.

That throws away half the map.

Suppose:

laptop powers on
Windows boots
Wi-Fi associates
IP address is valid
local printer responds
remote websites fail by hostname
remote test IP responds

What works?

A lot.

Hardware, Windows startup, wireless association, IP configuration, local networking, gateway/remote IP path all have positive evidence.

The failure has climbed high enough that DNS becomes a much stronger boundary.

Do not restart the router because the user said "internet."

Recent change is not proof, but it changes probability

A workstation worked yesterday.

Today it fails immediately after:

• RAM upgrade;
• graphics-card installation;
• VPN profile update;
• printer-driver update;
• browser extension install;
• cloud application policy change.

The change does not automatically equal the cause.

It does give you a useful comparison point:

What part of the system changed immediately before the symptom appeared?

That can make the next test smaller and safer.

Build a boundary map before choosing a tool

A general endpoint path can look like:

power / hardware
      ↓
firmware / boot
      ↓
operating system
      ↓
local identity / policy
      ↓
network interface
      ↓
IP / gateway / DNS
      ↓
remote service
      ↓
application / data

You do not always start at the bottom.

Start at the last boundary the evidence already proves.

If Windows is running, do not pretend the CPU has not been proven to execute instructions at all.

If the application can reach its server but authentication fails, do not start by testing the Ethernet cable.

Incident 1: black screen after GPU service

Evidence:

system power: on
case fans: spinning
monitor: powered
monitor: No Signal
recent change: GPU removed and reinstalled

Possible theories:

• wrong display output;
• GPU not seated;
• GPU supplemental power missing;
• RAM disturbed during service;
• monitor input wrong.

What should you avoid?

Replace motherboard.

That is a large conclusion with weak evidence.

Stay near the changed graphics/display path first.

Incident 2: cloud app login fails, normal web works

Evidence:

endpoint: healthy
internet: works
DNS: works
cloud app: reaches sign-in page
credentials: accepted
license/entitlement: missing in supplied state

This is not an internet outage.

The failure is above networking and authentication.

The entitlement boundary is first unproven or failed.

Incident 3: printer works for everyone except one PC

Evidence:

printer internal test: good
other users: print normally
problem PC: garbled output
problem PC driver: wrong model

The printer hardware has already passed several useful tests.

A client driver/page-description problem is much stronger.

Do not replace toner because the characters look wrong.

Incident 4: files disappear after sync

Evidence:

file deleted on one synchronized endpoint
sync status: healthy
deletion propagates to other devices
version recovery: available

Did synchronization fail?

No.

It worked exactly as configured.

The support problem is recovery from an unwanted state.

That distinction changes the action completely.

Incident 5: VM and host both slow

Evidence:

host memory: 98%
host paging: heavy
three VMs: all slow
new VM started before symptom

The shared host resource pool is the strongest boundary.

Do not debug three guest operating systems independently before checking the common dependency.

Scope beats repetition.

Build five triage cards

For five supplied incidents, write:

user report
what the user actually needs
scope
recent change
known-good boundaries
first failed / uncertain boundary
three plausible theories
one theory already weakened by evidence
smallest useful next evidence
safety / privacy / data concern

Do not identify the CompTIA domain until after the triage is complete.

Before you move on

A technician who categorizes too early starts testing the course syllabus instead of the system.

Triage first.

Find the boundary.

Then choose the evidence that can actually answer the next question.