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.
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
}
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.
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.
Following on the tails of my previous (answered) question...
SharpSvn makes calling the Subversion client API simple:
SvnClient client = new SvnClient();
client.Authentication.DefaultCredentials = new NetworkCredential(username, password);
client.CheckOut(new Uri("http://xxx.yyy.zzz.aaa/svn/repository"), workingCopyDir);
On the other hand, calling the client API from C/C++, as shown in minimal_client.c requires coding "closer to the metal", as it were, on Subversion.
Are there Windows libraries for C++ in Visual Studio 2003 that present a simpler interface than what minimal_client uses?
If there are not, is there a VS2003 C++ project (a .vcproj file) that demonstrates getting minimal_client to run? I'm able to compile minimal_client.c and link it using the following libraries:
libsvn_client-1.lib libsvn_delta-1.lib libsvn_diff-1.lib libsvn_fs-1.lib libsvn_fs_base-1.lib libsvn_fs_fs-1.lib libsvn_ra-1.lib libsvn_ra_local-1.lib libsvn_ra_svn-1.lib libsvn_repos-1.lib libsvn_subr-1.lib libsvn_wc-1.lib libapr-1.lib libaprutil-1.lib xml.lib libneon.lib
but when I run my application (in the debugger or start the release build without debugging), it runs for about 20 seconds without hitting the first line of main() and then throws this exception:
An unhandled exception of type
'System.TypeLoadException' occurred in
Unknown Module.
Additional information: Could not load
type apr_pool_t from assembly
minimal_client,
Version=1.0.3477.16033,
Culture=neutral, PublicKeyToken=null.
I've tried various combination of libsvn_.lib and svn_.lib to no avail.
Any thoughts on what I'm doing wrong?
EDIT: I started fresh with a "Win32 Console Project" (still in VS2003) and I am now able to debug the first few lines of my app. But now, on this line:
if (svn_cmdline_init ("minimal_client", stderr) != EXIT_SUCCESS)
I get a different exception (in the debugger or start the release build without debugging):
Unhandled exception at 0x7c91b21a in
Win32ConsoleProject_minimal_client.exe:
0xC0000005: Access violation writing
location 0x00000010.
EDIT: This thread explains that this error is a CRT mismatch between svn and stderr in my app. If I don't want to build Svn so they match (I don't want to), I can pass NULL instead of stderr (provided I'm willing to do without messages that would go to stderr) When I did this, my app ran all the way through correctly.
It seems that C++ wrappers are not overflowing the 'net. However, you may want to try SVNCPP, which can be yoinked from RapidSVN.
See http://rapidsvn.tigris.org/ for details (note: I've not tried it).
Can you upgrade to Visual C++ 2005 ? If so, you could just go using SharpSvn with C++/CLI.
Or even maybe stick to VC2003 and go SharpSvn with Managed C++ ? (not that I have any knowledge on the how od even the if)
edit: oh well, SharpSvn's homepage explicitely states that VC++ 2005 SP1 is required...