Hardware Symptoms pt.1

A user says, "My computer crashed," and the ticket looks simple. Then you arrive and see a strange vendor warning, a black display, or nothing happens at all. These symptoms map directly to CompTIA A+ 220-1201 Objective 5.1, because the exam expects you to spot patterns and pick safe first actions.

This article gives an exam-ready flow you can reuse on real tickets. Start with safety and basics, confirm the exact symptom, then separate hardware from software. After that, apply the least risky fix first, verify the result, and document what changed. That method works whether you're staring at a blue screen, a blank display, a dead system, or a PC that crawls like it's moving through wet cement.

Proprietary crash screens: how to read the message and pick the right first fix

A "proprietary crash screen" is any crash display that comes from an OS vendor or device maker, and includes details you can act on. In Windows, that often means a BSOD with a stop code. On macOS, it may be a kernel panic message and forced restart. On phones and tablets, it can be an error screen after an app or OS fault. Some OEM tools also show pre-boot warnings, for example, storage errors, thermal shutdowns, or fan failures.

The exam focus is practical: identify what you see, interpret common causes, and choose a sensible next step without guessing. That starts with one rule: treat the screen like a lab result. If you wipe it away, you lose the best clue.

Changes matter because crashes often follow them. A driver update can introduce instability. New RAM can cause memory errors. A new USB device can trigger a faulty driver. Even a low disk condition can turn a small issue into repeated stop errors.

When you see a crash screen, slow down for 30 seconds. Capture the text, then act. Rebooting first feels productive, but it often deletes the evidence.

What to capture before you reboot so you don't lose the clue

Before the restart, record what the crash screen provides and what the user reports. In many environments, a quick photo is allowed and saves time. If policy blocks photos, write details in the ticket.

Capture these items because they narrow the search fast:

• Error text and code: Windows stop code, macOS panic summary, or any OEM error number.
• Driver or file name (if shown): A named .sys file often points to a device driver.
• What changed: updates, new hardware, new peripheral, new app, or a recent repair.
• User activity: gaming, video calls, waking from sleep, printing, or heavy browser use.
• Frequency and trigger: random, at boot, after login, or only with one device attached.
• Related signs: unusual beeps, burning smell, high fan noise, or warning LEDs.

After reboot, confirm the crash happened. Then check simple logs and history tools. On Windows, Reliability Monitor and Event Viewer often show critical events around the time of failure. On macOS, system logs and panic reports help. The key point is not the tool name, it's the timeline. When you connect "crashed at 2:14 PM" to "driver updated at 1:50 PM," you reduce guesswork.

Fast triage moves that solve many crash screens

Start with safe actions that reverse recent risk. If the crash began after a change, undo it first. Remove the new peripheral. Roll back the driver. Uninstall the new software. If the system won't stay up long, boot into Safe Mode when possible, because it loads fewer drivers.

Next, choose one of these high-value steps based on evidence:

• If a driver name appears, update or roll back that driver from a trusted source (OS update, OEM support, or enterprise management).
• If crashes happen during heavy load, check for overheating. Dust and blocked vents cause thermal shutdowns and instability.
• If the machine is low on space, free disk space. A full system drive can break updates and paging.
• Run memory and storage checks when symptoms fit. Random restarts, "memory management" errors, and crashes during installs can point to RAM. Slow boot, repeated file errors, or corruption can point to a failing SSD or HDD.

Keep the A+ mindset: don't replace parts first. Confirm the cause with the smallest, safest change, then retest. When the crash returns, your notes from the first screen will often tell you where to look next.

Blank screen: tell the difference between display, boot, and OS problems

"Blank screen" is a vague phrase. For troubleshooting, you need to translate it into one of three cases: no video during POST, video works but the system can't boot, or the OS loads but shows a black screen after login. Each case has different clues, so your first job is observation.

Start with what the device does when you press power. Do fans spin? Do keyboard lights turn on? Does the drive activity light blink? Those signals help you decide whether you have a display path problem or a system startup problem.

A simple mental model helps: video output follows a chain. The system runs POST, then it initializes graphics, then it sends a signal through a port, cable, and display input, and finally the panel produces light (backlight) and an image. A failure anywhere in that chain can look like "nothing on screen."

The A+ exam expects you to use terms like POST, no video, backlight, and input source correctly.