This chapter covers troubleshooting application crashes, a core topic in the CompTIA A+ 220-1102 Software Troubleshooting domain (Objective 3.4). Application crashes are among the most common issues faced by support technicians, and exam questions frequently test your ability to identify causes and apply appropriate fixes. Understanding the underlying mechanisms—memory management, process execution, and resource conflicts—is essential for both the exam and real-world troubleshooting. This chapter provides a deep dive into crash types, diagnostic tools, and step-by-step remediation strategies.
Jump to a section
Imagine a busy restaurant kitchen where orders come in from the dining room. The head chef (the operating system) manages a team of line cooks (applications), each responsible for specific dishes. When a cook receives an order, they gather ingredients (allocated memory) and start cooking. If a cook runs out of a key ingredient (memory leak), they can't finish the dish and just stand there waiting, blocking the workstation. If a cook tries to use a pot that another cook is already using (resource conflict), they cause a clatter and potentially ruin both dishes. Sometimes a cook receives an order that makes no sense—like 'grill a salad' (invalid instruction)—and they freeze up, unable to proceed. The head chef can either try to snap the cook out of it (restart the application) or send them home and have another cook cover their station (terminate and relaunch). If the whole kitchen becomes chaotic—multiple cooks frozen, orders piling up—the head chef may call a 'kitchen reset' (system reboot) to clear all stations and start fresh. In computing, an application crash is similar: the program encounters a condition it cannot handle, such as accessing invalid memory (like using a wrong pot), running out of resources (missing ingredient), or executing an illegal instruction (impossible order). The operating system steps in to terminate the offending process, freeing its resources and protecting other running applications from being affected.
What is an Application Crash?
An application crash occurs when a program stops functioning as expected due to an unhandled exception, resource exhaustion, or violation of system protections. The operating system detects the fault and terminates the process, often displaying an error message such as 'Program has stopped working' or 'Fatal error'. Crashes can be intermittent or consistent, and they may affect a single application or multiple applications simultaneously.
Why Applications Crash
Applications crash for several reasons, all rooted in how software interacts with hardware and the OS. The most common causes include:
Memory leaks: The application allocates memory but fails to release it after use. Over time, available RAM diminishes, eventually causing the OS to deny further allocations, leading to a crash. Memory leaks are often caused by poor coding practices, such as forgetting to call free() or delete in languages like C/C++.
Access violations: The program attempts to read or write to a memory address it does not own. This triggers a segmentation fault (Unix/Linux) or access violation (Windows). Causes include dereferencing null pointers, buffer overflows, or using dangling pointers.
Resource conflicts: Two applications try to use the same hardware resource (e.g., a serial port, graphics hardware) without proper arbitration. For example, two programs attempting to capture video from the same webcam can cause one or both to crash.
Insufficient permissions: The application lacks necessary permissions to access a file, registry key, or system resource. This is common in user account control (UAC) scenarios where an application expects administrative privileges but runs as a standard user.
Corrupted or missing files: Essential DLLs, configuration files, or data files are missing or damaged. For instance, a game may crash on launch if a DirectX runtime file is corrupted.
Incompatible software: The application was designed for a newer or older version of the OS, or conflicts with other installed software (e.g., antivirus or third-party drivers).
Malware: Viruses, trojans, or other malicious software can corrupt application files or inject code that causes crashes.
Hardware failures: Faulty RAM, overheating CPU, or failing hard drives can cause applications to crash as data corruption or timing errors occur.
How the OS Handles a Crash
When an application crashes, the operating system intervenes to protect system stability. The process is as follows:
Exception generation: The CPU detects an illegal operation (e.g., division by zero, invalid memory access) and raises an exception. The OS's exception handler receives the interrupt.
Exception dispatch: The OS checks if the application has registered an exception handler (e.g., try/except blocks in .NET or signal handlers in Unix). If so, the handler may attempt to recover. If not, the OS proceeds to terminate.
Process termination: The OS sends a termination signal (SIGTERM or SIGKILL on Unix) or calls TerminateProcess on Windows. All threads are halted, and the process's memory and handles are released.
Error reporting: On Windows, the Windows Error Reporting (WER) service creates a dump file and may prompt the user to send error details to Microsoft. On Linux, core dumps may be generated if enabled.
Resource cleanup: The OS reclaims all resources allocated to the process: memory, file handles, network connections, etc. This prevents resource leaks from affecting other applications.
Key Components and Defaults
Windows Error Reporting (WER): Enabled by default. Stores crash dumps in %LOCALAPPDATA%\CrashDumps and %SystemRoot%\Minidump. Dump files can be analyzed with WinDbg or Visual Studio.
Application Event Log: Windows logs application errors to Event Viewer under 'Windows Logs > Application'. Each event has an Event ID (e.g., 1000 for application errors) and includes faulting module name, exception code, and offset.
Dr. Watson (drwtsn32.exe): Legacy debugger in older Windows versions; replaced by WER in Vista and later.
Task Manager: Used to end unresponsive applications. Can also monitor memory and CPU usage to detect leaks.
Process Explorer: Advanced task manager from Sysinternals that shows detailed process information, including handles, DLLs, and memory usage.
System File Checker (SFC): Scans and repairs protected system files. Command: sfc /scannow.
Deployment Imaging Service and Management (DISM): Repairs Windows image corruption. Command: DISM /Online /Cleanup-Image /RestoreHealth.
Configuration and Verification Commands
- Check Event Log:
Event Viewer > Windows Logs > ApplicationLook for Error events with source 'Application Error' or 'Application Hang'. - Enable/Disable WER:
Services.msc > Windows Error Reporting Service > Startup type: Automatic (Delayed Start) or Disabled- Generate a memory dump manually:
Task Manager > Details tab > Right-click process > Create dump file Dumps are saved to %TEMP%.
- Test memory for hardware issues:
Windows Memory Diagnostic (mdsched.exe)Requires a reboot. - Run SFC:
sfc /scannow- Run DISM:
DISM /Online /Cleanup-Image /RestoreHealth- Check for malware: Use Windows Defender or third-party AV. Run a full scan. - Check disk for errors:
chkdsk /f /r- Check for driver issues:
Driver Verifier (verifier.exe)Enables stress testing of drivers; can cause crashes if faulty drivers are present.
How Crashes Interact with Related Technologies
Virtual Memory: When physical RAM is exhausted, the OS pages memory to disk. If the page file is full or corrupt, applications may crash. Ensure page file size is adequate (typically 1.5x RAM).
User Account Control (UAC): Applications that require elevation may crash if they don't handle the 'access denied' error gracefully. Always run such apps as administrator.
Compatibility Mode: Older applications may crash on modern Windows. Use compatibility settings (right-click > Properties > Compatibility) to emulate older OS versions.
Application Virtualization: Tools like Microsoft App-V or VMware ThinApp run applications in isolated environments. Crashes in these environments are often due to configuration mismatches.
Sandboxing: Windows Sandbox or third-party sandboxes isolate applications. Crashes inside the sandbox do not affect the host.
Antivirus/EDR: Some security software hooks into application processes and can cause crashes if they misbehave. Temporarily disabling AV can help diagnose.
Common Crash Types and Their Causes
Application Not Responding (Hung): The UI thread is blocked (e.g., by a long operation or deadlock). The app is still running but not processing messages. Task Manager shows 'Not Responding'.
Blue Screen of Death (BSOD): A system-level crash caused by a driver or hardware issue. The application crash may be a symptom of the underlying problem.
Access Violation Error: The app tried to access invalid memory. Often due to bugs in the application or corrupted data.
DLL Not Found: A required DLL is missing or not registered. Use regsvr32 to register DLLs or reinstall the application.
Runtime Error: Specific to programming environments (e.g., Visual C++ Runtime). Install the correct redistributable package.
Unhandled Exception: The application did not handle an error condition. Example: dividing by zero or file not found.
Troubleshooting Methodology
The CompTIA A+ troubleshooting methodology applies: 1. Identify the problem: Gather details from the user, check event logs. 2. Establish a theory of probable cause: Common causes include memory leaks, corrupt files, permissions, compatibility. 3. Test the theory: Use diagnostic tools (e.g., Event Viewer, Performance Monitor). 4. Establish a plan of action: Choose a fix based on the cause (e.g., reinstall app, run SFC, update drivers). 5. Implement the solution: Apply the fix and test. 6. Verify full system functionality: Ensure no other issues. 7. Document findings: Record the cause and resolution.
Identify the Crash Symptoms
Begin by gathering information from the user: What were they doing when the crash occurred? How often does it happen? Are there any error messages? Take note of the exact text of any error dialog, as it often contains clues (e.g., 'Exception code: 0xc0000005' indicates access violation). Check if the crash affects only one application or multiple. If multiple applications crash, suspect a system-wide issue like memory failure or malware.
Check Event Viewer Logs
Open Event Viewer and navigate to Windows Logs > Application. Look for Error events with source 'Application Error' or 'Application Hang'. The event details include the faulting module name (e.g., 'ntdll.dll' or 'kernel32.dll'), exception code (e.g., 0xc0000005 for access violation), and fault offset. This information helps pinpoint the problematic module. For example, a crash in 'ntdll.dll' often indicates memory corruption, while a crash in a third-party DLL suggests that specific component is faulty.
Determine Recent Changes
Ask the user if the crash started after a specific event, such as installing new software, updating drivers, or applying Windows updates. Use System Restore to revert recent changes if needed. Check the Installed Updates list in Control Panel. If a recent Windows update caused the crash, uninstall it temporarily. Also check for hardware changes: new RAM, graphics card, or peripherals can introduce driver conflicts.
Run System File Checker
Open Command Prompt as Administrator and run `sfc /scannow`. This command checks all protected system files for corruption and replaces any that are damaged. If SFC finds issues but cannot repair them, follow up with DISM: `DISM /Online /Cleanup-Image /RestoreHealth`. DISM can fix component store corruption that SFC relies on. After running both, reboot and test the application.
Check for Memory Leaks
Open Task Manager and monitor the application's memory usage over time. If the memory (Private Working Set) steadily increases without releasing, a memory leak is likely. Use Resource Monitor or Performance Monitor to collect detailed data. For persistent leaks, update the application or contact the vendor. If the application is custom-developed, work with developers to fix the code. As a workaround, schedule periodic restarts of the application.
Test in Clean Boot State
Perform a clean boot to eliminate software conflicts. Run `msconfig`, select 'Selective startup', and uncheck 'Load startup items'. Disable all non-Microsoft services. Reboot and test the application. If the crash stops, enable services one by one until the culprit is found. Common troublemakers include antivirus software, third-party firewalls, and shell extensions. This method isolates the conflicting component.
Update or Reinstall Application
Check the application vendor's website for updates or patches. Many crashes are fixed in newer versions. If no update exists, uninstall the application completely (using Programs and Features or a dedicated uninstaller) and reinstall from a fresh download. Ensure all prerequisites (e.g., .NET Framework, Visual C++ Redistributables) are installed. After reinstallation, test immediately.
In an enterprise environment, application crashes can disrupt productivity and require systematic troubleshooting. Consider a scenario where a financial trading application crashes randomly on several workstations. The IT support team first checks Event Viewer and finds consistent 'Application Error' events with faulting module 'MSVCR100.dll'. This indicates a Visual C++ runtime issue. The solution is to reinstall the Microsoft Visual C++ 2010 Redistributable package. In another case, a CRM application crashes when users try to print reports. The crash occurs only on Windows 10 version 20H2. Using compatibility mode set to Windows 7 resolves the issue. A third scenario involves a custom in-house application that crashes after running for 2-3 hours. Performance Monitor shows a steady increase in private bytes until memory reaches 2 GB. The developers identify a memory leak in a loop that allocates strings without freeing them. The fix involves a code update. In production, large-scale deployments use tools like System Center Configuration Manager (SCCM) to push updates and run scripts that collect crash dump files for analysis. Performance considerations include ensuring adequate RAM (e.g., 16 GB per workstation for memory-intensive apps) and monitoring page file usage. Misconfigurations, such as setting the page file too small or disabling Windows Error Reporting, can hinder diagnosis. Best practices include enabling automatic memory dump generation, maintaining up-to-date antivirus definitions, and using application whitelisting to prevent unauthorized software that may cause conflicts.
The CompTIA A+ 220-1102 exam (Objective 3.4) focuses on troubleshooting application crashes using the CompTIA troubleshooting methodology. Key areas tested include: interpreting error messages, using Event Viewer to identify faulting modules, and applying fixes such as System File Checker, DISM, and clean boot. Common wrong answers on the exam include: 'Reinstall the operating system' when the issue is a single application (overkill), 'Run a memory diagnostic' for a software crash (memory test is for hardware), and 'Disable UAC' for permission-related crashes (UAC should be configured properly, not disabled). Candidates often choose 'Update the driver' for crashes involving ntdll.dll, but ntdll.dll crashes usually indicate memory corruption, not driver issues. The exam loves to test specific values: Event ID 1000 for application errors, exception code 0xc0000005 for access violation, and the command sfc /scannow. Edge cases: a crash that only occurs when the application is run as a standard user (fix: run as administrator or adjust permissions), and crashes caused by corrupted user profiles (fix: create a new user profile). To eliminate wrong answers, always match the symptom to the most likely cause: if an error message mentions a specific DLL, suspect missing runtime; if the crash is intermittent after hours of use, suspect a memory leak; if it started after a Windows update, uninstall the update. Remember that the troubleshooting methodology always starts with identifying the problem, not immediately applying a fix.
Application crashes are often due to memory leaks, access violations, or missing dependencies.
Event ID 1000 in Application Event Log indicates an application error.
Exception code 0xc0000005 means access violation (invalid memory access).
Use `sfc /scannow` to repair corrupted system files.
Use `DISM /Online /Cleanup-Image /RestoreHealth` to fix system image corruption.
Clean boot (msconfig) helps isolate software conflicts.
Windows Error Reporting (WER) creates dump files for analysis.
Memory leaks cause gradual performance degradation and eventual crashes.
Always follow the CompTIA troubleshooting methodology: identify, theorize, test, plan, implement, verify, document.
Do not assume hardware failure without first ruling out software causes.
These come up on the exam all the time. Here's how to tell them apart.
Reinstall Application
Replaces all application files with fresh copies
Does not affect other applications or system settings
May not fix issues caused by system-wide problems (e.g., missing runtime)
Quick to perform if the installer is available
Best for crashes specific to one application
System Restore
Reverts system files, registry, and installed programs to a previous state
Can fix crashes caused by recent changes (e.g., driver update, software install)
Does not affect user data files
Takes longer and requires a restore point to exist
Best for crashes that started after a specific system change
Mistake
Application crashes are always caused by malware.
Correct
While malware can cause crashes, the majority are due to software bugs, memory leaks, compatibility issues, or corrupted files. Always check event logs and recent changes before scanning for malware.
Mistake
If an application crashes, you should immediately reinstall the OS.
Correct
Reinstalling the OS is a last resort. Most crashes can be resolved by reinstalling the specific application, running SFC, or performing a clean boot to isolate conflicts.
Mistake
A crash with error code 0xc0000005 always means faulty RAM.
Correct
0xc0000005 is an access violation, which can be caused by software bugs, corrupt data, or memory corruption, but not necessarily hardware. Run a memory diagnostic only after ruling out software causes.
Mistake
Running an application as administrator always fixes crashes.
Correct
Running as administrator only helps if the crash is due to insufficient permissions. It does not fix crashes caused by memory leaks, corrupt files, or compatibility issues.
Mistake
Event Viewer is only for system administrators and not useful for application crashes.
Correct
Event Viewer is the primary tool for diagnosing application crashes. It logs detailed error information including faulting module, exception code, and process ID, which are essential for identifying the root cause.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The first step is to identify the problem by gathering details from the user and checking Event Viewer. Look for error codes, faulting modules, and recent changes. This aligns with the CompTIA troubleshooting methodology: identify the problem before establishing a theory of cause.
Open Event Viewer, expand Windows Logs, and select Application. Look for Error events with source 'Application Error' or 'Application Hang'. Double-click an event to see details like faulting module name, exception code, and fault offset. For example, 'Faulting module name: ntdll.dll' suggests memory corruption.
Exception code 0xc0000005 is an access violation. It means the application tried to read or write to a memory address it did not have permission to access. This can be caused by software bugs, corrupted data, or hardware issues like faulty RAM.
No. Only run a memory diagnostic (e.g., Windows Memory Diagnostic) if you suspect hardware failure, such as when crashes are random, affect multiple applications, or are accompanied by system instability like BSODs. Most crashes are software-related.
First, identify the missing DLL from the error message. Reinstall the application that provides the DLL, or install the appropriate Microsoft Visual C++ Redistributable. You can also try registering the DLL with `regsvr32 <filename>.dll`. If the DLL is a system file, run SFC.
A clean boot starts Windows with a minimal set of drivers and startup programs. Use it to determine if a background service or startup application is causing the crash. If the crash stops in clean boot mode, enable services one by one to identify the culprit.
Open Task Manager > Processes tab. Monitor the application's Memory (Private Working Set) column over time. If the value steadily increases without decreasing, a memory leak exists. Use Resource Monitor or Performance Monitor for detailed analysis. The fix is to update or patch the application.
You've just covered Troubleshoot: Application Crashes — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?