I've worked in IT for more than 20 years, but I still haven't found a consistently reliable way to troubleshoot random application crashes beyond checking Event Viewer and searching the error message. What's your usual process, and which tools do you use to determine whether the cause is the application, permissions, networking, security software, the operating system, or the server?
5 Answers
A crash that appears random is often caused by something external to the application, such as an EDR product, firewall rule, permissions change, unavailable share, profile synchronization, or a recent update. Compare affected and unaffected systems, note exactly when the problem started, and correlate it with software, policy, and OS changes before assuming the server is responsible.
Process Monitor is usually the next step when the normal logs aren’t enough. Filter it to the affected process and look for repeated failures, high activity, or calls immediately before the application becomes unresponsive. If the program creates a crash dump, WinDbg or DebugDiag can help analyze it. For a hung application, saving a dump from Task Manager and examining it can provide evidence when dealing with a vendor or security-software provider.
Sometimes rebuilding or replacing the workstation is the practical answer, especially when you’re supporting a large number of endpoints with limited staff. Automation, standardized images, and profile migration can resolve local corruption quickly. Just be careful: a reimage won’t fix a shared configuration problem, an incompatible security agent, or a vendor bug that affects every machine.
Start with the basics in order: reproduce the problem if possible, ask what the user was doing when it happened, and capture the application’s own error message and logs. Then check Event Viewer. If that doesn’t identify the cause, use Process Monitor to trace file, registry, process, and network activity around the failure. It can reveal things like access-denied errors, missing files, dead network shares, or other environmental problems.
Don’t overlook the vendor. For line-of-business software, the application logs and a support case may be the only way to determine whether it’s a known bug. Staying current without immediately installing every bleeding-edge update can also help. If the issue affects many users, endpoint monitoring or DEX tools may show patterns involving a particular version, device, update, or location.
That’s useful for a true crash. In my case, some applications become unresponsive or consume excessive CPU and memory before eventually recovering, so I’ll look into capturing a dump during that state.