Legacy Haven University

Software troubleshooting frameworks exist to stop guesswork. They force a technician to isolate a symptom, name a probable cause, test that cause, and restore the system without destroying user data. CompTIA A+ Core 2 (220-1202) weights Software Troubleshooting at 23 percent of the exam and tests that process across Windows, mobile operating systems, and security incidents.

A framework is not a list of fixes. It is a decision engine. You feed it symptoms, logs, recent changes, and tool output. It returns a sequence: identify, theorize, test, plan, implement or escalate, verify, document. Apply the same engine to a Blue Screen of Death (BSOD), a phone that will not install an app, or a browser that redirects to fake antivirus pages.

The CompTIA Troubleshooting Methodology Applied to Software

CompTIA publishes a repeatable methodology that every A+ technician uses on software tickets. The published sequence is: identify the problem; establish a theory of probable cause; test the theory to determine the cause; establish a plan of action and identify potential effects; implement the solution or escalate; verify full system functionality and apply preventive measures; document findings, actions, outcomes, and lessons learned.

Identify the problem. Question the user. Capture the exact error text, stop code, or behavior. Ask what changed: a Windows feature update, a new driver, a sideloaded Android package, a browser extension. Duplicate the fault if you can do it safely. Split multiple symptoms and handle one at a time. Pull Event Viewer, crash dumps, and mobile battery or data-usage screens before you change anything.

Establish a theory of probable cause. Start with the simplest explanation that matches the evidence. A BSOD after a GPU driver update points at that driver before it points at failing RAM. An app that fails only on cellular and works on Wi-Fi points at the carrier profile or a captive portal, not at a full OS reinstall. Question the obvious: airplane mode, a full disk, an expired certificate, a disabled service.

Test the theory. Change one variable. Roll back one driver. Disable one startup app. Clear one app cache. If the theory fails, form a new theory. Do not stack three “maybe this will help” changes and then wonder which one worked.

Establish a plan and name the side effects. A profile rebuild logs the user out and can drop local settings. A reimage wipes the volume unless you back up first. Disabling System Restore during malware cleanup removes an easy rollback path on Windows Home. Write the plan so another technician can execute it.

Implement or escalate. Apply the least destructive fix that tests the theory. Escalate when the next step needs domain admin rights, a mobile device management (MDM) wipe, or a forensic hold.

Verify and prevent. Confirm the original symptom is gone and that adjacent functions still work: print, VPN, mail, camera, Bluetooth. Then add the preventive control: patch the OS, pin the working driver, revoke the rogue app permission, schedule Windows Defender scans.

Document. Record the symptom, the root cause, the exact commands or clicks, and the outcome in the ticket. That record becomes the knowledge-base article the next technician needs.

Candidates who want this methodology embedded in a full Core 2 study path can use the structured exam guide at https://legacyhaven.university/how-to-pass-comptia-a-core-2-220-1202/.

Domain 3.0: The Exam’s Software Framework

Core 2 Domain 3.0 splits software work into four scenario objectives:

• 3.1 Troubleshoot common Windows OS issues.
• 3.2 Troubleshoot common mobile OS and application issues.
• 3.3 Troubleshoot common mobile OS and application security issues.
• 3.4 Troubleshoot common personal computer (PC) security issues.

Security Domain 2.6 supplies the companion 10-step SOHO malware removal procedure. Exam items mix these lists. A single ticket can start as “slow laptop,” become “unexpected pop-ups,” and end as a full malware-removal sequence.

Windows OS Troubleshooting Framework (Objective 3.1)

Windows fails in a finite set of ways. Map the symptom to a layer: boot loader, kernel/driver, service, application, profile, or time/sync.

Blue screen of death (BSOD). Windows hits a stop error it cannot recover from and writes a minidump. Read the stop code and the faulting module on the screen or in Event Viewer under Windows Logs > System. Common drivers include storage, display, and antivirus filter drivers. Test the theory with a driver rollback, a clean-boot, Windows Memory Diagnostic, or sfc /scannow. If the dump names ntoskrnl.exe with no third-party module, treat hardware and firmware next.

Boot issues and “No OS found.” The firmware cannot find a bootable Windows Boot Manager, or BCD (Boot Configuration Data) is corrupt. Boot to WinRE (Windows Recovery Environment). Run Startup Repair. From the recovery command prompt, rebuild the store with bootrec /fixmbr, bootrec /fixboot, and bootrec /rebuildbcd when the disk and partition table are intact. Confirm the disk is detected and that BitLocker is unlocked before you assume the OS is gone.

Degraded performance, low memory warnings, USB controller resource warnings. Task Manager shows CPU, memory, disk, GPU, and the process that owns them. Startup apps and runaway services consume RAM and I/O. USB controller resource warnings appear when too many devices share limited endpoint slots on older controllers. Unplug unused hubs, move devices to another controller, and trim startup items. Add RAM only after you prove the working set is actually constrained.

Services not starting and applications crashing. Services.msc and Event Viewer show the failed service and its dependency chain. Restart the service once. If it dies again, repair the application or run DISM to fix the component store, then System File Checker:

text

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

An application that crashes on launch often fails a dependency (Visual C++ runtime, .NET, missing DLL) or hits a corrupt user profile.

Frequent shutdowns and system instability. Distinguish thermal/power hardware from software. If Event Viewer logs Kernel-Power 41 with no preceding stop error, look at PSU and heat. If instability started after a cumulative update, roll the update back from Settings or WinRE.

Slow profile load. A roaming or local profile with a bloated registry hive or a failing network path delays the shell. Test with a newly created local account. If the new account is fast, rebuild the user profile: copy data out, delete the old profile, and let Windows create a clean hive.

Time drift. Windows and Kerberos break when the clock skews. Sync to an NTP source. If the clock resets at every boot, the CMOS battery is dead. That is a hardware fix, but the symptom presents as a software authentication failure.

Practical Windows repair ladder, least to most destructive: reboot → isolate in a clean boot or Safe Mode → restart or repair the service/app → sfc and DISM → uninstall or roll back the last change → System Restore → Startup Repair / bootrec → in-place repair upgrade → reimage.

Mobile OS and Application Troubleshooting Framework (Objective 3.2)

Mobile faults cluster around the app sandbox, the store update channel, power management, and radios.

Application fails to launch, close, crash, update, or install. Clear the app cache first. Force-stop the app. Confirm free storage; both iOS and Android abort installs when the volume is full. Check that the OS version meets the app’s minimum. On Android, a failed install from an unofficial store is a security event, not just a packaging error. Uninstall and reinstall from the official store (Google Play or Apple App Store). If one app fails and others work, the app is the fault domain. If every app fails after an OS update, roll the OS or wait for the vendor patch.

Slow to respond. Background refresh, a runaway sync account, thermal throttling, and a nearly full flash volume all produce the same “laggy” complaint. Inspect battery usage by app. Disable background activity for the offender. Reboot to clear leaked wakelocks.

OS fails to update. Insufficient storage, a metered cellular link, a pending reboot, or a device that is no longer in the vendor support window will block the package. Download on Wi-Fi, free space, and confirm the model is still receiving builds. End-of-life devices do not get a software fix; they get a replacement plan.

Battery life issues and random reboots. A single app holding a wake lock drains the cell. Poor signal forces the radio to run at high power. Random reboots after an OS update point at a bad build or a failing battery that the OS can no longer manage. Boot into safe mode on Android to see whether a third-party app is the trigger.

Connectivity: Wi-Fi, Bluetooth, NFC. Toggle airplane mode to reset all radios. Forget and rejoin the SSID. Clear the Bluetooth pair and pair again. NFC fails when the radio is off, the case shields the coil, or an app no longer has the payment permission. Test with a known-good access point before you replace hardware.

Screen does not autorotate. The rotation lock is on, the accelerometer is disabled in accessibility settings, or an app has pinned orientation. Toggle the lock. If no app rotates, the sensor or its driver is the next theory.

Mobile Security Troubleshooting Framework (Objective 3.3)

Mobile security issues start with how the app arrived on the device and whether the user opened a privileged mode.

Security concerns. Unofficial application stores and sideloaded packages skip store review. Developer mode and USB debugging expose the device to ADB (Android Debug Bridge) attacks. Root access or a jailbreak disables the vendor sandbox and integrity checks. Unauthorized or malicious apps include spoofed icons that mimic a bank or mail client (application spoofing).

Symptoms that confirm compromise. High network traffic and data-usage limit alerts on a modest plan. Degraded response time. Limited or no internet while Wi-Fi shows connected (a local VPN or DNS hijack). A high number of ads. Fake security warnings. Unexpected application behavior. Leaked personal files or photos appearing on another account.

Framework for the ticket: isolate the device from corporate mail and files (MDM quarantine or remove the work profile). Identify the unofficial app and revoke its permissions. Uninstall it through the OS settings, not through a “cleaner” downloaded from the same unofficial store. If the device is rooted or jailbroken and the business forbids that state, wipe and restore from a known-good backup, then re-enroll in MDM. Do not attempt to “unroot” a fleet device and call it trusted.

PC Security Troubleshooting Framework (Objective 3.4)

PC security symptoms overlap with malware, browser hijacks, and failed patching.

Host symptoms. Unable to access the network. Desktop alerts and false antivirus warnings (scareware). Altered system or personal files: missing or renamed files, or files that will not open. Unwanted notifications inside the OS. OS update failures while a process locks wuauserv or replaces system binaries.

Browser-related symptoms. Random or frequent pop-ups. Certificate warnings on sites that previously loaded cleanly. Redirection from a typed URL to an advertising or credential-harvest page. Degraded browser performance from injected toolbars and extensions.

Treat the browser as its own fault domain first: disable untrusted extensions, reset the browser profile, flush cache and the hosts file, and confirm DNS is not pointed at a rogue resolver. If pop-ups survive a browser reset, the infection lives in the OS and you enter the malware-removal framework.

The 10-Step SOHO Malware Removal Framework (Objective 2.6)

CompTIA requires this exact order for basic small-office/home-office malware removal. Skipping a step is an exam miss and a real-world reinfection.

1. Investigate and verify malware symptoms. Confirm the behavior is malicious, not a failed update or a legitimate push notification.
2. Quarantine the infected system. Unplug Ethernet, disable Wi-Fi, and keep the machine off the production network so it cannot encrypt shares or spread.
3. Disable System Restore in Windows Home. Malware hides in restore points. Leaving System Restore on lets the infection ride a later rollback.
4. Remediate infected systems. Identify the family and remove what you can with the tools you trust.
5. Update anti-malware software. A stale definition file misses the current hash.
6. Scan and remove using Safe Mode or a preinstallation environment (WinPE, a bootable rescue ISO) so the malware cannot hook running processes.
7. Reimage or reinstall when removal is incomplete, when a rootkit owns the boot path, or when file integrity cannot be proven.
8. Schedule scans and run updates. Persistence dies when the next definition and OS patch land automatically.
9. Enable System Restore and create a restore point on Windows Home after the system is clean.
10. Educate the end user. Explain the click, the USB stick, or the fake alert that started the incident so the same user does not reopen the door.

Safe Mode loads a minimal driver set. WinPE scans the offline Windows volume before winlogon starts. Reimaging is the cleanest close when the boot sector, a kernel driver, or the component store is untrusted.

Tool Stack That Drives the Framework

Windows: Task Manager (Processes, Performance, Startup, Services), Event Viewer (eventvwr.msc), Services, Settings > Recovery, WinRE, sfc, DISM, chkdsk, bootrec, Resource Monitor, Windows Security / Microsoft Defender, autoruns-class startup inspection.

Mobile: App info screens (force stop, cache, permissions, battery), official stores, safe mode, OS update channels, MDM consoles for wipe and compliance.

Security: current anti-malware with updated definitions, bootable rescue media, browser reset, hosts-file inspection, certificate viewer, network isolation.

Use each tool to test a theory, not to spray fixes.

Exam Decision Patterns

Performance-based and multiple-choice items reward sequence discipline. Identify before you change. Quarantine before you remediate. Disable System Restore before you clean Windows Home. Verify after you implement. Document last.

When two answers both look correct, pick the least destructive action that still tests the current theory. Rebuild a profile before you reimage. Clear an app cache before you factory-reset a phone. Update Defender definitions before you declare the machine clean.

Domain 3 does not live alone. Domain 1 gives you the tools. Domain 2 gives you the malware taxonomy and the 10-step removal process. Domain 4 gives you the ticket, the change plan, and the user-education close. The framework is how those domains lock together on a live incident.