Printable View
I have a debug version and a release version of the same application. The debug version is working fine but release version crashed. How can I find out what causes the crash since I can't debug a release version of application? Thanks for your inputs.
What does the crash message say? Is it an access violation?
Yes, it is possible to build a release version and execute it using the Visual Studio IDE. Turn optimizations off, and execute as you would execute a debug build application.
It could be more problems of the release mode app. First try to find if you have gived starting point for your variable;
This question has been asked many times. Read this for some good info. Search the forums for any other questions you have.
Kelly
It is a general message for an unhandled exception. I tried to disable optimizations but it still crashed. The following is the error report. Can you please pinpoint the problem? Thank you very much!
-------------------- Error Report --------------------------------------------------
<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="MyApp.exe" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="MyApp.exe" SIZE="1089536" CHECKSUM="0x269611DE" BIN_FILE_VERSION="1.0.0.1" BIN_PRODUCT_VERSION="1.0.0.1" PRODUCT_VERSION="1.0.0.1" FILE_DESCRIPTION="My App" COMPANY_NAME=" dullboy Inc." PRODUCT_NAME="My App" FILE_VERSION="1.0.0.1" ORIGINAL_FILENAME="MyApp.exe" INTERNAL_NAME="MyApp.exe" LEGAL_COPYRIGHT="dullboy Inc. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="1.0.0.1" UPTO_BIN_PRODUCT_VERSION="1.0.0.1" LINK_DATE="10/23/2005 18:43:32" UPTO_LINK_DATE="10/23/2005 18:43:32" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
<EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="ntdll.dll" SIZE="708096" CHECKSUM="0x9D20568" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="NT Layer DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xAF2F7" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:56:36" UPTO_LINK_DATE="08/04/2004 07:56:36" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="983552" CHECKSUM="0x4CE79457" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xFF848" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:56:36" UPTO_LINK_DATE="08/04/2004 07:56:36" VER_LANGUAGE="English (United States) [0x409]" />
</EXE>
</DATABASE>
-------------------- End of Error Report ------------------------------------------------
Quote:
Originally Posted by Siddhartha
The thing is that this is a big application. It would be very awkward(sorrt to say that) to find out if there is uninitialized variable or many other things which could possibly cause the crash. Is there any way to pinpoint the problem very quickly? Thank you very much!
Quote:
Originally Posted by g_gili
I think that only you are ho knows what happens in your app. And than try to find when the app is crash(what you are doing in that moment when your app is crashing and so on... to find the problem)
What kind of an error report is this?Quote:
Originally Posted by dullboy
Without knowing the code - nobody can pinpoint a problem!Quote:
Originally Posted by dullboy
Not with that error report for sure. ;)
But, perhaps my conjecture was correct - it could be an access violation that resulted in an exception which went unhandled.
What happens when you execute the application using VS IDE? It should bring you to a point in code where the exception occured. Does it not?
Also, you can use map files to locate the point of a crash -
Can you remember generally what you added or changed right before this happened? I sometimes insert AfxMessageBox("I'm here") or MessageBeep statements in various places that I would suspect the error happens. Keep moveing it in the various parts of the logic sequence. If you no longer get the messagebox or beep this you have found the error location.
I'm sure there are better ways to do this but it usually works fairly quickly for me when I knew generally where the error could be and need to pinpoint the exact location.
Hope this helps.
Yes, you can debug a release build. See this FAQ for more info.Quote:
Originally Posted by dullboy
Thanks for Charris67, I can pinpoint where the crash happened. Actually it is the statement such as: TCHAR* tstr = new TCHAR[20]; Then if I tried to use tstr it will crash right away.
Quote:
Originally Posted by gstercken
Create a release version with debug information, as the FAQ describes. Then just run your app with the debugger until it crashes. The call stack will let you know what calls were made that led to the crash.Quote:
Originally Posted by dullboy
The issue is that you will know what calls led to the crash. It won't necessarily tell you why those calls caused the crash. You said that you call new TCHAR[20] (why, oh why don't more people use CString or std::vector<TCHAR> instead???). This alone does not cause crashes, so all you are seeing is a symptom of a problem and not the cause of the problem. Also, we don't know what you did when you say you "use tstr". How did you "use tstr"?
Regards,
Paul McKenzie
First off, everybody who has told you that you can use the debugger in a release mode application are correct. This exersize is probable the fastest and most reliable way to find both the line and understand the problem.Quote:
TCHAR* tstr = new TCHAR[20]; Then if I tried to use tstr it will crash right away.
Now having said that.... what is probable going on in the above line of code is a memory initialization in debug mode is masking your error. Debug mode initializes alocated memory to NULL and set's int variables likewise to 0. Release mode does not. So often times these debug/release dependent bugs have to do with how you are using the allocated memory...
For instance in the above memory allocation, if you were to do something line this...
This would work in debug mode cause tstr is NULL or '/0' initialized. It would not work in release mode because the unititialized memory at the end of the buffer would not stop strlen from accessing memory off the end of the buffer.Code:strnpy( tstr, "yada", strlen("yada"));
strlen( tstr );
Check how you're copying values into your tstr buffer and make sure that your buffer is getting a NULL terminator... Bet that's your problem..
The good fix for this problem is to make sure your algorithm null terminates your buffer. The fast fix is to just memset the offending buffer to '\0' after you initialize it so it will always work the same way in both debug and release mode...
Good lunk
The strange thing is that when I execute the application in VS , then it worked fine. But when I double clicked the application from explorer, it crashed somewhere. So debugging doesn't help.
Quote:
Originally Posted by JMS
So you executed a debug version of your app from the command line and it still crashed?? Or, that's how you know it crashs you tried to execute it from the command line???Quote:
The strange thing is that when I execute the application in VS , then it worked fine. But when I double clicked the application from explorer, it crashed somewhere. So debugging doesn't help.
1) Does the release version crash too when executed inside the IDE?
2) Does the release version crash when you execute it from the comand line?
3) Debug version works from the IDE
a. in the debugger?
b. when you execute it?
Your problem could be in your configuration.... in you project settings you might have changed the working directory, thus executing from the DEBUG or release directories the program can't find config files (.ini) etc and blows up.
Could be command line optioons in your project settings.. The IDE uses them and the command line version doesn't...
Need to know more..
Still running the release version inside the IDE using techniques others have already refferenced will allow you to isolate the line where problem exists..
If the debugger is not able to help you with locating a crash when executing the release mode version, map files should (see my post above to learn how these are to be used).
Map files are a standard way to locating the reason behind release-mode crashes, and an accurate way too - one I would recommend. If you are sure that the problem is with that TCHAR string usage, review the same and hopefully you'll fix it. BTW, map files can help you in being sure of this as the cause of the crash as well.
Actually I executed a RELEASE version of my app from the command line and it will crash. But it won't crash if I execute a RELEASE version of app from VS IDE.
Quote:
Originally Posted by JMS
Ok, so can you execute a Debug version of your app in the ide? I'm assuming yes..Quote:
Actually I executed a RELEASE version of my app from the command line and it will crash. But it won't crash if I execute a RELEASE version of app from VS IDE.
Then can you execute a Debuf version of your app from the command line?
If you can execute a release version from the IDE and then the same command line version caughs up a furball. Most likely your IDE is defining a different working directory to execute from (settings->general).... Or your IDE is passing in command line options which you aren't when calling from command line....
In the registry, you can specify a particular debugger to get invoked when an application that isn't currently being debugged crashes.
google for the "AEDebug" regkey. You could probably set the VS debugger to attach itself when the app crashes.