I have a C++ windows application that was done by another programmer, that I had to remove one line of code. After rebuilding the application with visual studio 2013 it crashes with this in the event log:
Faulting application name: WaveStream.exe, version: 0.0.0.0, time stamp: 0x536122da
Faulting module name: WaveStream.exe, version: 0.0.0.0, time stamp: 0x536122da
Exception code: 0xc0000409
Fault offset: 0x0000bd7f
Faulting process id: 0x8b8
Faulting application start time: 0x01cf6490aee4f557
Faulting application path: C:\Program Files (x86)\PS Audio\WaveStream.exe
Faulting module path: C:\Program Files (x86)\PS Audio\WaveStream.exe
Report Id: efe00d42-d083-11e3-a513-bc305baf9e1e
The application uses QT 4.7.4, and compiles with no errors. I am an embedded systems programmer and have very little windows programing experience. What can I do to figure out why it is crashing?
Dennis
The clue to the problem is in the exception code: 0xc0000409
0xc0000409 means STATUS_STACK_BUFFER_OVERRUN.
In other words, something in your program is writing past the current stack frame, corrupting data on the stack. The program has detected this and rather than let it continue, has thrown an exception.
How do you debug this? There are a few options:
1) Rerun this in the debugger and watch it crash, workout what failed.
2) If you've got a crash dump of this, load that in the debugger, hit F5 and workout what failed.
3) If you don't have a crash dump you can still attempt to find out the cause of the crash if you know the absolute address of the crash (and know the module always loads at a fixed address), or if you know the offset of the crash location from the start of the faulting module.
The crash information above tells you the offset into the faulting module of the crash. That's reported in the Fault Offset field. In your example, that is an offset of 0x0000bd7f.
If you've got the original dll/exe and it's matching PDB, just load it into DbgHelpBrowser, go to the Query menu, choose "Find Symbol with DLL Relative Address..." then enter the offset in the field and click "Find Symbol...". The display will move to show you the nearest matching symbol, highlighting the symbol and display any info about parameters, line numbers and source code.
It's a free tool. You can get it here:
https://www.softwareverify.com/cpp-dbghelp-browser.php
Disclaimer. I wrote this tool to do just this job for our in house use. We recently made it available for everyone else. I found this question while trying to understand what the exception code 0xc0000409 meant.
Try to create a crash dump for the application. See this StackOverflow question and the MSDN documentation on how to do that. Once you have the crash dump file, open it in the Visual Studio debugger and you will be able to see the exception and call stack for the exception, which should help.
!analyize -v in windbg
It will do a lot of work for you.
Related
A brief story about my problem:
My application [which is compiled in VC++ 2010] is supposed to have fewer viewing/working rights to Standard user, while of-course in Administrative user it will have full permission.
Few days back when I tried to run the application [installed version that is release binaries] in Standard user I saw a crash in MFC140ud.dll [weird]. It should not be ud version. Anyways, in my programs & features [I am a Win7 user] I saw Runtime & redistributable of VS2015.I uninstalled them.
I restarted my computer with not much luck- and I was still getting crash but in different dlls.
It shows two dialog boxes showing errors. One is showing error in MSVCR100d.dll and second is showing in ntdll.dll
Here is the problem signature from the two boxes:
Problem signature:
Problem Event Name: APPCRASH
Application Name: MyAppName.exe
Application Version: 4.5.64.0
Application Timestamp: 594a41e2
Fault Module Name: MSVCR100D.dll
Fault Module Version: 10.0.40219.325
Fault Module Timestamp: 4df2be37
Exception Code: 80000003
Exception Offset: 0011b545
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789
--
Problem signature:
Problem Event Name: APPCRASH
Application Name: MyAppName.exe
Application Version: 4.5.64.0
Application Timestamp: 594a41e2
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.23796
Fault Module Timestamp: 59028e17
Exception Code: c015000f
Exception Offset: 00083af6
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 55c7
Additional Information 2: 55c739abdb4e531959bbe02ef6e9e097
Additional Information 3: e422
Additional Information 4: e422b1470321edbfed7e5b3f5a1b3d28
--
I reinstalled VS2010 redistributable but no luck.
I see same error even if I try it running as admin [right click and select Run as admin].
If I run it from Administrator account it works fine.
Also, I want to add- if it helps anybody to help me correct- usually I keep windows updates, but, few days back it installed a long list of updates.
So I think it is Win7 updates causing problem but not sure.
Any help is appreciated.
I have an application that uses Qt, it works on some machines (Windows 7 64bits, Windows Server Standard 32bits), and on other machines (Windows Server 2012 R2 64bits, Windows 10 Pro 64bits) it gives an SEH exception. I've been trying to debug this for some time but I don't know how to find the root.
This exception is not caught by the try/catch, and I wasn't able to use __try/__except because it cannot be used together with the first, and also it says it can only be used in code that does not require unwinding (if I remember correctly).
Problem signature:
Problem Event Name: APPCRASH
Application Name: gpeh_parser.exe
Application Version: 0.0.0.0
Application Timestamp: 584051a0
Fault Module Name: Qt5Core.dll
Fault Module Version: 5.1.1.0
Fault Module Timestamp: 521a52ae
Exception Code: c0000005
Exception Offset: 00023087
OS Version: 6.3.9600.2.0.0.272.7
Locale ID: 11274
Additional Information 1: 5861
Additional Information 2: 5861822e1919d7c014bbb064c64908b2
Additional Information 3: 01d7
Additional Information 4: 01d7340064827245f2249cd1f1a7c264
I also tried to use windbg, but wasn't able to find the root of the problem (altough that might be due to my very little experience with it).
What else can I do to find what's happening?
I've found that enabling /EHa (Structured Exception Handling) on the compiler solves my problem, as I can then use my default exception handling code (try/catch).
Appending this to my .pro did it:
win* {
QMAKE_CXXFLAGS_EXCEPTIONS_ON = /EHa
QMAKE_CXXFLAGS_STL_ON = /EHa
}
This is a very open ended question and I am really just looking for how to approach locating the issue.
The application runs for a day or so and then will crash while being used. The point in the application that it crashes is not the same each time. The memory that the application is using is not increasing.
C++ is not my standard dev language so any pointers would be appreciated.
The run time error I am given is detailed below. Having googled this I can see that 40000015 is a generic I don't know what has happened style error. Is there anyway I can use the additional information (1-4) to assist in locating the issue?
Any help is much appreciated!
Thanks
Problem signature:
Problem Event Name: APPCRASH
Application Name: Main.exe
Application Version: 1.1.10.0
Application Timestamp: 5278d640
Fault Module Name: MSVCR90.dll
Fault Module Version: 9.0.30729.4940
Fault Module Timestamp: 4ca2ef57
Exception Code: 40000015
Exception Offset: 0005beae
OS Version: 6.1.7601.2.1.0.256.48
Locale ID: 2057
Additional Information 1: 3793
Additional Information 2: 379382cf89267e4a4b730ab2a7cc6828
Additional Information 3: f05b
Additional Information 4: f05b042c097ccdb870355bd0f539be8d
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
I would start by running it under debugger and leave it running for a day. Remember to enable all exceptions to catch - in my VS 2005 its in Debug->Exceptions, add handler for 40000015 exception.
If you cannot run it under debugger, ie. it happens only on client PC (still you can use remote debugging), then you can implement exception hanlder using : AddVectoredExceptionHandler, then use StackWalk64 to log call stack. If you can compile with symbols, then such stack will contain full path to the source of exception. It will be inside MSVCR90.dll, but will originate probably somewhere in your code. If you cannot include symbols then you can always use .map files or windbg with locally stored .pdb files. Of course this is a lot of work especially if C++ is not your main language, so the first suggestion is the best for you.
Ok, you can also use MiniDumpWriteDump and then use windbg instead of StackWalk64.
After the program I am debugging crashes, I am left with heap dump *.mdmp file & appcompat.txt in my Temp directory. I understand that appcompat.txt is an error report. Is there a description of its format?
My appcompat.txt lists a number of DLLs. Am I correct assuming that the reason for a crash could have only come from one of the listed DLLs? Can I limit my debugging effort to the DLLs listed in appcompat.txt?
Thanks in advance!
The minidump file is far more informative for diagnosing crashes:
Install Debugging Tools for Windows, if you don't already have it.
Set up the symbol path variable _NT_SYMBOL_PATH to point to the Microsoft symbol server
Run Windbg and do File -> Open Crash Dump and locate your .dmp or .mdmp file
Type !analyze -v.
This will try to isolate the location of the crash. Note that just because a crash occurs in a particular dll it doesn't mean that is where the bug resides - it could be because an invalid parameter has been passed in from your application code. The analysis should hopefully show you a meaningful stack and an error code which should help in working out the actual cause of the crash.
I have a .Net 4.0 C++ application that used to be built in 32bits. Obviously when running on a 64bits station I was having issues, therefore I started rebuilding everything in 64 bits. The whole project is converted as well as the libraries I had made for this in other project files. All references have been updated and everything compiles fine.
Once deployed to a 64bit station I now get the following errors in the windows event viewer:
Information : Windows Error Reporting
Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: EDI.exe
P2: 0.0.0.0
P3: 4e32e547
P4: KERNELBASE.dll
P5: 6.1.7601.17625
P6: 4de88429
P7: e0434352
P8: 000000000000cacd
P9:
P10:
Attached files:
These files may be available here:
C:\Users\developer\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppCrash_EDI.exe_b14cfebcf86ccaf91a35dacab06a28cdf7277ba_17f14701
Analysis symbol:
Rechecking for solution: 0
Report Id: c9983227-ba04-11e0-9299-002713d66c71
Report Status: 0
Error : Application Error
Faulting application name: EDI.exe, version: 0.0.0.0, time stamp: 0x4e32e547
Faulting module name: KERNELBASE.dll, version: 6.1.7601.17625, time stamp: 0x4de88429
Exception code: 0xe0434352
Fault offset: 0x000000000000cacd
Faulting process id: 0x1704
Faulting application start time: 0x01cc4e118bde9f1d
Faulting application path: C:\Users\developer\Desktop\EDI_6.1.0.4160_x64\EDI_6.1.0.4160_x64\EDI.exe
Faulting module path: C:\Windows\system32\KERNELBASE.dll
Report Id: c9983227-ba04-11e0-9299-002713d66c71
Error : .Net Runtime
Application: EDI.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
Stack:
at <Module>.main(System.String[])
When I run dependency walker on the executable, I get to see the executable listed in the modules and nothing else at all comes up. I am kind of out of ideas at the moment and wondering if anyone can make something of this?
Exception code: 0xe0434352
Not very common. Check this:
http://social.msdn.microsoft.com/Forums/en-GB/pex/thread/b9728c2d-130e-48f9-80c1-442ddbc1e85b
I just experienced this same error-code, also in Kernelbase.dll when attempting to debug a C++ application in VS2012. Fortunately in my case I tracked the issue down to the Document Well (from Productivity Powertools Extension) option:
Environment-Tabs and Windows-Maintain pin status if document is removed from well.
Clearing this option fixed my problem. It appears that DevStudio was crashing when rearranging the tabs/windows for debugging.
This may not be the cause of your particular issue, but I've added it here because if anyone else searches for error code: 0xe0434352 in Kernelbase.dll, this issue is at the top of the Google search.