After more than 20 years in IT, I still haven't found a reliable method for troubleshooting applications that crash or hang seemingly at random. I usually start with the application's error messages, logs, and Windows Event Viewer, but many incidents eventually turn into searching the exact error online. What tools or troubleshooting process do you use to determine whether the cause is the application, permissions, security software, networking, or the server?
4 Answers
Don’t overlook the vendor, especially with line-of-business software. Provide them timestamps, application logs, event details, dump files, and steps to reproduce rather than just saying it crashed. Vendor support can still be frustrating, but they may know about a specific build issue or need diagnostic data that isn’t obvious from the client machine.
Start with the basics in order: reproduce the problem and note exactly what the user was doing, then check the application’s own logs, Windows Event Viewer, and finally use Process Monitor to inspect file, registry, process, and network activity. Reproduction is especially useful because it lets you filter Procmon to the affected process and compare a successful run with a failed one.
Process Monitor is usually the next step when the normal logs don’t explain anything. It can reveal access-denied errors, missing files, dead network shares, firewall blocks, or other environmental problems. Those issues shouldn’t normally crash a well-written application, but they can expose bugs or at least point to a workaround. If the process is hung or consuming excessive CPU and memory, capture a user-mode dump from Task Manager and inspect it with a debugger or DebugDiag.
That’s the sort of situation I’m dealing with: the application sometimes spins up CPU or memory and eventually recovers, but nobody wants to investigate it unless it becomes a major incident.
Sometimes replacing or reimaging the endpoint is the practical answer, especially when managing a large fleet with limited staff. Automation can make that faster than spending hours on a one-off problem, but it won’t solve configuration conflicts, security software interference, profile synchronization issues, or an application bug that affects every updated machine. For recurring problems, collect crash dumps and compare affected systems instead of assuming a rebuild fixed the root cause.
Vendor support is worth trying, although some vendors are just as unsure as the internal IT team, and their recommended changes may not be acceptable in the environment.