Chapter 3

Software Troubleshooting

CompTIA A+ Core 2 (220-1202) Study GuideBased on the CompTIA A+ 220-1202 exam objectives

Software problems are the ghosts of the IT world. A failed hard drive announces itself with clicks and grinding noises. A dead power supply gives you silence. But software? Software fails quietly, intermittently, and often with symptoms that point in three directions at once. The user says "it's slow." The screen is blue. The app that worked yesterday crashes today for no apparent reason. Nothing changed — except, of course, something always changed.

This is the domain where CompTIA separates technicians who guess from technicians who diagnose. Roughly 23% of your Core 2 exam lives here, and the questions are overwhelmingly scenario-based: a story, a symptom, and four possible actions. The exam isn't testing whether you've memorized every Windows tool. It's testing whether you think like a troubleshooter — methodical, evidence-driven, and disciplined about what you do FIRST versus what you do eventually.

3.1 The 6-Step Methodology, Software Edition

You met the CompTIA troubleshooting methodology in Core 1's hardware domain. The six steps don't change, but their flavor does when the problem is software:

1. Identify the problem — Gather information, question the user, identify symptoms, determine if anything has changed.
2. Establish a theory of probable cause — Question the obvious; consider multiple hypotheses.
3. Test the theory to determine the cause — If the theory is confirmed, move on. If not, establish a new theory or escalate.
4. Establish a plan of action and implement the solution — Identify potential effects before you act.
5. Verify full system functionality and implement preventive measures — Make sure the fix worked and the problem won't return.
6. Document findings, actions, and outcomes — Write it down.

In hardware troubleshooting, step 3 often means swapping a part. In software troubleshooting, step 3 means changing one variable and observing. Disable the startup program. Boot into Safe Mode. Run the scan. The principle is identical: isolate, test, observe.

One more methodology trap: escalation is a valid step-3 outcome. If your theory doesn't pan out and you've exhausted reasonable hypotheses, the correct move is to escalate or consult documentation — not to keep randomly trying things. CompTIA rewards the technician who knows their limits.

3.2 Windows Won't Boot: The Black Screen of Dread

Scenario: It's 8:47 on a Tuesday morning. A user calls, voice tight with panic: "My computer won't start. There's just a black screen with a spinning circle, and it's been like that for twenty minutes." Yesterday it worked fine. They swear they didn't change anything — but then they mention, almost as an afterthought, that Windows installed updates when they shut down last night.

Step 1 — Identify the problem. The symptom: Windows begins to load (spinning circle) but never reaches the login screen. Something changed: a Windows update installed at shutdown. That's your first theory forming already — a bad or incomplete update.

Step 2 — Theory of probable cause. The update theory is strong, but keep alternatives in mind: corrupted boot files, a failing drive that chose this morning to die, or a driver the update dragged in that's hanging the boot.

Step 3 — Test the theory. You can't get into Windows normally, so you need the Windows Recovery Environment (WinRE). Have the user force WinRE by interrupting the boot three times in a row — power off during the spinning circle, power on, repeat. On the third boot, Windows gives up and loads WinRE automatically. This three-interrupt trick is the single most useful boot troubleshooting move in your arsenal.

From WinRE's Advanced options, you have a toolbox:

In our scenario, the fix is almost comically direct: WinRE → Troubleshoot → Advanced options → Uninstall Updates → remove the latest quality update → reboot. Twenty minutes of panic, two minutes of fix. The user's PC boots normally.

But suppose Uninstall Updates isn't available or doesn't fix it. Then you go deeper. From WinRE's Command Prompt:

• bootrec /fixmbr — rewrites the Master Boot Record (legacy BIOS systems)
• bootrec /fixboot — writes a new boot sector
• bootrec /scanos — scans for Windows installations
• bootrec /rebuildbcd — rebuilds the Boot Configuration Data store

Safe Mode deserves its own moment. When Windows boots in Safe Mode, it loads only the bare minimum: basic drivers, essential services, no startup programs. If the PC boots fine in Safe Mode but not normally, you've just proven the problem is something that loads during a normal boot — a driver, a service, or a startup program. That's not a fix, but it's a magnificent diagnostic narrowing. From there, System Configuration (msconfig) lets you disable startup items and non-Microsoft services selectively — the software equivalent of pulling RAM sticks one at a time.

3.3 The Blue Screen of Death: Reading the Crash

Scenario: A graphic designer calls mid-afternoon. "My screen just went blue with a bunch of white text, and then the computer restarted itself. I lost an hour of work. This is the third time this week." She mentions it seems to happen when she's rendering video — heavy GPU and CPU load.

Step 1 — Identify. The symptom is a BSOD (Blue Screen of Death) — Windows' way of saying "something went so wrong I had to stop everything to protect your data." Key details: it's intermittent (three times this week), and it correlates with heavy load (video rendering).

Step 2 — Theory. Intermittent crashes under load point toward: a flaky driver (GPU driver is suspect #1 for a designer), overheating, or failing RAM. Three solid theories, ranked by likelihood.

Step 3 — Test. First, stop the bleeding of information: by default, Windows restarts automatically after a BSOD, which hides the error. Have her note the stop code next time (e.g., VIDEO_TDR_FAILURE, IRQL_NOT_LESS_OR_EQUAL, MEMORY_MANAGEMENT). Better yet, check Event Viewer → Windows Logs → System, where the crash is logged with its stop code even after the reboot. Even better: the memory dump file (MEMORY.DMP) can be analyzed, though that's beyond A+ scope — just know it exists.

The stop code is your Rosetta Stone:

In our scenario, the crashes happen under GPU load. Theory #1: the GPU driver. Test: boot into Safe Mode (which uses a basic display driver) — if it's stable, the GPU driver is implicated. Fix: use Device Manager to roll back or update the GPU driver. If the driver is current, try a clean reinstall of an older stable version. Also check temperatures — rendering pushes the GPU hard, and overheating causes the exact same symptom. Two theories, both cheap to test.

One more BSOD-adjacent scenario CompTIA adores: the PC boots to a BSOD in a loop and won't reach the desktop. The move: WinRE → Startup Settings → Safe Mode. If Safe Mode works, it's a driver or startup item — use msconfig or Device Manager from there. If Safe Mode also blue-screens, you're looking at hardware (RAM, drive) or deep system corruption (SFC/DISM from WinRE's command prompt).

3.4 Slow Performance: The Boiling Frog

Scenario: "My computer is just... slow. It takes forever to start, everything lags, and I swear it used to be fast." No error messages. No crashes. Just the slow, grinding misery of a PC that has accumulated two years of digital barnacles. This is the most common software complaint in existence, and the vaguest — which is exactly why methodology matters.

Step 1 — Identify. "Slow" is not a diagnosis; it's a feeling. Your job is to turn the feeling into measurements. Open Task Manager (Ctrl+Shift+Esc) and look at the Performance tab: is the CPU pegged at 100%? Is memory maxed out? Is the disk at 100% utilization? Each pattern points somewhere different:

Step 2 & 3 — Theory and test. The usual suspects for gradual slowdown, in order of likelihood:

1. Too many startup programs. Every application wants to launch at boot "for your convenience." Two years of installs means thirty programs fighting for CPU at startup. Fix: Task Manager → Startup tab → disable everything non-essential. Or msconfig → Startup. This single fix resolves an astonishing percentage of "slow PC" complaints.

1. Disk nearly full. Windows needs breathing room — when the drive drops below ~10-15% free space, everything slows down (no room for temp files, page file, updates). Fix: Disk Cleanup (cleanmgr), empty the Recycle Bin, uninstall unused programs, move files off the drive.

1. Malware. We'll cover this in depth in section 3.7, but a slow PC with high CPU from an unknown process is malware until proven otherwise.

1. Failing hard drive. If it's a spinning HDD and Task Manager shows 100% disk with the system barely responding, the drive may be dying. Fix: back up immediately, run chkdsk /r, plan replacement (with an SSD).

1. Windows Update stuck. An update downloading or installing in the background can grind everything to a halt. Check Settings → Windows Update.

For the "slow boot specifically" variant: msconfig → Boot tab → check boot options, but more usefully, the Startup tab (which redirects to Task Manager in modern Windows). Also check for a nearly-full drive and consider whether the user would benefit from an SSD — the single most transformative upgrade for an old PC, and a legitimate professional recommendation.

A quick word on virtual memory / page file: if RAM is maxed out, Windows uses disk space as overflow (the page file). On an HDD, this is brutally slow — which is why "not enough RAM" feels like "slow everything." The real fix is more RAM, but you can check the page file settings at System → Advanced system settings → Performance → Advanced → Virtual memory. CompTIA occasionally tests that you know the page file exists and what it does, not the exact configuration steps.

3.5 Windows Update Problems: The Update That Wouldn't

Scenario: A user reports that Windows Update has been "checking for updates" for three hours, or an update downloads to 98% and fails, or — the truly maddening one — the PC is stuck in an update loop, rebooting over and over. Updates are supposed to protect the system; when they break, they break everything.

Step 1 — Identify. Pin down exactly what's happening: Is the update failing to download, failing to install, or installing and then rolling back? The error code (e.g., 0x80070002, 0x80240034) matters — write it down.

Step 2 & 3 — Theory and test. The update pipeline has a few well-known choke points:

1. Corrupted update cache. Windows downloads updates to C:\Windows\SoftwareDistribution. If those files corrupt, every subsequent attempt fails the same way. The fix is beautifully mechanical: stop the Windows Update service, rename or delete the SoftwareDistribution folder, restart the service. Windows rebuilds the folder fresh and re-downloads. This resolves a huge share of stuck-update cases.

1. Insufficient disk space. Feature updates need significant free space (often 10GB+). If the drive is nearly full, the update fails. Free up space first (see section 3.4).

1. Third-party interference. Antivirus software occasionally blocks update components. Temporarily disabling it for the update (and re-enabling after) is a legitimate test.

1. The built-in troubleshooter. Settings → System → Troubleshoot → Windows Update troubleshooter. It's automated, safe, and surprisingly effective for common update glitches. Always worth running before manual surgery.

3.6 Application Crashes and Compatibility: "It Worked Yesterday"

Scenario: An accounting firm calls. Their critical invoicing software — a program they've used for six years — crashes on launch after a Windows feature update. The vendor went out of business in 2021, so there's no update coming. Reinstalling doesn't help. The accountants are doing invoices by hand, and the glares are getting sharper.

Step 1 — Identify. The app crashes on launch, consistently, after a Windows feature update. The timing is the clue: the update changed something the old app depended on.

Step 2 & 3 — Theory and test. For application crashes, work through this ladder from least to most disruptive:

1. Run as Administrator. Some older apps need elevated privileges to access files or registry keys. Right-click → Run as administrator. If it works, set it permanently in the shortcut's Compatibility/Properties. Quick test, quick win.

1. Compatibility mode. Right-click the executable → Properties → Compatibility tab → "Run this program in compatibility mode for:" and select the older Windows version the app was designed for. This is THE answer for "old app broke after Windows upgrade" scenarios. Windows shims the old APIs the app expects.

1. Update or reinstall the app. Corrupted program files cause crashes that look mysterious but have a mundane fix. Uninstall cleanly, reinstall fresh. Check the vendor for a patched version first.

1. Check dependencies. Some apps need specific runtimes — Visual C++ Redistributables, .NET Framework versions, Java. A crash on launch with no error sometimes means a missing runtime. Event Viewer → Application log often names the faulting module, which points at the dependency.

Scenario 2: A different flavor — Microsoft Word crashes every time the user tries to print. Everything else works. Theory: the problem isn't Word, it's the print subsystem — a corrupt printer driver or a damaged document. Test: try printing from Notepad. If Notepad prints fine, the issue is Word-specific (try repairing Office). If Notepad also fails, it's the printer driver — reinstall it. This "change one variable" isolation is step 3 in its purest form: does the symptom follow the app, or follow the function?

3.7 Malware: The Uninvited Guest

Scenario: A home user calls. "There are pop-ups everywhere, even when I'm not in my browser. My homepage changed to something I've never heard of, my computer is really slow, and my friend said they got a weird email from me that I didn't send." This is the full malware symphony — every section playing at once.

Before touching anything, you need to speak malware fluently. CompTIA expects you to recognize the types:

And the symptoms that should make your malware antennae twitch:

Now, the removal. CompTIA defines a best-practice malware removal procedure, and they test it as an ordered sequence — you must know the steps AND their order:

1. Investigate and verify symptoms. Confirm it's actually malware (not a legitimate program behaving badly). Check Task Manager, Event Viewer, browser extensions.
2. Quarantine the infected system. Disconnect it from the network — unplug Ethernet, disable Wi-Fi. This stops the malware from spreading, exfiltrating data, or receiving commands. Do this BEFORE scanning.
3. Disable System Restore (Windows). Malware can hide in restore points; if you don't disable it, the system may cheerfully restore the infection later.
4. Remediate: update anti-malware, scan in Safe Mode, remove threats. Boot into Safe Mode (minimal drivers = malware can't defend itself as well), update your anti-malware definitions, run full scans. You may need multiple tools — no single scanner catches everything.
5. Schedule scans and updates. Set up recurring automatic scans and make sure definitions update automatically. Prevention beats cure.
6. Re-enable System Restore and create a fresh restore point. Now that the system is clean, capture a known-good state.
7. Educate the end user. Explain how the infection likely happened (phishing link, shady download, no updates) and how to avoid it. The user is part of the security system.

Back to our scenario: pop-ups with no browser open, hijacked homepage, slowness, spam sent to contacts. Step 1: verified — that's malware, not a glitch. Step 2: disconnect the network cable immediately. Step 3: disable System Restore. Step 4: reboot into Safe Mode with Networking (needed to update definitions), update the anti-malware, run full scans, remove everything found, check browser extensions and uninstall unknown programs. Step 5: schedule weekly scans. Step 6: re-enable System Restore, create a clean restore point. Step 7: the awkward conversation — "That 'free PDF converter' was the trojan. Let's talk about where you download software."

3.8 Mobile OS Troubleshooting: The Computer in Your Pocket

Scenario: "My phone battery dies by lunchtime, it gets hot in my pocket, and apps keep crashing." Three symptoms, one device, and the user wants all of it fixed before their flight this afternoon.

Mobile troubleshooting follows the same methodology, but the tools and culprits are pocket-sized:

Step 1 — Identify. Check Settings → Battery → battery usage by app. One app consuming 40% of the battery in the background is your prime suspect — a runaway process, the mobile equivalent of the desktop's 100%-CPU mystery process.

Step 2 & 3 — Theory and test. Force-stop the suspect app. Does the drain stop and the phone cool down? Theory confirmed. If it recurs, uninstall the app or check for an update — a buggy update is a classic cause of sudden battery drain that "started last week."

Mobile security is the other half of this section, and CompTIA treats it as a distinct topic:

• Screen locks (PIN, pattern, fingerprint, face) — the first and most basic defense. If a question asks for the minimum security on a company phone, it's a screen lock.
• Remote wipe — if a device with company data is lost or stolen, IT wipes it remotely. The scenario keyword is "lost/stolen device with sensitive data" — the answer is remote wipe, and speed matters.
• Locator applications (Find My iPhone, Find My Device) — find, lock, or wipe a missing device.
• MDM (Mobile Device Management) — the enterprise solution: IT enrolls company phones in an MDM platform to enforce policies (require encryption, push apps, restrict features, remote wipe). If a scenario mentions managing many company devices centrally, the answer is MDM.
• Full-device encryption — scrambles all data on the device; without the key, a stolen phone yields nothing.
• Authenticator apps — for multi-factor authentication; more secure than SMS codes.

3.9 Master Symptom-to-Cause Quick Reference

When you're staring at a scenario question and the clock is ticking, pattern-match the symptom:

End-of-Chapter Test