An EXE I compiled keeps crashing. I have the following info in the Event Viewer when it crashes:
Exception code: 0xc0000008
Fault offset: 0x00000000000cb8e8
How do I match the "Fault offset" with my C++ code? There is a .PDB file in the Release folder, just not sure what steps to figure this out.
You also need to know what module the offset belongs too, if you are getting 0xC0000008 (STATUS_INVALID_HANDLE), then the exception is likely thrown from ntdll.dll, which isn't going to help you debug your program, since what you care about is deeper in the stack.
What you should be doing is have your customer enable LocalDumps, and then send you a minidump file which you can debug.
Sample registry setup:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpFolder"="d:\\miniDumps"
"DumpType"=dword:00000002
"CustomDumpFlags"=dword:00001124
Related
I've got a crash minidump to analyze. My program is multithread Qt5 application. I'm not a debugging guru but usualy I can easily find place where program failed, but this time I can't. I opened dump file in Visual Studio 2010, clicked "Debug with native only" and it shows me where problem is: it is thread with location "__CxxUnhandledExceptionFilter". Call stack is like this:
msvcr100.dll()!_abort()
msvcr100.dll()!terminate()
program.exe!__CxxUnhandledExceptionFilter(_EXCEPTION_POINTERS * pPtrs)
KERNELBASE.dll!_UnhandledExceptionFilter()
ntdll.dll!__RtlUserThreadStart()
ntdll.dll!__RtlUserThreadStart()
I expected to see stack with program functions and Qt internal functions. But this call stack tells me nothing interesting. So please tell me what is the "ExceptionFilter"-thread and how can I find place where program failed actually?
You are viewing the application at the point where the unhandled exception has already been caught by the default exception filter.
That is, you are not seeing the line where the exception occurred.
Unfortunately, this means the minidump likely contains no useful information.
You might try inspecting the _EXCEPTION_POINTERS structs, it might contain the EIP of the instruction that triggered the unhandled exception.
See the value of pPtrs->ExceptionRecord->ExceptionAddress, that should hold the EIP.
From MSDN:
ExceptionAddress: The address where the exception occurred.
To get the stack trace at the point where the exception occured, read http://support.microsoft.com/kb/313109.
I am building up a program and it works fine past few days. When I run it today it shows this Unhandled exception at 0x7770efc8 in LHM.exe: 0xC0000005: Access violation writing location 0x00440f48.
ntdl.dll!7770fb12()
In the call stack below, it indicates that frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll.
And I found the ntdl.dll!7770fb12() is 7770FB12 push esi in the Disassembly.
Is there anyway I can solve this problem?
Even if the call stack doesn't show any specific location with a call in your code eventually leading to ntdll.dll, in most cases you can pinpoint the call by stepping through your code from the beginning. If your code is too big, try to set breakpoints randomly and narrow it down continuously.
This is some very basic and maybe crude debugging procedure but it helps me alot...
'Frames below may be incorrect' is definitely not a sign of corrupted stack. It is easily solvable if you load the public symbols for ntdll from MS servers (done easily from the IDE - say, right click ntdll at the 'modules' window).
A deeper dive is available here.
My app was running fine until I tried to debug it with the Application Verifier. After that I started getting "First-chance exception... : An invalid handle was specified" and the issue seems to be in the "bailout.c" file in Pantheios:
hFile = CreateFileA("logging-bailout.txt"
, GENERIC_WRITE
, 0
, NULL
, OPEN_ALWAYS
, 0
, NULL); <--- this is where it crashes, line 442
And message:
First-chance exception at 0x7769f8cd in myapp.exe: 0xC0000008: An invalid handle was specified.
=======================================
VERIFIER STOP 0000000000000300: pid 0x3814: Invalid handle exception for current stack trace.
00000000C0000008 : Exception code.
00000000111DE950 : Exception record. Use .exr to display it.
00000000111DE460 : Context record. Use .cxr to display it.
0000000000000000 : Not used.
=======================================
This verifier stop is continuable.
After debugging it use `go' to continue.
=======================================
Before the console just logged the exceptions that I got with Pantheios and I didnt really care too much about. However, now when the app crashes on the first occurrence of logging using Pantheios it's time for me to deal with this, but I'm not too sure sure how to.
I was following this guide when setting up my Pantheios: http://www.codeproject.com/Articles/27119/Using-Callback-Back-ends-with-the-Pantheios-Loggin
In every file I have logging I have the following lines in the source file:
#include <pantheios/pantheios.hpp>
#include <pantheios/inserters/boolean.hpp>
#include <pantheios/inserters/integer.hpp>
#include <Shared/logs.h>
logs.h contains:
#include <pantheios/implicit_link/core.h>
#include <pantheios/implicit_link/fe.simple.h>
#include <pantheios/implicit_link/be.WindowsConsole.h>
I also call pantheios::init(); before doing any logging.
I'm using Visual studio 2010 and are including the following lib-files under "Additional Dependencies":
$(PANTHEIOS_ROOT)\lib\pantheios.1.core.vc10.mt.debug.lib
$(PANTHEIOS_ROOT)\lib\pantheios.1.be.WindowsConsole.vc10.mt.debug.lib
$(PANTHEIOS_ROOT)\lib\pantheios.1.fe.simple.vc10.mt.debug.lib
$(PANTHEIOS_ROOT)\lib\pantheios.1.util.vc10.mt.debug.lib
However, all my logging looks like this:
First-chance exception at 0x750bb9bc in myapp.exe: Microsoft C++ exception: stlsoft::winstl_project::windows_exception at memory location 0x1822bda0..
20120423-104817.497: failed to write message to log file; given message follows: [myapp.Qt.Framework.13424, 23/04/2012 10:48:17.496 a.m.; Debug]: "some logging"
when calling pantheios::log(pantheios::debug, "some logging");
Then, all my logging is written to a "bailout"file in the same folder as the project. This worked before but it was a big bullet on my "To-do-list" (but a bit further down than other things).
So now my question is, how do I fix this? Followed every tutorial I can find but with no success. And why did my app decide to not accept this anymore after running the Ms Application Verifier? Makes no sense.
First chance exceptions mean only that an exception was thrown. It does not mean you have a bug in your program, just that the debugger is showing you that an exception is being thrown, so you have a chance to examine it before it is propagated up the call chain. If the exception is caught by an exception handler (e.g. for logging), your application continues, otherwise the debugger gives you a second-chance exception notification to inform you that the application will exit due to an unhandled exception.
If you do not want to receive the first-chance exception notifications, you can turn it off in your debugger. This link may help on how to turn off exception handling in Application Verifier.
To work around this problem, turn off exceptions testing in Application Verifier. To do this, follow these steps:
1.Start Application Verifier.
2.Under Applications, click the GDI+ program that you want to test.
3.Under Tests, expand Basics.
4.Click to clear the Exceptions check box.
5.Run the GDI+ program that you want to test.
You can also configure the debugging tool to make sure that you do not experience a breakpoint in the debugging tool when an access violation occurs.
The alternative (turning off exception notification in MSVS) is via "Debug->Exceptions..."
Alternatively, if it is possible, make sure the exception does not get thrown in the first place. You will need to examine the nature of the exception (e.g. file not found) and fix the condition that is preventing the intended operation.
Given the nature/purpose of Application Verifier, I would suggest the latter approach: AV is telling you that something incorrect is going on that might have been ok previously, but can cause problems later on (depending on enviornment, circumstances, etc.)
My application crashes with an error saying "Demo Application pk/si component has stopped working". The systems Event Viewer log shows an error with the following details.
"Faulting application Demo.exe, version 1.0.0.1, faulting module OLEACC.dll,version 4.2.5406.0, time stamp 0x4549bd93,exception code 0xc0000005,fault offset 0x00004062,process id 0x154c,application start time 0x01c9ee94aab4c550"
I am using Windows Vista Home Premium edition and the application which i created was a Vc++ SDI application.
Please let me know if anyone have come across this issue and what could be the possible solution for the same.
Thanks in Advance,
It looks like good old access violation to me. It looks like you writing/reading from an invalid memory location in your application.
It's most likely a bug somewhere in your code that is passing invalid values to some Windows functions, and somewhere further down the line this results in a crash. Just because it isn't your DLL where the crash occurs doesn't mean it isn't your fault!
Although this isn't very helpful, all you can do is hook up a debugger to your program and reproduce the crash, then debug it.
Sometimes my c++ program crashes in debug mode, and what I got is a message box saying that an assertion failed in some of the internal memory management routines (accessing unallocated memory etc.). But I don't know where that was called from, because I didn't get any stack trace. How do I get a stack trace or at least see where it fails in my code (instead of library/ built-in routines)?
If you have a crash, you can get information about where the crash happened whether you have a debug or a release build. And you can see the call stack even if you are on a computer that does not have the source code.
To do this you need to use the PDB file that was built with your EXE. Put the PDB file inside the same directory as the EXE that crashed. Note: Even if you have the same source code, building twice and using the first EXE and the second PDB won't work. You need to use the exact PDB that was built with your EXE.
Then attach a debugger to the process that crashed. Example: windbg or VS.
Then simply checkout your call stack, while also having your threads window open. You will have to select the thread that crashed and check on the callstack for that thread. Each thread has a different call stack.
If you already have your VS debugger attached, it will automatically go to the source code that is causing the crash for you.
If the crash is happening inside a library you are using that you don't have the PDB for. There is nothing you can do.
If you run the debug version on a machine with VS, it should offer to bring it up and let you see the stack trace.
The problem is that the real problem is not on the call stack any more. If you free a pointer twice, that can result in this problem somewhere else unrelated to the program (the next time anything accesses the heap datastructures)
I wrote this blog on some tips for getting the problem to show up in the call stack so you can figure out what is going on.
http://www.atalasoft.com/cs/blogs/loufranco/archive/2007/02/06/6-_2200_Pointers_2200_-on-Debugging-Unmanaged-Code.aspx
The best tip is to use the gflags utility to make pointer issues cause immediate problems.
You can trigger a mini-dump by setting a handler for uncaught exceptions. Here's an article that explains all about minidumps
Google actually implemented their own open source crash handler called BreakPad, which also mozilla use I think (that's if you want something more serious - a rich and robust crash handler).
If I remember correctly that message box should have a button which says 'retry'. This should then break the program (in the debugger) at the point where the assertion happened.
CrashFinder can help you locate the place of the exception given the DLL and the address of the exception reported.
You can take this code and integrate it into your application to have a stack trage automatically generated when there is an uncaught exception. This is generally performed using __try{} __except{} or with a call to SetUnhandledExceptionFilter which allows you to specify a callback to all unhandled exceptions.
You can also have a post-mortem debugger installed on the client system. This is a decent, general way to get information when you do not have dump creation built into your application (maybe for an older version for which you must still get information).
Dr. Watson on Windows can be installed by running: drwtsn32 -i Running drwtsn32 (without any options) will bring up the configuration dialog. This will allow the creation of crash dump files, which you can later analyze with WinDbg or something similar.
You can use Poppy for this. You just sprinkle some macros across your code and it will gather the stack trace, together with the actual parameter values, local variables, loop counters, etc. It is very lightweight so it can be left in the release build to gather this information from crashes on end-user machines