OS & Application Troubleshooting

A user says their PC is acting up. The exam is rarely asking you to name the broken part; it is asking what you do next. Every objective in domain 3.0 opens "Given a scenario, troubleshoot common ... issues" (220-1202 exam objectives^[1]), so what is under test is the symptom-to-cause-to-fix discipline: read the symptom, name the likely cause, then pick the fix that matches. The A+ troubleshooting method is the job-role habit that carries that discipline, a six-step loop running identify, theorize, test, plan and implement, verify, then document, applied here to operating-system and application faults. It is a working habit rather than a numbered sequence the 220-1202 objectives publish, so learn it for the way it orders your thinking. The figure below traces the loop, including the return from a failed test at step three to a fresh theory or an escalation.

The six steps

1. Identify the problem. Gather information, question the user, and pin down the exact symptom. Reproduce the fault if you can, and ask the single most useful question: what changed? A new update, driver, or app installed right before the symptom is your prime suspect. Two sub-habits are tested on their own: back up data before you change anything, and when a machine has several faults, work them one at a time.
2. Establish a theory of probable cause. Question the obvious first (is it plugged in, is the account locked, did an update just install), then form one testable cause and research the vendor knowledge base rather than guessing.
3. Test the theory to determine the cause. If the test confirms the theory, move on to a plan. If it does not, form a new theory or escalate to someone who can. Do not act on an unconfirmed guess.
4. Establish a plan of action and implement the solution. Choose the fix, check vendor documentation and any corporate policy on change and downtime, then apply it. Planning and implementing are one step here: settle on the fix before you touch the machine, then carry it out.
5. Verify full system functionality and, if applicable, implement preventive measures. Confirm the original symptom is gone and nothing else broke, then take a step that stops a repeat (schedule the update, replace the failing driver source, adjust the setting).
6. Document the findings, actions, and outcomes. Record what you saw and what fixed it in the ticket or knowledge base so the next technician does not start from zero.

Why working in order pays

Skipping steps is the classic wrong choice. Reimaging before you have reproduced the fault, or swapping parts before you have questioned the user, throws away information and often the user's data. A "what should the technician do first" stem is asking whether you gather information before you change anything; a "what next" stem is asking which action the symptom you have just been given actually justifies. Because two sibling pages, security-issue-remediation and malware-defense, layer a specialized process on top of this same loop, getting the base order right pays off across the whole domain.

Step four asks you to choose a fix, and the guiding rule is simple: reach for the least invasive action that could resolve the symptom, and escalate only when it fails. Rebooting clears a surprising number of transient faults and costs nothing; a full reimage cures almost anything but erases the user's installed software and, done wrong, their data. Everything else sits between those two on what this page calls an escalation ladder, an analogy for teaching rather than CompTIA terminology, and the skill is stopping at the lowest rung that works.

The escalation ladder

• Reboot, or restart the specific service. A restart releases stuck memory, closes leaked handles, and reloads a hung service. For one misbehaving background service, the Services console (services.msc) restarts just that service without a full reboot.
• Boot Safe Mode and undo the recent change. Safe Mode^[2] starts Windows with a minimal set of drivers and services, so you can work when a bad driver or startup app blocks the normal desktop. From there, roll back the driver in Device Manager or uninstall the update that preceded the symptom.
• Use System Restore. System Restore^[3] returns Windows system files, settings, drivers, and installed programs to an earlier restore point while leaving personal files untouched, so it undoes a bad change you cannot pin to one driver or update.
• Run a targeted repair. sfc /scannow^[4] repairs corrupted protected system files, DISM /Online /Cleanup-Image /RestoreHealth^[5] repairs the component store that sfc draws from, chkdsk /f^[6] fixes file-system errors on a volume, and Startup Repair (covered in the next section) fixes boot files. The full tour of these commands lives in Windows management tools; here they are simply the next rung.
• Reset this PC, then reimage. Reset this PC^[7] reinstalls Windows with a Keep my files or Remove everything option; a full reimage from a known-good image is the last resort when the install itself is beyond repair.

Each rung up the ladder preserves less of the user's setup and takes more time, which is exactly why you climb only as far as the symptom forces you. The figure below lists the same rungs with the bottom one first, so reading down the figure is climbing the ladder. The comparison table further down this page lines the heavier tools up by what they fix and what they cost.

A no-boot machine looks like a dead end, but it is really a Windows Recovery Environment (WinRE)^[8] session waiting to start. Windows loads WinRE automatically after two consecutive failed startup attempts (also after two unexpected shutdowns or reboots within two minutes of boot, or a Secure Boot error), and you can force it from the sign-in screen by holding Shift while you select Restart, or by booting Windows installation media and choosing Repair your computer. Once you are in, one menu path, Troubleshoot then Advanced options, holds every offline repair.

Work the WinRE tools in order

• Startup Repair runs first for a boot failure. It diagnoses and fixes common boot problems automatically^[2], such as damaged boot configuration, and writes a log to Srttrail.txt. Let it run before you touch anything by hand.
• Startup Settings, a different menu item from Startup Repair above, reboots into a screen where F4 starts Safe Mode^[2], F5 adds networking, and F6 gives a command prompt. Safe Mode loads a minimal driver set so you can remove the driver or update that blocks a normal start.
• System Restore from WinRE rolls the system back to a restore point taken before the change, without needing a working desktop.
• Command Prompt is where you rebuild boot files by hand when Startup Repair cannot.

bootrec: the manual boot-repair commands

bootrec /fixmbr        # rewrites the master boot record's boot code
bootrec /fixboot       # writes a new boot sector to the system partition
bootrec /scanos        # scans all disks for installed Windows systems
bootrec /rebuildbcd    # rebuilds the Boot Configuration Data (BCD) store

Reach for bootrec when the error names a missing or corrupt Bootmgr, boot sector, MBR (master boot record), or BCD store^[2]. You can also run an offline system-file scan from the same prompt with sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows and a disk check with chkdsk /f /r.

• Reset this PC is the heavy option in the same menu. It reinstalls Windows^[7] and offers Keep my files (removes apps and settings, preserves personal data) or Remove everything (wipes the volume), and it needs no external media because it rebuilds from on-box recovery files or a cloud download.

The one-line map

If it will not boot: enter WinRE, try Startup Repair, then Safe Mode or System Restore to undo a change, then bootrec and offline sfc or chkdsk for damaged boot files, and only then Reset this PC. The figure below traces the same path, with Reset this PC at the end of it. That order preserves the most and reinstalls the least.

Most OS-fault questions describe one symptom and ask for the first action. The fastest way in is to read what the system already recorded, then map the symptom to its usual cause.

Read the history first

Before you change anything, two built-in logs tell you what happened and when. Event Viewer (eventvwr.msc) holds timestamped System, Application, and Security logs; filter to Error and Critical^[2] and match the time to the symptom. Reliability Monitor (run perfmon /rel, or open it from Security and Maintenance) draws a day-by-day stability timeline and marks each app crash, driver failure, and Windows update against the date it happened, which makes the "what changed?" question almost visual: a stability score that drops the day a driver installed points straight at that driver.

Symptom to first move

Symptom	Likely cause	First move
Blue screen (BSOD) / stop error	Bad driver, failing update, or hardware fault	Note the stop code, boot Safe Mode, roll back the recent driver or update; read the minidump and Event Viewer
No boot; error names BCD or Bootmgr	Corrupt boot files	Enter WinRE, run Startup Repair, then bootrec
Boot loop (restarts before the desktop)	Bad update or driver applied at startup	WinRE, uninstall the latest update, or Safe Mode to roll it back
Black screen after sign-in	Explorer shell or GPU driver failed	Restart explorer.exe from Task Manager; roll back or reinstall the display driver in Safe Mode
Slow performance	Heavy process, too many startup apps, low disk	Task Manager to find the hog; trim Startup apps; check free space
A service will not start	Missing dependency, wrong startup type, corrupt files	services.msc to check dependencies and start type; read the System log
USB device or resource warning	Driver, or a power or resource conflict	Device Manager: update or reinstall the driver, read the error code
Time is wrong; logins fail	Clock drift breaks Kerberos authentication	Resync the clock (w32tm /resync); a domain client must stay within about five minutes of the server
"Signed in with a temporary profile"	Corrupt local user profile	Repair or recreate the profile, then copy the user's data into the new one
Low-memory warnings, instability	A leaking app, or too little RAM or page file	End the offending process; check the page-file setting; add resources if it is chronic

The deep reference for Task Manager, Event Viewer, Device Manager, and the Services console is on the Windows management tools page; this page is about matching each symptom to the right one. When the symptom is pop-ups, redirected searches, or a fake antivirus, stop and switch to the malware process in security-issue-remediation, because a generic OS repair will not remove an infection.

An application refuses to launch, or it opens and dies a second later. Before you uninstall it, remember that the cheapest fixes, running it with the right permissions or in the right compatibility mode, resolve most of these, and a corrupt user profile or a missing file permission is often the real culprit that a reinstall never touches.

When it will not install

Check that the machine meets the app's requirements (Windows edition and version, disk space, and any framework it depends on), and that you are installing with administrator rights, since a standard user cannot write to Program Files. A download that fails a checksum or was interrupted produces a corrupt installer, so re-download it. If an older version is already present and blocking the new one, remove it first from Programs and Features.

When it will not open, or crashes and hangs

• End it and relaunch. A hung app (its title bar reads "Not responding") often clears with Task Manager's End Task and a fresh launch; this is the app-level equivalent of a reboot.
• Run as administrator. Some apps need the elevated token to reach protected files or registry keys. Right-click and Run as administrator, and if that fixes it, set the shortcut to always run elevated.
• Set compatibility mode. An app written for an older Windows can run under compatibility mode^[9], which makes Windows present itself as the earlier version the program expects. It lives on the program's Properties, Compatibility tab.
• Repair, then update, then reinstall. Many installers offer a Repair option that replaces corrupt program files without losing settings; apply pending app updates too, since the crash may already be patched. A full uninstall and reinstall is the step after those, not before.

The non-obvious causes

• Permissions. If one user can run an app or open a file and another cannot, the difference is usually NTFS permissions on the program folder or data file, not the app itself. This overlaps with the access-control material in encryption and access control.
• A corrupt user profile. When an app fails for one user but works under a fresh account, the local profile is likely damaged; repair or recreate it and copy the data across, rather than reinstalling the app for everyone.
• Truly incompatible. A legacy app that will not run on the current OS even in compatibility mode belongs in a virtual machine or on a supported OS version; that is the plan of action, not another reinstall.

The figure below sets those app-level steps out in that order, ending with the virtual machine or supported OS that a truly incompatible program needs. Escalate an app the same way you escalate the OS: cheapest fix first, reinstall late, and a rebuild only when nothing lighter works.

Software-troubleshooting items on Core 2 read as short help-desk scenarios: a symptom, sometimes a recent change, and a question of what to do first or next. Two instincts win most of them. First, when the stem asks for the first step, the answer is to gather information (identify the problem, or take a safe, reversible action), not the biggest hammer. Second, when it asks for a fix, prefer the least destructive option that fits the symptom.

The scenario	Right answer	Tempting wrong answer
"What should the technician do first?"	Identify the problem: question the user, find what changed	Jump to a repair or reimage
Symptom appeared right after an update	Roll back or uninstall that update	Reinstall Windows
Will not boot; error names the BCD	WinRE, Startup Repair, then bootrec	Reset this PC immediately
sfc reports corruption it could not fix	DISM /RestoreHealth, then run sfc again	Reimage the machine
App crashes only for one user	Check that user's profile and permissions	Reinstall the app for all users
Old app will not run on Windows 11	Compatibility mode, or run it in a VM	Tell the user it is unsupported
The fix worked; ticket almost done	Verify functionality, then document	Close the ticket without documenting
Pop-ups and browser redirects	Switch to the malware-removal process	Run Startup Repair

A few reversals recur. Reimaging is almost never the first correct answer; it is the fallback after cheaper tools fail, and choosing it early is the trap. sfc and DISM pair in a fixed order: DISM repairs the store, then sfc repairs files from it. Verifying and documenting are real steps, so a "the repair worked, now what" stem wants verify then document, not "close the ticket." And any symptom that smells like infection (pop-ups, redirects, ransom notes, a rogue antivirus) leaves this page for malware-defense and security-issue-remediation, which follow a distinct removal sequence where a generic OS repair is the wrong answer. Mobile app and OS faults follow their own path in mobile troubleshooting.