🚀 go-pugleaf

"Michel Corbin" <corbin.michel@libertysurf.fr> wrote in message
news:3E6F3321.D563CE7A@libertysurf.fr...
> > BCB can generate .map file for your project with functions names and
their
> > addresses -
> my map file begins with :
>
>  Start         Length     Name                   Class
>  0001:00401000 0000239BEH _TEXT                  CODE
>  0002:00425000 00000AEA4H _DATA                  DATA
>  0003:0042FEA4 000000264H _BSS                   BSS
>  0004:00000000 0000000A4H _TLS                   TLS

Just looking at info you provided, it's clear that exception occurred in one
of the functions in your code section. Exception address = 0x00422033, you
code section (first line) starts at virtual address 0x00401000 and continues
till next section (data ) which has virtual address 0x00425000. Your
exception address falls between them - therefore it's in your code section.

> > section address ('CODE')+ RVA. Function that cause exception will have
> > biggest
> > address <= EIP, obviously. This itself will give you a clue.
> The problem is that all the adresses in the map file are very low in
> comparison
> with the address (00422033) where the exception occurred.

I think you didn't read carefully what I wrote. Function address = CODE
address + RVA. Addresses are not low, they are RVA - relative virtual
address from the beginning of the corresponding section (example):
....
0001:00000EF4  Class::~Class()
0001:00000F44  Class::__vdthk__ (rtti)
....
means Section = 0001; RVA = 00000EF4. Looking up for section starting
address (piece that you copied/pasted ), we see that 0001 is a CODE section
with starting address 00401000. So real function address ( Class::~Class() )
in virtual address space is 00401000 + 00000EF4 = 00401EF4. And so on...

Now, lets say the exception address is 00401F00. First of all, we subtract
section starting address : 00401F00 - 00401000 = 00000F00. This value is RVA
of exception. Looking through part of the .map file that is sorted 'by
value' and related to code section we find that this 00000F00 is between
Class::~Class() and Class::__vdthk__ (rtti). That means that exception
occurred in Class::~Class() function - function with biggest RVA<= RVA of
exception.

> To do that, I have to read and understand a lot of things,
> Must I use SetUnhandledExceptionFilter to achieve that ?

Yes, this function sets UnhadledExceptionFilter(...).

> Is it necessary to change
> the
>  try{    }
>  catch (Exception &exception)
>   {
>     Application->ShowException(&exception);
>   }
> of the main file written by BCB into something like :
> __try{    }
> __except( ){   }

No, you don't need to change you code at all!!!, except to install in the
very beginning of your program your own exception filter. The point is that
ONLY exceptions that are NOT handled by you will make to this filter.

The fact that you see this message box means exception is NOT handled by
your try/catch block. try/catch does not handle Windows SE and the nature of
the message box suggests that unhanded Windows SE occurred, not C++
Exception, because, although, C++ E are built on top of Windows SE, they
pass though terminate() first and terminate() kills program without letting
exception to make to filter. Usually, you see message box "Program
terminated abnormally".

However, you don't really want to handle this exception. You just want to
find what the hell is going on. Of course, you can install you __try/__catch
everywhere where's needed ( I don't know how many threads you are using
etc.) and dump info from there, but the easiest way is to treat this
exception as unhandled. This way, after installation of your filter, this
exception will get into it. You can then use information passed to your
filter function to walk the stack. Take a look at
UnhadledExceptionFilter(..) in Windows help. Regarding the stack walk you
have to understand how stack frames are built. It's quite easy, but is off
topic here. You can read Matt Pietrek's article at MSDN. (1997,  I think,
check archives.)

Best regards,
Holy Punk.