Troubleshooting Hardware, Networks and Software

A useful diagnosis starts with a clear description of the failure. “My computer is broken” leaves almost everything open; “the laptop shuts down during a video call after about 20 minutes” gives you something to investigate.

Follow a repeatable method

The six-step troubleshooting method gives each action a purpose:

1. Identify the problem. Gather facts, reproduce the symptom and protect data.
2. Establish a theory of probable cause. Name a specific explanation you can test.
3. Test the theory to determine the cause. Use the result to confirm it or choose another theory.
4. Plan and implement the solution. Check the impact and prepare a way back.
5. Verify full system functionality and add preventive measures where they apply.
6. Document findings, actions and outcomes. Leave a useful record for the next technician.

A symptom is an observation; a cause is the condition producing it. A shutdown is a symptom. A dust-blocked cooling fan may be its cause. Several faults can produce the same symptom, so keep observations separate from explanations in your notes.

Ask questions that narrow the problem

Start with open questions: “What were you doing when it happened?” and “What exactly does the message say?” Let the user describe their experience before offering a diagnosis. Then ask closed questions that separate possibilities: “Does it happen on other websites?” or “Did it work yesterday?” Capture the exact message or a screenshot, the start time, the frequency and the effect on the user's work.

Ask what changed: software, updates, passwords, new hardware or a moved device. Also check changes outside the user's view, such as building work, a power outage or a replacement router. Update history and logs can fill gaps in the user's account.

Reproduce the failure and find its scope

Ask the user to show the failing task. Record the steps so you can repeat the same test after a repair. For an intermittent fault, record times, running programs and matching log entries. One successful attempt during a quiet period gives little information about a failure that occurs only under load.

Scope means how widely the problem occurs: one user or many, one device or all, one application or all, one location or several. Suppose one laptop cannot open any website while another device at the same desk works. Start with that laptop's connection and settings. If every device fails, shared equipment and the service upstream deserve attention.

Protect the user's work

Before a reinstall, disk repair or phone reset, check that a current backup exists and that the needed data can be recovered. Check the organization's procedures, your permission to make the change and the expected downtime. A reset made too early can remove logs and settings that would have explained the fault.

When the user reports several problems, list them separately and work through them one at a time. For a laptop that both shuts down and fails to print, record two symptoms with their own tests. This keeps the outcome of each action clear.

A theory turns collected facts into a testable explanation. “Network issue” is too broad to test. “The desk's patch cord is damaged” suggests a clear test: replace that cord with a known-good one and repeat the failing task.

Choose the next test

List likely causes and rank them by likelihood, safety and the time needed to check them. Question the obvious: power, cables, switches, monitor input, airplane mode, available storage and Caps Lock can all explain apparently serious faults. Check the state yourself when possible. A cable may be plugged in at the desk but loose at the switch.

When you need research, start with earlier tickets and the organization's knowledge base. Search the vendor's support site with the exact error code, hardware model and software version. A fix for a similar-looking error on another product may change the wrong setting.

Pick an approach that fits the chain

A comparison is strongest when the important conditions match. Using the same laptop, outlet and task while changing only the cable makes the result easier to interpret than moving the laptop and changing its adapter together.

Keep changes separate

Make one change, test it, and record the result. Undo an unsuccessful change unless you deliberately retain it as an improvement. Replacing a cable, updating a driver and changing a setting together may restore service, but leaves you unable to identify which action mattered.

If a theory is confirmed, determine the steps needed to resolve the fault. If it is not confirmed, use the result to narrow the next theory. Escalate when the remaining work exceeds your skills, permissions, available tools or support time.

Work through a printer failure

A user cannot print. You first check power, paper and the printer's status. Its display says “Ready,” and a configuration page from its own menu prints correctly. The printer can produce a page independently; its USB or network interface still needs checking.

The user's job remains in the Windows queue with “Error.” Restarting the Print Spooler releases the job. You send a new document from the user's application and repeat the task. That sequence supports a stalled queue as the cause of this failure; the successful internal page alone would not have identified it.

For an intermittent fault, test under the conditions that previously triggered it. If a connection drops every few minutes, one successful page load immediately after a cable swap is too short a test. Observe it through the usual failure interval and record whether the drops return.

A confirmed cause still needs a careful repair plan. The plan should restore the user's work, protect what already works and leave a way to recover if the change fails.

Plan the repair

Write the action steps, the expected result, the main risks and the rollback steps that return the system to its previous state. Follow the vendor's instructions, including any required order for driver or firmware work. Check whether the organization requires approval, a maintenance window or a notice to affected users.

Choose the least disruptive fix that corrects the cause. If one application is damaged, try its repair option before reinstalling it. A full operating-system reinstall affects many more programs and settings, so it needs a reason beyond one failing application.

Tell the user which outcome you have provided. A workaround needs an owner and follow-up work so it does not quietly become a closed ticket with an unresolved cause.

Verify the whole affected system

Repeat the original failing task, then test related functions that the repair could have disturbed. After replacing a laptop keyboard, test every key, the touchpad, Wi-Fi and the display: nearby cables may have been moved during access. Ask the user to try their normal work as well. A technician's test page may succeed while the user's usual application still fails.

Match the test to the original conditions. A PC that restarted during video processing needs a comparable load test, not only a few idle minutes at the desktop. Record the test duration and relevant readings so another technician can understand the evidence.

Prevent a repeat

Tie prevention to the cause. Dust-related overheating calls for cleaning filters and a maintenance schedule. Power interruptions may call for a surge protector or an uninterruptible power supply (UPS). Other useful measures include backups, updates, replacing an aging battery and showing the user the setting that caused the problem. Add a measure only when it addresses a real risk you found.

Write a ticket that someone else can use

Record the symptom, findings, each test and its result, the confirmed cause, the repair, verification and any remaining work. Use exact names and values. “Fixed computer” gives no useful starting point if the fault returns.

For example: “PC restarted without warning 3–4 times daily since Monday. Kernel-Power event 41 matched the restart times. CPU reached 98 °C under load; heatsink fins were blocked with dust. Shut down and unplugged PC, then cleaned heatsink and case fans. A 30-minute load test reached 72 °C with no restart. Added PC to the six-month cleaning schedule. User confirmed normal work.”

The log entry records an unclean shutdown; the temperature and inspection findings support the cooling diagnosis. Keeping the observations and the conclusion distinct makes the record useful for a future investigation.

Individual tickets solve today's problems. Reviewing groups of tickets can reveal faults that return across devices, locations or weeks. Escalation gives work that needs different skills or access a clear next owner.

Map the recurring problems

Group tickets by category, device, location and confirmed cause. Keep the time period consistent. Look for repeated symptoms and shared conditions, such as several phones dropping calls near one access point. A common symptom gives you a group to investigate; it still needs a cause confirmed by tests.

In one month an office records 60 tickets:

Wi-Fi drops and printer jams account for 33 tickets, or 55%. These are useful starting points for investigation. Counts show reported frequency; compare user impact and time spent before deciding where a repair will help most. A rare failure that stops a critical service may need attention before a frequent minor inconvenience.

Find what makes the fault return

A root cause is the underlying reason for the problem. Restarting an access point whenever it overheats restores service briefly. Finding it inside a closed cabinet and moving it to a suitable ventilated position addresses the cause. Review later tickets to see whether the same failure returns after the change.

A tested recurring fix belongs in a knowledge-base article. Include the exact symptom and error text, the confirmed cause, the repair steps and where they apply. State the relevant device models or software versions. Someone reading the article should be able to recognize the same problem and carry out the tested fix.

Escalate with useful evidence

Escalate when you need skills, access rights, tools or parts you lack; when many users or a critical system are affected; or when the agreed time for your support level expires. Passing the ticket promptly helps the user get the right help.

A handover should identify:

• The user, device and location.
• The exact symptom, start time, frequency and impact.
• The scope: who and what is affected.
• Tests already completed and their results.
• Your current theory and the work you need from the specialist.

For example: “Switch port 14 for room B2 has gone down and up about every 2 minutes since 09:10. One desk phone and the PC connected through it lose service. Replaced patch cord: no change. Wall-cable test shows pin 6 open. Suspect outlet termination or fixed cable. Cabling team needed to inspect and re-terminate or replace the faulty section.”

Use measured descriptions such as “12% packet loss to the default gateway” in place of “slow internet.” Include unsuccessful tests too: a specialist can avoid repeating them and see why you narrowed the fault to the remaining section.

Logs show what the system recorded; monitors show what it is doing now. Together they help you choose a test, but entries matter most when their timing and source match the user's symptom.

Find the right Windows log

Open Event Viewer with eventvwr.msc. Its main logs separate different kinds of activity:

Each event has a time, a level, a source and an event ID. A healthy computer can also log errors and warnings. Filter around the reported failure and start with Critical and Error entries that fit its timing and pattern. Search the vendor's documentation using both the source and event ID, because an ID without its source can be misleading.

A PC restarted at 14:32. Kernel-Power event 41 appears in the System log. It records that the previous shutdown was unclean; Windows writes it when starting again. It leaves several possibilities open, including power loss, heat or a system crash. Check for a crash record, temperature evidence and power problems before choosing a repair.

Match failures to changes

Reliability Monitor, opened with perfmon /rel, displays failures and changes on a day-by-day chart. Look for an application or driver installation near the first failure. A crash starting after an update gives you a theory to test, not permission to remove unrelated updates.

For a live slowdown, open Task Manager. Compare CPU, memory, disk and network use by process, and review startup apps and their impact. Resource Monitor (resmon) adds detail about which process is accessing a disk or network connection. Watch the system while performing the task that feels slow so the readings describe the same workload.

A memory leak occurs when a program keeps memory it no longer needs. Unexpected, steady growth during an unchanged workload is a warning sign. Opening a large file or caching data can also increase memory use normally. Compare use over time under similar conditions before labeling it a leak.

Check devices and exact versions

Device Manager (devmgmt.msc) lists devices and their drivers. A yellow triangle marks a problem. Read Properties for the code: Code 10 means “This device cannot start,” while Code 43 means Windows stopped a device that reported problems. Driver actions include update, rollback, disable and uninstall; choose the action that tests your theory.

Use System Information (msinfo32) for hardware, firmware and driver details in a handover. They help a specialist match vendor notices to the installed system.

Use the equivalent tools elsewhere

On macOS, Console shows logs and Activity Monitor shows resource use. On Linux, journalctl reads the system journal and dmesg shows kernel messages. If the journal persists across restarts, journalctl -b -1 selects the previous boot.

A measurement becomes useful when you know what was measured, under what conditions and which specification applies. A voltage reading with no rail name or load condition is much less useful than “+12 V rail: 10.9 V during the failing workload.”

Prepare for hardware work

Before handling internal desktop parts, shut down, switch off and unplug the power supply, and use ESD protection. Do not open a power supply or monitor; internal capacitors can retain dangerous charge. Live low-voltage tests need a suitable procedure and meter setup. Mains measurements require training and authorization.

A multimeter measures voltage, current and resistance and can test continuity. Select the correct mode, range and probe sockets before connecting it. Voltage is measured across points; continuity tests whether a disconnected circuit has a conducting path. Never connect an energized circuit to a meter set for resistance or continuity, or place a current-mode meter across a supply.

Compare power rails with the correct limits

Desktop supplies provide +12 V, +5 V and +3.3 V rails. Check the design specification for the supply being tested.

For the older +12 V rule, 5% of 12 V is 0.6 V. Subtract and add 0.6 V to find the limits. A 10.9 V reading is below both listed +12 V ranges. A reading of 11.3 V fails the ±5% rule but falls within the ATX 3.0 range. Record the applicable rule with the result.

A power supply tester connects directly to the supply's plugs and checks the rails without a motherboard. It places little or no load on the supply. A passing result can therefore miss a failure during heavy use; a compatible known-good supply gives a stronger comparison under the actual workload.

Choose a tool for the question

A clamp meter measures current from the magnetic field around one conductor. Around a whole power cord, live and neutral currents flow in opposite directions and their fields largely cancel. That can produce a near-zero reading even while the device is using power.

A POST card, motherboard debug display or debug LED identifies the stage reached during the power-on self-test. Look up codes in the board's manual; beep patterns and numeric codes vary by maker.

Windows Memory Diagnostic and bootable memory testers check RAM. A drive's S.M.A.R.T. data reports warning signs such as reallocated sectors, and vendor utilities can run device-specific tests. Firmware screens and monitoring tools show CPU and GPU temperatures.

Record the tool, result and conditions. If a fault occurs only when hot or under load, repeat a suitable test under those conditions and observe readings over time. One short passing test is weaker evidence than a test that reproduces the user's failing task.

Startup is a chain. Finding the last stage that worked is faster than treating every failed start as a Windows problem. A machine with no power needs different checks from one that reaches the Windows logo and then loses its picture.

Locate the stopping point

The usual sequence is power, firmware self-test, boot-device selection, boot loader, then operating-system drivers, services and sign-in. UEFI is the firmware on modern PCs; older systems use BIOS.

For a laptop with no power, test a suitable known-good adapter and check the battery. For a desktop, a spinning fan shows that some power is present; the supply may still fail to provide stable power under load.

Use firmware evidence

POST, the power-on self-test, checks key components before the operating system starts. Beeps, debug LEDs or a code display can identify the failing stage. Use the motherboard manual to interpret them. Common tests include reseating RAM, starting with one module, and checking the graphics card and its power connectors.

A firmware change can also block startup. Windows installed in UEFI mode on a GPT disk will not start simply by switching the firmware to legacy CSM mode. Secure Boot checks boot-loader trust. Record existing settings before testing a change; restore a mistaken change instead of changing several unrelated options.

When POST succeeds but no boot device is found, check whether the drive appears in firmware setup. If present, check that the correct boot entry is selected ahead of removable media. If absent, check its connection and power before investigating Windows files. Clearing CMOS can undo a bad firmware setting, but also resets other settings you may need to restore.

Recover a Windows startup

The Windows Recovery Environment (WinRE) provides Startup Repair, Uninstall Updates, System Restore, Startup Settings, Command Prompt and System Image Recovery. It can open after repeated failed starts. From a working sign-in screen, hold Shift while selecting Restart.

Safe Mode loads a minimal set of drivers and services. A fault that stops there points toward a driver, service or startup item excluded from that mode. A fault that remains calls for checks of system files and hardware. Safe Mode with Networking adds network drivers, although network access still depends on the available hardware and connection.

After a graphics-driver update, a PC goes black after the Windows logo. WinRE lets the technician start Safe Mode, where the basic display driver works. Rolling back the graphics driver restores the normal desktop. The ticket records the driver version and the update that caused the failure.

For a slow start, review Task Manager's startup impact, free storage, drive health and pending updates. A long wait at startup calls for evidence before buying replacement hardware.

Heat, power, memory and graphics faults can share symptoms. A restart during heavy work is a clue about the conditions, not a component name. Use those conditions to design a test that separates the likely causes.

Investigate heat and power

Random shutdowns commonly point to overheating, an unstable supply or a loose power connection. Check fans, dust, vents and temperature readings first. A blocked heatsink, failed fan, dried thermal paste or poorly seated cooler can keep heat from leaving the processor.

Thermal throttling is a processor reducing its speed to control temperature. A system may become slow before it shuts down. Many desktop CPUs have a maximum near 95–105 °C, but use the actual processor's limit when judging a reading. A value near its limit during ordinary work deserves investigation.

A desktop runs office applications all day but shuts off after 10 minutes of video editing. During an export its CPU reaches 100 °C just before shutdown. The fan spins slowly and dust packs the heatsink. After cleaning, the same export completes with a maximum of 74 °C. Comparing the same workload before and after makes the cooling explanation much stronger than an idle temperature reading.

If cooling checks leave the fault unresolved, check power connectors and compare with a compatible known-good power supply. A supply that passes a light-load tester can still fail when the CPU and graphics card draw more power.

Read physical clues safely

If you notice smoke or a burning smell, switch off and unplug immediately. Leave the device off until the source is found. Bulging or leaking motherboard capacitors are signs of board failure; the board needs replacement.

A new sound after moving or changing hardware deserves a check even when a similar sound can be harmless. A reset clock can also explain certificate and company sign-in errors.

Separate a RAM module from its slot

Memory-test errors can come from the module, slot, motherboard or CPU memory controller. Test modules one at a time in the same recommended slot. Then compare other slots or a known-good module. If errors follow one module between slots while another module passes those tests, the module is the leading suspect. Errors that remain with one slot point toward the board or connection.

For a powered PC with a blank screen, check the monitor input and cable before interpreting POST indicators. With a separate graphics card, connect the monitor to that card's output, not an inactive motherboard output.

Test simple connections and easily exchanged parts before replacing a CPU or motherboard. Record which module, slot or supply you tested so the next person can reproduce the comparison.

Storage troubleshooting starts with the data. A long repair can add stress to a drive that is already failing, so decide how to protect the user's files before testing its performance or file system.

Recognize failing storage

A hard disk that clicks or grinds may be close to failing completely. SSDs have no moving parts, so investigate their failures through detection, performance and diagnostic evidence. Both types can produce freezes while opening files, very slow reads, corrupted files or missing boot devices.

S.M.A.R.T., the drive's self-monitoring system, reports health indicators. Rising reallocated, pending or uncorrectable sector counts are warning signs. Copy important data and plan replacement. A warning is a reason to protect the data, not a fault cleared by formatting.

If valuable data has no backup and the disk is making failure noises, stop using it and consider professional recovery. Repeated full scans or repair attempts may reduce the chance of recovering the remaining readable data.

Find the level where the drive is missing

Check firmware detection first. A drive absent there points to power, a data cable, a disabled port or the drive itself. If firmware detects it but File Explorer does not show it, inspect Disk Management. An existing healthy volume may simply lack a drive letter.

A genuinely new, empty drive needs initialization, partitioning and formatting. Confirm that it is new before doing that work: formatting a drive that already contains needed data is not a diagnostic test.

chkdsk C: /f repairs Windows file-system errors. chkdsk C: /r also locates bad sectors and attempts to recover readable data; it takes longer. Protect data first when hardware failure is suspected. File-system repair and hardware replacement solve different problems.

Understand RAID failure limits

RAID combines drives, but its layout determines what happens when one fails.

RAID 5 requires at least three drives; RAID 6 requires at least four. RAID 10 can survive a failure in each pair, but losing both drives in one pair loses the array. Merely counting failed drives misses that distinction.

Handle a degraded array

A controller may show “degraded,” sound an alarm or mark a drive amber or red. Check its management tool and logs to identify the exact drive. Follow the replacement procedure with a compatible drive of at least the required capacity, then monitor the rebuild.

A four-drive RAID 5 array continues working after one failure, but another failure before rebuilding completes loses it. Keep separate backups: RAID redundancy cannot recover a file the user deleted or protect the system from ransomware, theft or fire.

Trace a picture problem from the source to the screen. The laptop's output mode, the cable, the selected display input and the panel all sit in that path. A working screen with the wrong input selected can look like failed graphics hardware.

Start with the signal path

Check that the display is powered on and awake, that the cable is secure and that the input matches the connected port. On Windows, Windows key + P selects whether the laptop uses its own screen, duplicates it or extends the desktop. Test a suitable known-good cable before replacing expensive hardware.

A meeting-room projector shows “No signal.” Setting its input to HDMI 1 makes no difference. The laptop is set to “PC screen only.” Changing it to “Duplicate” produces the picture. The cause is the laptop's output mode; the projector's fan running and power light alone could not identify it.

Match the symptom to a check

The native resolution is the panel's actual pixel grid. Other resolutions may need scaling and look soft. Choose the recommended setting, then check whether the user's readability problem needs a scaling change instead.

Separate software from hardware

Look at the firmware setup screen before Windows loads. A fault visible there belongs to the panel, cable or graphics hardware path. A fault appearing only after Windows loads points toward a driver or setting. This comparison narrows the investigation without changing several display options at once.

For a laptop, try an external monitor. A clear external image with a faulty internal one directs attention to the internal panel or its connection. If a faint LCD image is visible only under a flashlight, its illumination has failed. Modern panels use LED backlights; older ones may use fluorescent lamps and an inverter. A laptop commonly needs a panel replacement.

A dead pixel stays black; a stuck pixel stays one color. Check the manufacturer's pixel policy for warranty treatment. Burn-in is a lasting ghost of a static image, especially on OLED and older plasma displays. Automatic dimming, screen savers and hiding static elements reduce that risk.

Check projector heat and sound output

A lamp warning and no picture with the fan running can indicate a failed lamp. Let the projector cool before touching it. Repeated shutdowns suggest blocked vents or a clogged air filter; a dim image may come from eco mode or a lamp near the end of its rated hours.

For missing HDMI or DisplayPort audio, select the display or projector as the sound output device, then check its volume and mute. A good picture and silent speakers can be a sound-routing issue even when the video cable is working.

A printer problem may begin inside the printer, along its connection, or in the computer's driver, queue or application. An internal configuration page is a useful first split because it does not depend on a job arriving from a PC.

Separate standalone printing from incoming jobs

Print from the printer's own menu. A correct page shows that it can produce a page independently. Next check the USB or network interface and connection, followed by the driver, queue and application. The internal page has not exercised that incoming path.

For a network printer marked “offline” after a move, compare its current address with the address configured on the PCs. In one case the printer's page shows 192.168.1.57 while the PCs send jobs to 192.168.1.40. Restoring a suitable reserved address for the printer, then testing from two PCs, verifies the repair. A reserved or correctly managed static address prevents unexpected address changes from breaking the print path.

Read print-quality clues

The fuser melts toner onto the paper. If the toner rubs off, investigate that stage instead of only replacing toner. For an inkjet, use the nozzle check and head-cleaning procedure, then replace a cartridge that is empty or dried out.

Check paper handling

Wrong paper type or weight, damp or curled paper, overfilled trays and debris can cause jams. Remove jammed paper in its direction of travel and inspect for torn pieces. Worn pickup rollers fail to feed paper; a worn separation pad or damp paper can feed several sheets together. Stop a grinding printer and inspect its gears and paper path for a foreign object.

A laser fuser can be around 200 °C, so let it cool before reaching inside. Avoid spreading or breathing loose toner, and use a toner-rated vacuum for spills instead of a household vacuum.

Check the driver and queue

Garbled symbols often point to a wrong or damaged driver or print job. Cancel the job and install the correct driver for the exact model. Missing trays or finishing features can mean that installed options are not configured in the driver's properties. Check orientation in the application's print settings and follow the finisher's procedure for staple jams.

In a frozen queue, a pending or error job blocks later jobs. Cancel the stuck job. If it will not cancel, restart Print Spooler in Services or use net stop spooler followed by net start spooler in an elevated Command Prompt. Consider other users before restarting a shared service.

Send a new job from the user's normal application after the repair. For a shared problem, verify from another affected computer too, so the test covers the path that originally failed.

A network connection depends on several stages working together. Test them in order: physical link, IP configuration, local gateway, outside reachability and name resolution. Keep each result so the first failure gives you a useful boundary.

Check the local connection and address

For a cable, inspect the plugs and link lights. For Wi-Fi, check association with the intended network. Then read the address, subnet mask, gateway and DNS servers with ipconfig /all on Windows, ip address on Linux, or macOS network settings.

A DHCP-configured Windows PC showing an address such as 169.254.17.203 has assigned itself an APIPA, or link-local, address after receiving no DHCP answer. Check the link, switch port and DHCP availability. ipconfig /release followed by ipconfig /renew requests a new lease; it cannot fix a disconnected cable or unavailable DHCP service by itself.

Test a progressively longer path

Use ping to send ICMP echo requests and read round-trip times:

1. ping 127.0.0.1 tests the local network software.
2. Ping the device's own address.
3. Ping the default gateway.
4. Ping an outside IP address such as 1.1.1.1.
5. Test a name such as ping example.com.

A missing reply needs interpretation: some hosts and firewalls block ICMP even while the service works. Compare other evidence before declaring the host unavailable.

If an outside IP answers but a name fails with “host not found,” investigate DNS. nslookup example.com shows the DNS server used and its response. After a DNS record changes, ipconfig /flushdns clears the local cached result. A website loading badly is different from its name failing to resolve.

Check whether the gateway belongs to the network

A PC has address 192.168.10.23 with mask 255.255.255.0, but its gateway is 192.168.1.1. The local network is 192.168.10.0/24; the configured gateway is outside it. An old static setup explains why the gateway test fails. Restoring the intended automatic configuration supplies gateway 192.168.10.1 and restores access.

Read the complete configuration before changing one field. A wrong subnet mask can also make the device interpret its network incorrectly.

Look farther along the path

tracert on Windows and traceroute on macOS or Linux show responding routers along a route. An asterisk marks an unanswered probe; a later hop can still reply because the earlier router forwarded traffic without answering the probe. Delay that begins at one hop and persists at later hops is more useful evidence than one slow intermediate response.

pathping adds per-hop loss statistics. netstat -an lists connections and listening ports, useful when checking whether a service is listening or an application has a connection.

“Limited connectivity” means a link exists while internet access fails. Check the address, gateway, guest-network sign-in page and shared internet service. If one device fails, focus locally; if all fail, check the router, modem and provider status. Consider affected users before restarting shared equipment.

A connection can work and still perform badly. Separate weak signal, interference, authentication and unstable delivery so your next action addresses the kind of failure the user actually experiences.

Read wireless evidence

RSSI, a measure of received signal strength, is commonly shown in dBm. Values closer to zero are stronger: −50 dBm is stronger than −80 dBm. Rough guides are about −50 dBm for a strong signal, around −67 dBm as a common voice/video design target, and below about −80 dBm for unreliable service. A Wi-Fi analyzer shows signal levels, nearby networks and channels.

Move closer to test distance or obstacles, and compare a second device in the original location. Concrete, metal and floors can weaken coverage. Many clients, old adapter drivers and power-saving settings can also contribute.

In 2.4 GHz, channel centers are 5 MHz apart while a channel is roughly 20 MHz wide, so adjacent channels overlap. Channels 1, 6 and 11 have centers at 2412, 2437 and 2462 MHz, 25 MHz apart, and are the usual non-overlapping choices. Nearby networks, Bluetooth and microwave ovens share this band. A less crowded channel or a suitable 5 GHz or 6 GHz connection may help; check coverage because higher bands generally have shorter useful range.

Separate authentication from signal

A strong signal with rejected sign-in calls for password and security checks. Passphrases are case-sensitive; a saved old password can keep failing after a change. Check security-type support, MAC filtering and, on managed 802.1X networks, account or certificate expiry. Forget the saved network and reconnect with the current details when appropriate.

Distinguish delay, variation and loss

These are common quality guidelines, not guarantees for every service. Choppy voices and gaps call for checks of variation and loss as well as average delay.

Five gateway replies take 21, 23, 64, 22 and 20 ms. Their total is 150 ms, giving an average of 30 ms. Consecutive absolute differences are 2, 41, 42 and 2 ms; their average is 21.75 ms. This is a simple estimate of variation in round-trip samples, not a universal jitter measurement. The spike needs a longer test and a wired comparison before blaming Wi-Fi.

Investigate wired and shared failures

A gigabit-capable device linking at 100 Mb/s suggests checking cable pairs and negotiation. Also check duplex, congestion and large backups or updates using bandwidth. Port flapping means the physical link repeatedly goes down and up. Replace the patch cord first, then test fixed cabling, the adapter and negotiation settings.

If every device loses internet intermittently, compare router or modem logs with the provider's status and the time of day. Busy-hour congestion and random line drops suggest different next tests.

A working installation needs both sound cabling and successful service tests. Start with the physical link, then verify that each outlet gives the intended device a usable connection before handover.

Inspect and map the cable

Check link lights at the adapter and switch, connector seating and visible damage. Light colors can indicate speed, but their meaning depends on the device. Read the port status or manual when the indication is unclear.

Twisted-pair Ethernet uses eight conductors in four pairs. A straight-through cable follows the same termination standard at both ends. T568B pin order from 1 to 8 is white-orange, orange, white-green, blue, white-blue, green, white-brown, brown. T568A exchanges the orange and green pairs.

A wire-map tester checks which pin reaches which pin:

A split pair can pass simple continuity testing while causing high crosstalk. Use a tester that checks pair integrity or crosstalk for that fault. T568A at one end and T568B at the other produces crossed pairs instead of a straight-through map.

Check length and identify the run

For the standard four-pair copper Ethernet channel taught here, the limit is 100 m: normally no more than 90 m of fixed cable and 10 m of patch cords. An 85 m permanent link with 3 m and 7 m cords totals 95 m and fits both limits. A 92 m fixed run plus two 5 m cords totals 102 m and exceeds both the permanent-link and channel limits. Excess length risks errors and reduced speed.

A toner probe identifies an unlabeled cable by following the signal from a tone generator. A suitable loopback plug returns a port's transmitted signal to its receive path for a port test. Advanced cable testers can show length and distance to a fault.

Check power and fiber separately

For a PoE-powered phone, camera or access point, check the port's PoE support, the required standard and the switch's remaining total power budget. Maximum port power is 15.4 W for 802.3af, 30 W for 802.3at, and 60 or 90 W for 802.3bt types. The power available at the device is lower because of cable loss.

For fiber, inspect and clean connector faces, check transmit-to-receive polarity and use a visual fault locator for a visible break or sharp bend. Never look into a fiber end or connected port; its light can harm your eyes.

Verify before handover

A new outlet has no link. Its wire-map test shows pin 6 open. After re-terminating the jack, all eight pins map correctly and a PC links at 1 Gb/s. Record the outlet label, original fault, repair and retest result.

Test each outlet and patch cord, match labels to the as-built documentation, and connect a device to check its link, IP address and network access. Check Wi-Fi coverage where included. Keep the test report with the updated diagrams so later technicians can identify the exact run.

Windows and application faults can look alike: a slow program, failed sign-in or sudden restart may begin with software, storage, memory or power. Use the error, timing and affected users to choose the next check.

Capture crashes and slowdowns

A blue screen of death (BSOD) is a Windows stop error. Record the stop code, such as MEMORY_MANAGEMENT or IRQL_NOT_LESS_OR_EQUAL, and what happened just before it. Windows may save a memory dump with more evidence. Check Reliability Monitor for a recent driver or update, and search official guidance for the code and Windows version.

For degraded performance, use Task Manager to locate high CPU, memory or disk use. Check startup programs, free system-drive space and whether the workload needs more RAM. Ending a runaway process tests whether it explains the slowdown; a lasting fix addresses why it ran away. Malware, failing storage and heat can also cause poor performance.

Repair the affected layer

A program that fails to launch needs its Application log entry, faulting module, compatibility and update status checked. Try the application's repair function, then reinstall if repair fails. Test another user account: a failure limited to one account points toward that user's profile or settings.

For protected Windows files, run sfc /scannow in an elevated Command Prompt. If SFC cannot repair files, DISM /Online /Cleanup-Image /RestoreHealth repairs the component store it uses; then run SFC again. This repairs system-file damage, not a bad RAM module or an unsupported application.

A service that will not start needs its startup type, dependencies and sign-in account checked in services.msc. Read the System log for the reason. A dependent program may fail because its supporting service never started.

Check profiles, clocks and USB resources

A temporary profile or very slow sign-in can come from profile damage, a large profile or a slow connection to a roaming profile. Create a new profile when appropriate and preserve the user's data before removing the old one.

For time drift, check the time zone and automatic synchronization. w32tm /resync requests synchronization through Windows Time. A clock that resets after unplugging suggests the CMOS battery; a wrong clock can cause certificate and sign-in failures.

A USB controller resource warning can arise from many devices sharing a controller. Move some to ports on another controller. A different physical port may help, but verify the controller arrangement rather than assuming every socket has separate resources.

Isolate startup software

Safe Mode reduces drivers and services; a clean boot disables non-Microsoft services and startup items for testing. If the fault stops, re-enable items in groups to find the cause. If it remains, investigate hardware and system files as well as software still active during the test.

When a recent change is the likely cause, System Restore or uninstalling that update may reverse it. On macOS, Disk Utility First Aid and Recovery provide repair options; on Linux, an older kernel in the boot menu can bypass a bad kernel update. Preserve data and record the change before applying a repair.

A phone's short battery life may reflect a worn battery or a healthy battery doing more work. Compare battery health with the way power is being used before changing settings or ordering a part.

Separate capacity from power use

Lithium-ion capacity falls with age, charge cycles and heat. Battery health reports maximum capacity relative to new. Many manufacturers use about 80% retained capacity after several hundred to roughly a thousand full cycles as a design benchmark; the exact rating depends on the model.

A 3,000 mAh battery at 78% health holds about 2,340 mAh. A day's tasks needing 2,600 mAh no longer fit on one charge. Reducing background use can reduce demand, but replacement is the repair for the worn battery itself.

With a healthy battery, inspect battery use by app, brightness, screen timeout, background activity and location use. A weak mobile signal also raises power demand because the radio works harder to maintain the connection.

Respond to physical warning signs

A lifting screen, bulging case or back that no longer closes may mean a swollen battery. Stop using and charging the device. Do not press, puncture or flatten it; keep it away from flammable material and arrange replacement and recycling under local rules.

For poor charging, compare with a suitable known-good charger and cable. Inspect the port for damage or lint and check for a moisture warning. For wireless charging, check alignment and remove a thick case. A damaged port needs repair, not repeated force on the plug.

Heavy apps, gaming while charging, direct sun, a thick case or battery trouble can cause overheating. A hot phone may dim, slow down or stop charging as protection. Let it cool in shade, not a refrigerator, and check which app is using the most power.

Separate display and touch

The digitizer senses touch. A visible image with failed touch or phantom touches can come from the digitizer, a damaged protector, or a dirty or wet surface. Clean and dry the screen, test without the protector and restart. Use calibration if the device offers it. An active stylus also needs compatible hardware, charge and pairing.

Handle liquid and connection faults

For liquid exposure, power off, disconnect charging, remove the case and dry the outside. Allow airflow and follow the manufacturer's drying guidance. Do not use rice, external heat or objects inside a wet connector. A liquid-contact indicator may change color after exposure. IP67 or IP68 water resistance describes fresh-water test conditions and can weaken with wear; it is not permission to charge a wet device.

For lost connectivity, check airplane mode, Wi-Fi and Bluetooth switches, SIM or eSIM status, and mobile-data or roaming settings. Restart before a network-settings reset. A reset is more disruptive because saved connection details are removed; the exact settings removed vary by platform.

Choose mobile repairs in an order that preserves the user's data and settings. A single crashing app needs a narrower investigation than many apps failing across the phone.

Begin with the least disruptive steps

Close and reopen the affected app, then restart the device. Check app and system updates, available storage and compatibility. On Android, clearing the app's cache removes temporary files; clearing its data can remove locally stored content and settings. On iOS, offloading removes the app while retaining its documents and data, then allows reinstallation.

If those steps fail, consider reinstalling the app, resetting settings, and finally a factory reset after a verified backup. Check that needed local content is synced or backed up before clearing data or deleting an app. Keep enough information to restore access after a reset.

Find why installation or updates fail

Common causes include low storage, an unsupported system version, a store-account or payment problem, no internet access, parental controls and company mobile device management (MDM) restrictions. Check the actual error and status instead of repeatedly pressing Update.

A system update needs enough free space, adequate battery power or a charger, and a stable connection. If the manufacturer's support period has ended, plan replacement; repeatedly resetting the device will not create a supported update.

Work through a storage-blocked update

A banking app closes immediately. The phone has 0.5 GB free out of 64 GB, and an app update is waiting. The user backs up old videos and checks the backup. Removing those local videos frees 6.5 GB; the update installs and the app opens normally.

Record the causal evidence precisely: low storage blocked the update, and the app worked after both freeing storage and installing the update. Those actions do not separately identify whether the crash came from the old app version or another storage-related effect. For prevention, monitor free space and use the photo service's device-space cleanup after confirming backup. Enabling backup alone leaves the local copies in place.

Diagnose slow behavior and wireless functions

Low storage, many background apps, a faulty app, heat or a worn battery can cause slow responses and reboots. On Android, Safe Mode disables downloaded apps; if the fault stops, a downloaded app is causing the problem. Investigate the installed apps. Compare behavior under the same task.

For Bluetooth, put both devices in pairing mode, bring them close, then remove a stale pairing and pair again when needed. For Wi-Fi, check the password, saved network and any guest sign-in page. For NFC payments, check that NFC is enabled, the intended payment app is the default, and the phone's NFC area is close to the reader.

For failed rotation, check rotation lock and try an app that supports rotation before suspecting the sensor. After a major system update, background indexing can temporarily increase battery use. If it continues for more than a few days, inspect per-app use and background permissions.

Some apparently ordinary support faults point toward a security problem. An unexplained browser change or disabled security program deserves a different response from a routine software repair: protect data and follow the organization's security procedure.

Recognize suspicious patterns

On a PC, warning signs include repeated unwanted pop-ups, browser redirection, a changed search engine or home page, fake antivirus demands, disabled security software and unexpected update failures. Missing, renamed or unreadable files can point to ransomware. A slow browser or failed network connection alone has many possible causes; the surrounding changes help you judge the situation.

A fake alert may ask for payment or tell the user to call a number. Check its origin through the installed security program's own window instead of trusting text inside a web page. Genuine security programs and update tools also display alerts, so the presence of a pop-up alone does not identify an attack.

Treat certificate warnings seriously

A browser checks a site's certificate for trust, name and validity dates. A warning can mean expiry, a name mismatch, an untrusted issuer or a wrong device clock. Check the clock first. If it is correct and a familiar site still shows a trust warning, do not continue through it; investigate the connection because interception is a possible cause.

A PC warns on every site and shows January 1, 2020. The current site certificates appear “not yet valid” against that date. Correcting the date and enabling automatic time removes the warnings. If the clock keeps resetting after the PC is unplugged, replacing the CMOS battery addresses the underlying fault. The clock test explains this pattern without bypassing certificate checks.

Check mobile symptoms and access

Unexpected data traffic, battery drain, heat, ads outside apps, strange app behavior and personal data appearing in unexpected places can indicate misuse or malicious software. Compare the activity with the user's normal tasks and recent installations.

Sideloading means installing from outside the official store; application spoofing means an app imitates a trusted one. Rooted Android devices and jailbroken iOS devices bypass system protections. These factors raise risk and deserve attention during the investigation.

Android's Developer options menu is separate from rooting and from enabling debugging. USB or wireless debugging permits control by an authorized computer when enabled. Check whether debugging is active and which computers are authorized; turn it off when unneeded and remove unrecognized authorizations. Use the official store for apps and address unknown software through the applicable procedure.

Hand over the security problem

Report suspected compromise and isolate the device as the organization's procedure directs. The response may need to address stolen credentials or other affected devices as well as the visible symptom. Do not clean a company device and quietly return it to service. Record the symptoms, timing, scope and actions already taken so the security team can continue the investigation.