Help! How to debug if only release version crashes...

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi, gurus,

I am new with visual studio... I am trying to build a standalone C++ project
by MS visual C++, the problem that I have is: if compile it as "Release"
version, it crashes by a certain combination of the operations, while if
compile it as "debug" version, there is no problem. I also tried to "debug"
the release version in the IDE, after seeing warning and choosing "debug
anyway", there is no crash...I guess the problem has something to do with the
file I/O, but I don't know the debugging method in this situation.

Any suggestion on how to debug this problem??? Thanks a lot!
 
Song said:
Hi, gurus,

I am new with visual studio... I am trying to build a standalone C++
project
by MS visual C++, the problem that I have is: if compile it as "Release"
version
Click to expand...

This has definetely nothing to do with .NET. In most cases where this
happens, it is because you are writting beyond allocated memory, or are
freeing it two times. That's a common error when handling BSTR in COM
programming. Simply download a trial of BoundsChecker
(http://www.compuware.com/products/devpartner/bounds.htm) and run Visual
Studio on the debug release. In most cases, this will show you a bunch of
errors, and maybe one of them is crashing your release built app.

Regards
 
Song said:
Hi, gurus,

I am new with visual studio... I am trying to build a standalone C++ project
by MS visual C++, the problem that I have is: if compile it as "Release"
version, it crashes by a certain combination of the operations, while if
compile it as "debug" version, there is no problem. I also tried to "debug"
the release version in the IDE, after seeing warning and choosing "debug
anyway", there is no crash...I guess the problem has something to do with the
file I/O, but I don't know the debugging method in this situation.

Any suggestion on how to debug this problem??? Thanks a lot!
Click to expand...

Well, you can always Use "Programmer's Best Friend", the MessageBox at
strategic places in your code. The last message you get prior to the crash
will be closest to the offending code. It's a good idea to use use "1" as
the header for the first message, "2" for the second and so on. The actual
message should show somethingthat can help you to identify the problem. If,
for instance, you think the problem may be related to a BSTR, then you
should show it as the message.If you want to debug a file handle, you may
want to use something like (fileHandle!=NULL)?"fileHandle!=NULL" :
"fileHandle==NULL"

/ Fredrik
 
Back
Top