Release version of application crashed!!!

[dullboy]

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.

[Siddhartha]

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.

[g_gili]

It could be more problems of the release mode app. First try to find if you have gived starting point for your variable;

[Runt888]

This question has been asked many times. Read this for some good info. Search the forums for any other questions you have.

Kelly

[dullboy]

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 ------------------------------------------------

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.

[dullboy]

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!

It could be more problems of the release mode app. First try to find if you have gived starting point for your variable;

[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)

[Siddhartha]

The following is the error report.

What kind of an error report is this?

Can you please pinpoint the problem?

Without knowing the code - nobody can pinpoint a problem!
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 -

• Using map files to locate Release Mode Crashes

[charris67]

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.

[gstercken]

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?

Yes, you can debug a release build. See this FAQ for more info.

[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.

Yes, you can debug a release build. See this FAQ for more info.

[Paul McKenzie]

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.

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.

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

[JMS]

TCHAR* tstr = new TCHAR[20]; Then if I tried to use tstr it will crash right away.

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.

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...

strnpy( tstr, "yada", strlen("yada"));
strlen( tstr );

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.

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

[dullboy]

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.

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.

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...

strnpy( tstr, "yada", strlen("yada"));
strlen( tstr );

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.

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

[JMS]

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.

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???

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..