Application and Software Troubleshooting
Resolve application faults across installation, permissions, dependencies, profiles, and updates without reimaging by default.
- Certification
- CompTIA A+
- Recommended study time
- 5h 35m
- Status
- Not started
Recommended study time
About 5h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 8 sittings.
- Read the lesson21 min
About 2,755 words at a careful technical reading pace.
- Second pass with notes13 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h 40m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 20m
4 short review sessions spread over the following weeks.
Learning objectives
- Separate application, profile, OS, and data causes with targeted tests.
- Use logs and error text to select the correct remediation.
- Apply the least disruptive fix that resolves the root cause.
Start here
About 8 minutes of reading, in 10 short parts.
Applications fail for reasons that live in different layers, from a single user's corrupted settings to a missing shared library affecting every user on a machine, and reimaging a computer to fix a software problem often destroys the evidence needed to prevent it recurring. This lesson gives you a layered approach to fixing software without resorting to a full rebuild by default.
Where you meet it: You use this whenever an application crashes, will not open, behaves differently for one user than another, or breaks immediately after an update.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Imagine a car that will not start. You would not automatically assume the entire engine needs replacing; you would first check smaller, cheaper things: is there fuel, is the battery charged, is a fuse blown. Application troubleshooting works the same way. Reimaging a machine to fix a single broken application is like buying a whole new car because the radio does not work.
Most software problems live in one of three places: something specific to the person using it (their settings or profile), something specific to the machine itself (a missing component or corrupted installation), or something specific to the data the person is working with (a corrupted file). Finding which of these three it is narrows the fix enormously before you touch anything.
Key ideas
If you remember nothing else from this topic, remember these.
- Application crashes, freezes, and slow performance often point to resource exhaustion, corrupted files, or conflicting background processes rather than the application itself being faulty.
- Safe Mode isolates the operating system from third-party drivers and startup programs, making it a key diagnostic step for boot and stability issues.
- Malware symptoms overlap heavily with legitimate software problems, so ruling out infection early with a reputable scanner avoids wasted troubleshooting time.
- System File Checker (sfc /scannow) and DISM repair corrupted or missing Windows system files that ordinary reinstalls would not fix.
- Application-specific logs, found in Event Viewer or the application's own log directory, frequently contain the exact error that a vague on-screen message hides.
- Uninstall and clean reinstall should follow a specific order: remove the app, delete leftover configuration folders, then reinstall fresh, since leftover config is a common cause of repeat failures.
Resolving a Windows application that crashes on launch after an update
A worked example, step by step.
A business application crashes immediately after launch on several machines the day after a vendor update was pushed, while it worked fine the day before.
- 01Step 1Identify the problem by confirming the update timing correlates with the crash onset across multiple affected machines.
- 02Step 2Open Event Viewer, navigate to Windows Logs then Application, and locate the Application Error event with the exact faulting module name.
- 03Step 3Note the faulting module points to a specific DLL shipped with the update, supporting a theory that the update itself is defective.
- 04Step 4Check the vendor's support site or release notes for a known issue matching the faulting module.
- 05Step 5As an immediate mitigation, roll back the application to the previous version using the vendor's installer or Programs and Features.
- 06Step 6Confirm the application launches successfully after rollback on one test machine before deploying the rollback more broadly.
- 07Step 7Run sfc /scannow on one affected machine as a secondary check to rule out unrelated system file corruption contributing to the crash.
- 08Step 8Deploy the rollback to remaining affected machines and monitor the vendor's site for a corrected update.
- 09Step 9Document the faulting module, the workaround applied, and set a reminder to test the corrected update in an isolated machine before wide deployment next time.
Outcome: All affected machines return to a working application state, and a controlled testing step is added before future vendor updates are deployed fleet-wide.
Software Troubleshooting Reference
Worth keeping at hand while you work.
- sfc /scannow
- Scans and repairs protected Windows system files
- DISM /Online /Cleanup-Image /RestoreHealth
- Repairs the Windows component store used by sfc
- Safe Mode
- Boots Windows with minimal drivers and no startup programs
- Event Viewer Application log
- Records application crashes and their faulting module
- Programs and Features
- Windows applet for uninstalling or repairing installed software
- Task Manager end task
- Force-closes an unresponsive application
- %appdata%
- Common location for per-user application configuration files
- Clean boot
- Starts Windows with a minimal set of drivers and startup programs for isolation testing
- Compatibility mode
- Runs an older application under emulated settings for a prior Windows version
- Windows Update rollback
- Uninstalls a recently applied update causing instability
- Malware scan
- First-pass check to rule out infection as the cause of odd behavior
- Application log files
- Vendor-specific logs often more detailed than Windows Event Viewer entries
Common misunderstandings
What most beginners get wrong here.
Reinstalling an application always clears its configuration.
Uninstalling frequently leaves configuration folders behind, which can carry the same corruption into the fresh install.
Safe Mode fixes the underlying problem by itself.
Safe Mode isolates the cause for diagnosis; it does not repair anything on its own.
sfc /scannow fixes all types of software corruption.
It only repairs protected Windows system files, not third-party application files or user data corruption.
A crash with a generic error message means the application itself is unfixable.
The Event Viewer or the application's own logs usually reveal a specific faulting component that can be addressed.
Malware should be checked last after every other theory is exhausted.
A quick malware scan early avoids wasting time troubleshooting symptoms actually caused by an infection.
Exam traps
How the question writers try to catch you out.
- Expect a question asking which command repairs corrupted Windows system files, distinguishing sfc from DISM.
- A scenario may test the correct order of uninstall, delete leftover config, then reinstall.
- Watch for questions where Safe Mode is the correct next diagnostic step given an unstable boot symptom.
- Exam may test that Event Viewer's Application log is where a crashing app's faulting module is recorded.
- Questions may test recognizing malware as a root cause disguised as an application performance issue.
Check yourself
Answer in your head first, then reveal. This is not scored.
What does sfc /scannow repair?
What is the purpose of booting into Safe Mode during troubleshooting?
Where would you find the exact faulting module of a crashing Windows application?
What command repairs the Windows component store that sfc relies on?
Why should leftover configuration folders be deleted during a clean reinstall?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
Software troubleshooting isolates whether a fault lies in the application binaries, the user profile and its settings, system components such as runtimes and drivers, data files, permissions, or an incompatible update. Testing a second user profile, a second machine, and a second data file usually identifies the layer within minutes.
Why It Matters
Rebuilds cost hours of technician and user time and often destroy the evidence. Precise diagnosis reduces repeat tickets and identifies fleet-wide problems, such as a bad update, before they spread.
How It Works
- Applications load configuration from per-user locations, then shared system components.
- Updates replace binaries and may change required runtime versions or permissions.
- Crash and application logs record faulting modules and exception codes.
Where You See It
- Line-of-business app support, Office and browser issues, deployment rollouts, and post-update incidents.
Key Terms
- Profile
- The per-user settings and data location for an application or OS.
- Runtime
- Shared components an application depends on, such as .NET or Java.
- Compatibility mode
- A setting that emulates older OS behaviour for legacy software.
- Rollback
- Reverting to a previous version of an application or update.
- Safe mode
- A reduced OS environment for isolating third-party interference.
Examples
- If a fault follows the user to another PC, the cause is likely the roaming profile or account, not the machine.
- If one document fails everywhere and others open normally, the data file is corrupt.
Common Problems
- Crash on launch
- Missing runtime
- Corrupt profile or cache
- Permission denied to a data path
- Update regression
How It Fails
- A shared runtime update breaks one legacy application while others continue working.
- A corrupted cache reproduces the fault after every reinstall until the profile data is cleared.
- A path permission change breaks saving for one department only.
How to Troubleshoot
- Reproduce the fault deliberately and capture the exact error text.
- Test with another profile, another machine, and another file.
- Check recent updates and consider a controlled rollback.
Practical Knowledge
- Copy, do not delete, profile data when testing so the user can be restored.
- Report fleet-wide patterns rather than closing repeated identical tickets.
Exam Coverage
- Application troubleshooting steps
- Profile, permission, and dependency faults
- Update and compatibility issues
Interview Questions
- How do you tell whether an app fault belongs to the user or the machine?
- When is a reinstall the wrong first action?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Reading and courses
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Reproduce a fault under a fresh test profile and record the difference.
- 02Find the log location for an application you support.