Troubleshoot: Application Crashes and Hangs

Application crashes and hangs are two distinct types of software failures that IT professionals encounter daily. A crash is an abrupt termination of an application, often accompanied by an error dialog or the application simply disappearing from the screen. A hang occurs when an application stops responding to user input but remains visible on the screen; the window may show a 'Not Responding' title bar in Windows, or the spinning cursor (beach ball) on macOS. Both conditions prevent the user from completing tasks and can lead to data loss.

From the operating system's perspective, a crash is typically caused by an unhandled exception – an error condition that the application code did not anticipate or manage. Common exceptions include access violations (trying to read or write memory the process does not own), division by zero, stack overflow, or invalid instruction. When such an exception occurs, the OS's exception handler terminates the process and may generate a crash dump (memory dump) for debugging.

A hang, on the other hand, is usually caused by a thread deadlock, infinite loop, or waiting on a resource that never becomes available. The process is still alive (its threads exist), but one or more threads are stuck. The OS can detect hangs through watchdog timers or by monitoring window messages; if a window fails to respond to a 'ping' message within a timeout (typically 5 seconds on Windows), the OS marks it as 'Not Responding'.

When an application starts, the OS creates a process with its own virtual address space, handle table, and at least one thread. The thread executes the application code. If the code attempts an invalid operation – for example, dereferencing a null pointer – the CPU raises an exception (e.g., access violation on x86/x64). The OS's exception dispatcher checks if the application has registered a structured exception handler (SEH) for that exception. If not, the OS invokes the final handler, which terminates the process and displays an error to the user (e.g., 'Application has stopped working').

For hangs, the mechanism often involves the Windows Message Pump. In GUI applications, a thread runs a message loop that retrieves and dispatches messages (keyboard, mouse, timer, etc.) from the thread's message queue. If the thread enters an infinite loop or is waiting on a synchronization object (mutex, semaphore, event) that is never signaled, it stops processing messages. The OS's Hung Window Detection component periodically sends a WM_NULL message to the window; if the window does not respond within a timeout (default 5 seconds), Windows marks the window as 'Not Responding' and offers the user the option to force close the application.

When an application crashes or hangs, follow a structured approach:

Process Monitor from Sysinternals logs file system, registry, and process/thread activity in real time. To troubleshoot a crash or hang: 1. Start ProcMon with filtering for the application's process name. 2. Reproduce the crash/hang. 3. Stop capture and look for 'ACCESS DENIED' errors, 'NOT FOUND' file operations, or repeated registry queries that indicate a loop. 4. This can reveal missing DLLs, permission issues, or infinite file access attempts.

In a typical enterprise environment, application crashes and hangs are a daily occurrence. Consider a financial trading firm where a proprietary trading application hangs during peak market hours. The application is multithreaded and uses a custom in-memory database. A deadlock occurs when two threads both hold a lock needed by the other. The application stops responding, and traders lose ability to execute trades. The IT team uses Process Explorer to identify threads waiting on WaitForSingleObject. They capture a dump and analyze it with WinDbg, revealing the deadlock. The developers then fix the lock ordering. In production, such issues are mitigated by implementing watchdog timers that automatically restart hung processes, and by using high-availability clusters with failover.

Another scenario: a large hospital uses an electronic health records (EHR) application that crashes when printing patient summaries. The crash is intermittent and occurs only on certain workstations. The support team discovers that the crash is caused by a missing printer driver – the application attempts to call a printer API that returns an error, leading to an unhandled exception. The solution is to ensure all workstations have the correct printer drivers installed and to update the application to handle the error gracefully. This highlights the importance of testing with all supported peripherals.

A third example: a cloud-based CRM application hangs for users when they upload large CSV files. The hang occurs because the application's UI thread is blocked waiting for the file upload to complete. The developers should have used asynchronous I/O. The temporary workaround is to instruct users to split files into smaller chunks. The permanent fix involves rewriting the upload logic to use background threads. In production, monitoring tools like Application Insights can detect hangs by tracking response times and alerting when a page takes longer than 10 seconds to load.