Deciphering Run-time Errors without running SDBG?

Is this possible? Typically, we receive 'crash' reports from external users and have to wait a few days before we receive their data files to reproduce their errors using the debugger. However, they usually send us a crash report as part of the initial request for support - an example is produced below.

Run-time Error Error: Negative number raised to non-integer power

00474fb0 MUCFW [+1438] 00431cb0 SA_MUC_BRANCH [+003a] 00418180 ALLASS [+0e82] 004026f0 SATURN_LOOPS [+1902] 00401000 main [+0226]

Is it possible to identify the specific line of code from the HEX value within the MUCFW sub-routine? We would be able to narrow it down based on the runtime error message but I'm looking for guidance on interpreting the more detailed information that is reported. I think there was a suggestion in the FTN95 v8.0 64-bit thread that it was possible. If so, any advice will be gratefully received.

Thanks

Ian

This can be done if you have an assembly listing for the source file concerned. If you do not have one, you can generate one by recompiling using the /explis option, but make sure that the remaining options are the same as those used when the EXE was built.

For example, here is an excerpt from a .LIS file:

   0087            INFO = -2                                                                     AT 4f
      0000004f(28/7/56)          mov       [edi],=-2
      00000055(29/5/54)          jmp       __N7
      0000005a(30/5/54)       Label     __N6
   0088         ELSE IF( LDA.LT.MAX( 1, M ) ) THEN                                               AT 5a
      0000005a(31/8/73)          mov       edx,[eax]
      0000005c(32/8/73)          mov       ebx,=1

You have to locate the assembly line with the offset that you have in the error traceback, and then locate the source line above that line. For example, if the offset is +005a from the base of the subprogram, the source line number is 0088. Note that the offsets are in hexadecimal and the source line numbers are in decimal. Note, in addition, that after access violations, etc., the address printed in the traceback is that of the instruction subsequent to the address at which the violation occurred. In the example, if an access error occurred while executing the instruction at offset +005a, the traceback would actually display +005C, which is the offset of the next instruction.

mecej4,

Many thanks for the prompt reply and very helpful suggestion. We will investigate further.

Ian