Information to focus on in Crash dump

Crash occur in a function, and 95% of crash are caused by one of the following two cases: The function that occurs crash obtains the wrong argument. The function that occurred crash used the corrupted internal data.

The process of code execution is the process of changing the data. For the same piece of code, in the same environment, if the data used are the same, the result of execution is certainly unique. If a function crashes, then it is certain that the data used is different from the ideal situation. The data source used by the function: one is the parameter passed in by the function, and the other is the member variable or global variable that the function body refers to.

So to analyze crash dump, most of the situation is finding the source of the wrong data. Here are some common examples of data errors: using uninitialized variables. For example, there are no pointers for allocating memory, no initialized criticalsection. The function parameters were calculated incorrectly. For example, when calling a function, the order of incoming parameters is mistaken, and the string operation is wrong with the string length. Using data incorrectly causes corruption to occur. For example, double free causes the heap curruption, in the multi-threaded environment forgets the synchronization causes according to the global variable computation error, the COM addref and the release call does not match. Use data in a logical manner against the program. For example, a function that starts using these resources before the program loads the necessary resources.

Thus, the analysis of crash dump is entirely dependent on the program's condition. The ability to dig out useful information from crash dump depends on how familiar the target program is. It includes the program architecture, the function of important functions, the important data structure, the call logic between functions, and the implementation details of the key functions. Mastery of the basics, including compilations, exceptions, memory, APIs, messages, CRT, and much more.

In general, analyzing a dump can be done in the following steps: See what kind of exception caused the crash. Align symbol, find the name of the function that crashed, and the corresponding assembly code and source code. Lists callstack check if callstack is reasonably checking if the function that crashed has got the correct parameters. Check that the data used by the crashed function is correct. Combine the above information, conceive the ins and outs, then use the data to prove, or disprove your own conjecture. Get more meaningful information through further operations. such as activating PageHeap, re-fetching the dump, or simply making live debug

Article about the CRT: http://www.codeproject.com/KB/cpp/Short_Story_VCPP_CRT.aspx?msg=2319521

Excerpt from: <windows high-efficiency error > for user-state programs