Getting crash information

  • Thread starter Thread starter Abubakar
  • Start date Start date
A

Abubakar

Hi,

I want to know that when my application is running outside of the debugger
(in debug or release build) can I set the application/project settings in a
way that when it crashes it tells me which method of which class it was
running while it crashed. And can it also give me the stack trace of when
the crash happened? I'm asking this cuz I'm running the app in a machine in
which I cant install the visual studio, but I do have the freedom of placing
as many files (debug dlls objs etc) as I want to.

Regards,

...ab
 
Abubakar said:
I want to know that when my application is running outside of the debugger
(in debug or release build) can I set the application/project settings in
a way that when it crashes it tells me which method of which class it was
running while it crashed. And can it also give me the stack trace of when
the crash happened?
Click to expand...

If you don'y want to modify your application, one thing that you can do is
to make sure the Dr. Watson is set as the JIT debugger. It will create a
crash dump if you set that option. Run

drwtsn32.exe

for details.
I'm asking this cuz I'm running the app in a machine in which I cant
install the visual studio, but I do have the freedom of placing as many
files (debug dlls objs etc) as I want to.
Click to expand...

Another option is to instrument your application to create a minidump:

http://msdn2.microsoft.com/en-us/library/ms680369.aspx

Regards,
Will
www.ivrforbeginners.com
 
Hi,
If you don'y want to modify your application, one thing that you can do is
Click to expand...

Well I can change my application, modify the source, if it can help me catch
the bugs that crashes my application. In this case do u mean I'll have to
use the MiniDump* apis that u gave the link of?

regards,

...ab
 
Abubakar said:
Well I can change my application, modify the source, if it can help me
catch
the bugs that crashes my application. In this case do u mean I'll have to
use the MiniDump* apis that u gave the link of?
Click to expand...

As I said, you can use Dr Watson to catch the fault and create the crash
dump or in you do it in code. A sample of the latter approach is here:

http://www.codeproject.com/tools/minidump.asp

Just by the way, I know nothing of that sample except that it was the first
hit at Code Project.

Regards,
Will
www.ivrforbeginners.com
 
Here is what I did: I have installed the windbg on the machine where i'm
running my code and set it as the default jit debugger. Now my binaries are
all in release mode but i've placed the release pdb files along them. I've
also placed the source code in some directories. Now when my app crashes,
windbg takes over and now I specify the source directory of source paths and
double click the stack trace lines and there I'm in the debugger showing me
my beautiful code :) but still I'v no idea of what went wrong. I've a
question: What is a "(8524.8ef4): Access violation - code c0000005 (!!!
second chance !!!)" ? Maybe the stack got corrupted?

...ab
 
Abubakar said:
What is a "(8524.8ef4): Access violation - code c0000005 (!!! second
chance !!!)" ? Maybe the stack got corrupted?
Click to expand...

It is an attempt to access memory that isn't there. A pointer could be zero,
it could point to non-existent memory, it could point to read-only memory on
a write etc. The memory could be on the stack or on the heap or anywhere
else.

It's often difficult to determine where and why things went bad, but if
you've trapped the fault at the debuuger you should be able to determine
what is bad.

Regards,
Will
www.ivrforbeginners.com
 
Do optimizations effect debugging in release mode. Should I turn off all
optimizations, will that help me in debugging release binaries?

...ab
 
Abubakar said:
Do optimizations effect debugging in release mode.
Click to expand...

Yes. The code you execute is not exactly the code as it was written.
Should I turn off all optimizations, will that help me in debugging
release binaries?
Click to expand...

Well, it can help.

But the first step is to determine what is the cause of the error. It could
be an optimizer bug. Or it could be a timing issue or it could be that the
bug corrupts different locations in debug and release mode.

Optimizer bugs aren't unknown but, IME, they don't occur as often as
application bugs. Rather than turning off optimizations you could try
optimizing for size instead of speed (or vice versa).

If you have a .pdb file for your release build - even optimized - then you
should be able to get close to the source of the error. You can use a pragma
to selectively turn off the optimizer in the module that contains the error.
And you can shrink the size of the unoptimized section of that module
iteratively until you find out where it breaks.

If you have an application problem you might want to look at tools like
PageHeap

http://support.microsoft.com/kb/286470

to diagnose memory problems. And you can always do what we did before we had
good debuggers - use printf() or WriteConsole() or the standard output
stream in C++ - to trace your application's execution.

Regards,
Will
www.ivrforbeginners.com
 
Hey I caught the bug! It was a threading problem, relating to an internal
(little) database that we access, I was not managing the locking of the
database efficiently. It was a rare bug though, I can only reproduce it on a
dual core machine :) wow.... this reminds me of the post that I have in
mind: about single core n dual core programming concerns .... I'll post it
sometime ..

thanks,

...ab
 
Back
Top