Problem Reports and Solutions.
In Windows XP, Vista and Windows 7, "Problem Reports and Solutions" in Control Panel (click "Classic View") allows you to define how application crashes are handled by Windows.
When you double "Problem Reports and Solutions" and select "Change Settings", you can configure Windows to "Check for solutions automatically" and in Advanced Settings, you can select "Automatically send more information if it is needed to help solve problems" which will give the developer of the application a better chance to diagnose and fix issues.
When an application crashes, a Problem Report is sent to Microsoft. The developer of the application can log on to the Microsoft WinQual site and download problem report information associated with the applications they have developed. This information is used to help identify the cause of the error hopefully resulting in a fix. If the error is identified and fixed, the developer will post a "response" on the Microsoft web site. This response may be that a new version or patch to the application is available to fix the issue, or it might be a description of a workaround. Either way, your PC will periodically check for fixes to previous problems on the Microsoft site and alert you if solutions are available.
But how is the specific problem identified?
Each application installed on your computer is typically made up of a number of modules.
e.g. Application.exe might use some code inside Application.dll and Utilities.dll and these modules make use of general system modules e.g. user32.dll and kernel32.dll installed as part of the Windows Operating System.
When an application runs, it loads into memory the modules that it uses (in this case, Application.exe, Application.dll, Utilities.dll, user32.dll and kernel32.dll) and the program begins to execute instructions (code) inside those modules.
To keep a track of which instruction is to be executed next, there is an Instruction Pointer (IP) which contains the address of the instruction currently being executed.
There are a number of reasons why an application may crash when executing one of these instructions. These crashes are known as exceptions. If the program has jumped into an area of memory that doesn't contain any instructions, for example, you may see an Invalid Operation exception. Or perhaps an instruction attempts to divide 10 by zero - this will cause a Divide By Zero exception.
In our example, if Utilies.dll tried to divide a value by zero then the problem report data may look something like this.
Problem Event Name: APPCRASH
Application Name: application.exe
Application Version: 2.0.02510.12346
Application Timestamp: 42e4438e
Fault Module Name: utilities.dll
Fault Module Version: 1.0.02310.12345
Fault Module Timestamp: 4549bdf8
Exception Code: c0000094
Exception Offset: 000a102b
OS Version: 6.0.6000.2.0.0.256.1
Locale ID: 1033
In this case the module is nicely identified as utilities.dll and the offset to the faulty instruction within the module is given as 000a102b and the reason for the crash is given as C0000094 (Divide By Zero).
This, along with the version of the module, goes a long way to assist the developer of the application identify and fix the fault. It also allows the particular fault to be uniquely identified so that if another user has the same fault then their information is added to the pool of information associated with the fault - thereby increasing the chances of the developer finding the reason for the fault and producing a fix. e.g. if the only users in the world reporting the fault are in Greece (identified by the locale id) then perhaps the application has a problem displaying Greek characters.
However, this information only uniquely identifies a fault if the module (utilities.dll) can be identified. Consider this next example.
If our application erroneously jumps to an area of memory that does not contain any instructions and attempts to start executing code at that address, then the Instruction Pointer will now be pointing outside any identifiable module.
i.e. it isn't in utilities.dll or any other modules that come as part of the application or Windows. How then can the crash that results be uniquely identified?
The Problem Reports and Solutions system in Windows attempts to "invent" a unique module name as follows.
A program is made up of smaller units called functions. Functions call each other to do work (e.g. display an icon or work out some calculation). A called function may call other functions which themselves call other functions. The information about who has called whom is stored in what is known as a Stack. Every application thread has its own stack and, when a crash occurs, the stack contains useful information that identifies who was calling whom at the time of the crash. This stack information is combined into what is known as a Hash to create a "semi" unique number for the crash. The prefix StackHash_ is added to the number (which is in hexadecimal (base 16) form) giving a module name that appears in the crash information as shown below.
Problem Event Name: APPCRASH
Application Name: iexplore.exe
Application Version: 7.0.6000.16757
Application Timestamp: 48e4238e
Fault Module Name: StackHash_1ea1
Fault Module Version: 6.0.6000.16386
Fault Module Timestamp: 4549bdf8
Exception Code: c0000374
Exception Offset: 000aa0fb
OS Version: 6.0.6000.2.0.0.256.1
Locale ID: 1033
Therefore, StackHash is not a real module. It is a constructed name because the Instruction Pointer was pointing to no known module at the time of the crash. The number after the StackHash_ is a semi-unique number calculated at the time of the crash such that if the same crash occurred on multiple PCs then they have a reasonable chance to be correlated.
For a programmer to successfully track down the cause of the problem, he needs either to be able to reproduce the problem or he needs a copy of the Stack at the time of the crash. The stack will be included in a minidump which is a file automatically generated and stored at the time of the crash and sent to Microsoft as part of the crash information if the PC is configured to do so.
Some of the reasons for StackHash crashes include...
The application itself has a fault causing it to call a function in a piece of memory that does not contain any code as in the example above.
A virus checker, virtual drive S/W, security systems (or other application) has injected a piece of code into the address space of the application that crashes for some reason. In this case there is no identifiable module so a StackHash_XXXX will be created.
A virus has infected the machine and the virus code is executing in the context of the faulting application.
There is a bug in the operating system or other shared component on the system.
The application has become corrupted either by a disk error or virus.
What to do if you get a StackHash?
1. First configure Problems Reports and Solutions in Control panel to Check for Solutions automatically and automatically send more information. Then check if there are fixes available for your application. If there are then download and install them.
2. Make sure your Window Operating system has all the latest service packs, security updates and other fixes installed.
3. Most applications have a Check for Updates feature. Use it to make sure you have the latest version of the S/W. Alternatively visit the company website and check for new versions and patches.
4. Run an up-to-date virus checker on the machine and fix any issues. If a virus is detected in the application then you may need to reinstall the application.
5. Re-install the application. Through Control Panel - Programs - Uninstall a program. Right click the application and click Uninstall - Change. This should launch the installer which may give the option to Repair the installation. If not then you will need to uninstall and reinstall - make sure you have the original installation discs available before uninstalling.
6. Disable any Virtual Drive software that may be hooking in to the application. If the problem goes away then contact the developer of the Virtual Drive software.
7. Disable any Virus checkers on your machine (temporarily) and run the application again. If the problem goes away then contact the developer of the Virus Checking software.
8. Check if the problem is reproducible (after a reboot). If it is, then attempt to narrow down the exact steps that cause the fault, write them down and contact the support department for the company that developed the application providing as much information about the crash and what you have done so far to attempt to resolve the issue.
