APP: Application failures – Hang / Crash


Description: Applications and Services often fail in one of two ways – a hang, or a crash.  The reasons behind the failure are different, however much of the data that we need to collect when troubleshooting the issue is quite similar.  If the application that is hanging / crashing is Windows Explorer, please see the support topic content for SHL: Windows Explorer – Hang / Crash.


Scoping the Issue:  For application hangs, there are a couple of things that you can do.  First, check Task Manager.  If the process is unresponsive but is not listed as “Not Responding” in Task Manager, then the application may be functioning normally but is waiting for data – possibly from a network resource.  If you are experiencing an issue as a result of a network bottleneck or network resource failure, the symptom will most likely be evident on multiple client systems – where all their applications waiting on that resource, or set of resources become unresponsive at the same time.  In some instances, the application may be functioning quite normally, however it is actually waiting for user input, but the user input box has somehow been hidden behind other open windows.  If however, the application is listed as “Not Responding” in Task Manager, then it may truly be hung, but keep in mind are some scenarios where applications that are waiting for network resources may also be listed as “Not Responding”.

Application crashes are usually easy to spot.  In most instances, the application exits, and an error message from Dr. Watson or Windows Error Reporting will be displayed.  In many instances, the error message will indicate an Access Violation of some sort and a user-mode dump of the process will be created.


Data Gathering:  In all instances, collecting either MPS Reports with the General, Internet and Networking, Business Networks and Server Components diagnostics, or a Performance-oriented MSDT manifest must be done.  Additional data required may include the following:

  • In the event of a hang, we may need to capture a dump (or a number of dumps) of the application while it is in its unresponsive state.  You can do this by either running ADPLUS.VBS from the Windows Debugging Tools in hang mode.  On Windows Vista and later operating systems, you can also create a dump of the process from within Task Manager.  To do this, highlight the process, right-click and select the “Create Dump File” option.

  • For an application crash, check to see if there is a user-mode dump file.  There are a number of ways to capture this data – from Dr. Watson to Debug Diag.  The resources listed below provide instructions on how to set up your systems to capture application crash dumps


Troubleshooting / Resolution:  After you have gathered the data, there are some things to check:

  • MPS Reports:

    • Review the Event Logs for relevant events – specifically look for Event ID 26 (Application Popup), Event ID 1000 (Application Error) and Event ID 7034 (Service Control Manager) messages that correspond to the times that you are seeing unexpected application failures

    • You should also check the Event Logs and Windows Update logs to see if there were any application updates or patches that preceded the unexpected behavior – there may be a correlation

  • Process Explorer: If you have the opportunity to do so, it may be worth using Process Explorer to examine what an unresponsive application is doing while it is in-state

  • Dump File Analysis:  If you are experienced at looking at dump files, there are some things that you can look for

  • For hang dumps, check for application locks (for example, anti-virus locks), long-running threads and whether or not the application is waiting for data – for example from a network resource or a user input

  • For application crash dumps, running the command !analyze -v may provide a hint as to the cause of the failure.  However, the output of this command may not always identify the real culprit 

Finally – where the application in question is either a custom in-house application or a third-party (non-Microsoft) application, you should always engage either your developer or the application vendor for assistance.  The reason for this is that we do not have access to the application’s source code or symbols – so our debug analysis may be incomplete.  If the application is an in-house application (for example a .NET application) you should open a case with our developer support group for assistance.

Additional Resources: