Application crashes and Application Error with Event ID 1000 is logged
search cancel

Application crashes and Application Error with Event ID 1000 is logged


Article ID: 164976


Updated On:


Symantec Products


An application is crashing and an Application Error with Event ID 1000 is logged in the Windows Application log.

You want to know why the application is crashing and what can be done to remedy it.

Faulting application <application name>, version <version number>, faulting module <module name>, version <version number>, fault address <hex address>.


Windows Vista/Server 2008 and later


When an exception is raised in an application, its exception handler may correct or ignore the condition, rather than allow a failure to propagate up through intervening layers. This is very useful in scenarios where partial failures are expected and it is not desirable to fail an entire operation just because one of several optional parts failed. This exception is called a "first-chance exception", as the application first gets a chance to handle the exception through its exception handler.

For example, a console application may allow to enter Y or N in response to a question, but what if the user enters any other character? If the programmer does not take this possible exception into account, the application would crash. More often than not, an application succesfully handles such an exception. Otherwise applications would crash all the time.

If an application is unable to handle an exception, whether by error of its own or through outside interference (e.g. injection of a Symantec user-mode component), it crashes. If a debugger (WinDBG, DebugDiag, ProcDump, etc.) is attached to the application, it is given a second chance to deal with the exception (typically, by saving a memory dump, which allows further investigation. Hence, the name "second-chance exception".

An Application Error Event ID 1000 is a directly result of a second-chance exception.


Windows Error Reporting (WER) is a flexible event-based feedback infrastructure that allows to take further action when an Application Error event ID 1000 is detected. One such action is the creation of a user-mode dump for further investigation.

Your Symantec product may have configured WER to redirect user-mode dumps to one of its product data folders.

For example, when using Symantec Endpoint Protection (SEP) 14, many processes listed in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\ in the Windows registry shows C:\ProgramData\Symantec\LocalDumps as its DumpFolder value.

If this is the case for the process you are looking to collect a user-mode dump from, navigate to the dump folder and collect the created dump(s). Otherwise, proceed with the following steps to enable the creation of user-mode dumps using WER:

  1. Open regedit.exe.
  2. Create folder C:\Dumps.
  3. Navigate to:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
  4. Right-click the Name/Type/Data area, select New..., and click Multi-String Value. Enter DumpFolder as its name.
  5. Double-click DumpFolder, enter C:\Dumps, and click OK.
  6. Right-click the Name/Type/Data area, select New..., and click D-Word (32-bit) Value. Enter DumpCount as its name.
  7. Double-click DumpCount, enter a and click OK.
  8. Right-click the Name/Type/Data area, select New..., and click D-Word (32-bit) Value. Enter DumpType as its name.
  9. Double-click DumpType, enter 2, and click OK.

This keeps a record of the last 10 user-mode dumps as a result of application crashes in the C:\Dumps folder. These settings take effect immediately; a restart is not required.

If you are experiencing random application crashes in a large environment, consider applying a registry change group policy to the affected client and/or server OUs that includes these settings, but use the C:\Perflogs folder (which is fully writable on any version of Windows) as the dump folder instead to do away with the necessity of having to manually create the C:\Dumps folder.