Click here to Skip to main content
15,435,438 members
Articles / Programming Languages / C++
Posted 24 May 2013

Tagged as


50 bookmarked

Using Windows Event Viewer to debug crashes

Rate me:
Please Sign up or sign in to vote.
4.93/5 (31 votes)
24 May 2013CPOL4 min read
This article talks about using the Windows event viewer to get the actual crashed module and location of the crash in the code. The sample code is written in C++ to generate different types of crashes like access violation and stack overflow.


I always hear from my juniors and QA' about a particular crash being easily reproduced at client machine and not being reproduced at their machines. This is a tricky problem, as developers cannot debug the crash at client's machine. The end result is endless communication between support team and the customer or even live meetings. Few smart programmers develop a crash logging system on their own to nail down the code which is causing the crash. Few others go over all places to implement try catch blocks generously in the code hoping to narrow down the problem.


In recent years I have started using Event Viewer to check logs of various warnings, errors registered on a particular machine. I observed that an application or program crash is logged in the Application Event logs and has sufficient information to get hold of the crash or problem location most of the times. The event viewer is generally located at C:\Windows\system32\eventvwr.exe and once launched the Application event logs can easily be viewed.

Image 1

Similar kind of information is shown to the user when a application or program crash takes place on a particular machine. 

How to debug the crashes ? 

To understand the event logger/viewer in a better and useful way, I decided to create a simple program which will crash when some specific command line parameter is passed to it.

Image 2

The HowToFindCrashInExeCode.exe takes a number between 1 and 4 as a parameter and then accordingly crashes by generating appropriate exception. Number 1 and 3 generate Access Violation exception, whereas number 2 and 4 generate StackOverflow exception in the dependent DLL and main EXE respectively. The below two images show the crash report and the application event log when the program crashes on command line by using 1 as the input parameter.

Image 3

Image 4

The important details which the application event log gives us is Faulting application path, Faulting module name and path, Exception code and most importantly Faulting offset. The purpose of faulting application path, faulting module name and path is very obvious. The exception code reveals the detail and/or circumstances under which the crash occurred. The faulting offset is the memory location inside the loaded faulting module i.e. it gives us the exact crash location in the faulting module mentioned in the log. Once you get hold of the application event log from the customer, check the faulting module name, path and faulting offset, then launch the application on your machine and attach it to the debugger. Find the starting memory address of the loaded faulting module and add the faulting offset to this address. Then jump to memory address using the Disassembly. The Disassembly will exactly tell you the crash location. Isn't it a cool and quick way to nail down the crack. Above event manager log tells us that faulting module is HowToFindCrashInDLLCode.dll, exception code is 0xc0000005 which is access violation exception and faulting offset is 0x00001032. The following image depicts the disassembly of HowToFindCrashInDLLCode.dll along with the module load address.

Image 5

The module load address is 0x73D60000, now add the faulting offset which is 0x00001032. The resulting memory address is 0x73D61032. After jumping to this memory location, you can see that crash comes from function crashForAccessViolation and the code which generates this crash is pVal[0] = 10; as pVal is integer pointer which is not instantiated.

Points of Interest

It is important to debug the same version/configuration/platform of the program on developer's machine to get the exact faulting location. Also if you have pdb's generated for your program then you can see the Disassembly as well as the source code once you jump to the faulting offset. No need of building the program with optimizations disabled as the faulting offset is universal for that program and developer needs to do some basic mathematics on his own. Sometimes the crash module is one of the system DLL, e.g., kernel.dll, nt.dll, or msvcr100.dll, then check the faulting offset the same way we did above and also check the exception code. These two things will help you to guess the problem in your code e.g. the STL or CRT libraries throw some exceptions like logical error, which sometimes generate unhandled exceptions and they get caught in the system DLL.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Technical Lead Geometric Ltd
India India
C/C++ practitioner with more than 5 years of experience in 3D Visualization.

Comments and Discussions

SuggestionApp for this: CrashExplorer Pin
Jochen Baier12-Jul-21 19:14
MemberJochen Baier12-Jul-21 19:14 
Suggestion"The specified address cannot be displayed. There is no code at the supplied location." -> Enable native code debugging Pin
Member 138544991-Jun-18 3:22
MemberMember 138544991-Jun-18 3:22 
QuestionKernelBase.dll Pin
jrpharis20-Nov-15 10:02
Memberjrpharis20-Nov-15 10:02 
QuestionManaged code analysis Pin
v-wamoha9-Oct-15 19:28
Memberv-wamoha9-Oct-15 19:28 
QuestionQuestions Pin
I will help you26-Jan-15 23:44
MemberI will help you26-Jan-15 23:44 
GeneralExcellent.. Pin
ashish.0223-Mar-14 22:08
Memberashish.0223-Mar-14 22:08 
QuestionNice. My Vote of 5 Pin
Ron Anders16-Jan-14 14:25
MemberRon Anders16-Jan-14 14:25 
QuestionDebug version of the executables wont work ? Pin
kaushik_code14-Jun-13 5:09
Memberkaushik_code14-Jun-13 5:09 
AnswerRe: Debug version of the executables wont work ? Pin
Nikhil Soman16-Jun-13 21:19
MemberNikhil Soman16-Jun-13 21:19 
GeneralMy vote of 5 Pin
Ștefan-Mihai MOGA13-Jun-13 20:42
professionalȘtefan-Mihai MOGA13-Jun-13 20:42 
GeneralMy vote of 5 Pin
Cosmore11-Jun-13 20:46
MemberCosmore11-Jun-13 20:46 
Questionvery nice Pin
BillW337-Jun-13 10:20
professionalBillW337-Jun-13 10:20 
AnswerRe: very nice Pin
BillW3327-Jan-15 4:51
professionalBillW3327-Jan-15 4:51 
QuestionNice Article Pin
Kannan.Ramjalwar29-May-13 18:39
MemberKannan.Ramjalwar29-May-13 18:39 
GeneralMy vote of 5 Pin
suvarnadhiraj27-May-13 20:41
Membersuvarnadhiraj27-May-13 20:41 
GeneralGreat article to resolve many support issues Pin
Tarkesh Shah27-May-13 20:18
professionalTarkesh Shah27-May-13 20:18 
QuestionNice article. Pin
Paresh Chitte26-May-13 23:16
MemberParesh Chitte26-May-13 23:16 
SuggestionGood article and idea, additional suggestion Pin
AndreMK25-May-13 5:11
MemberAndreMK25-May-13 5:11 
GeneralRe: Good article and idea, additional suggestion Pin
Nikhil Soman26-May-13 6:53
MemberNikhil Soman26-May-13 6:53 
GeneralMy vote of 5 Pin
SajeeshCheviry24-May-13 18:45
MemberSajeeshCheviry24-May-13 18:45 
GeneralRe: My vote of 5 Pin
Nikhil Soman26-May-13 6:51
MemberNikhil Soman26-May-13 6:51 
GeneralMy vote of 5 Pin
Carlos190724-May-13 14:49
professionalCarlos190724-May-13 14:49 
GeneralRe: My vote of 5 Pin
Nikhil Soman24-May-13 17:04
MemberNikhil Soman24-May-13 17:04 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.