Program works when running from debugger but not as an .EXE - Programmer

This is a discussion on Program works when running from debugger but not as an .EXE - Programmer ; Hi have a MFC program that reads voltage measurements from a mulitmeter via GPIB using VISA API. The program works find when running from the debugger but crash with the following error when running from the actual generated executable (and ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Program works when running from debugger but not as an .EXE

  1. Program works when running from debugger but not as an .EXE

    Hi have a MFC program that reads voltage measurements from a mulitmeter
    via GPIB using VISA API. The program works find when running from the
    debugger but crash with the following error when running from the
    actual generated executable (and I even Debug executable not the
    Release executable). I using Visual C++ 6.0 running on Windows XP. I
    got the following error signature:

    AppName: arc.exe (this is my program) AppVer: 1.0.0.1 ModName:
    ntdll.dll
    ModVer: 5.1.2600.1217 Offset: 000085c0

    any ideas? Please any advice would be greatly appreciated. Thanks.


  2. Re: Program works when running from debugger but not as an .EXE

    In message <1130213818.061714.281820@o13g2000cwo.googlegroups. com>,
    ratcharit@gmail.com writes
    >Hi have a MFC program that reads voltage measurements from a mulitmeter
    >via GPIB using VISA API. The program works find when running from the
    >debugger but crash with the following error when running from the
    >actual generated executable (and I even Debug executable not the
    >Release executable). I using Visual C++ 6.0 running on Windows XP. I
    >got the following error signature:
    >
    >AppName: arc.exe (this is my program) AppVer: 1.0.0.1 ModName:
    >ntdll.dll
    >ModVer: 5.1.2600.1217 Offset: 000085c0


    Generally things like this indicate either a modified path or a data
    corruption of some sort or uninitialised data problems.

    The modified path could be that the presence of the debugger is causing:
    o DLLs to load from a different path (I have never heard of this but
    different environment variable settings and different startup directory
    can have this effect and these do come into play when using a debugger).

    Or

    o Some DLLs to fail to load (this can happen - sometimes this causes the
    app to fail (crash) or to gracefully disable various functionality
    provided by the DLL (this may be the functionality causing your crash).

    Or

    o Some DLLs to load at different addresses than if the debugger was not
    present. This can happen if multiple DLLs want to load at the same
    address (the first one wins, the other either loads somewhere else or
    fails to load). Typically in this scenario various datastructures and
    functions are located at a different address than when running without
    the debugger. In the case of data corruption or computed function jumps
    the presence of the debugger can cause the data corruption to happen in
    a benign location that causes no immediate crash (or even no crash at
    all).

    Finally you need to contend with uninitialised data. Uninitialised
    variables in debug builds are always non-zero (various values depending
    on if on the stack, in dynamic memory etc). Static variables I cannot
    remember (they may be zero, can't remember at this time of night).
    However for release builds uninitialised data may be zero, may not be
    zero. Depending on your application the value may be repeatable each
    time or may be random each time. The presence of the debugger can often
    influence this behaviour simply because different addresses are used and
    the stack locations may be slightly different.

    Such problems are hard to deal with. Try to identify if the same DLLs
    are loaded for the EXE that crashes and the EXE when run in the
    debugger. If they are not the same, fix that. If they are the same then
    you probably need to use a software tool to rule out the possibility of
    memory corruption and/or uninitialised data.

    A useful software tool for this work is Memory Validator by Software
    Verification. There is a 30 day eval.

    http://www.softwareverify.com

    You may also find the flow tracing product that is in beta (Crash
    Validator) may provide some insight into your application's behaviour.

    Stephen
    --
    Stephen Kellett
    Object Media Limited http://www.objmedia.demon.co.uk/software.html
    Computer Consultancy, Software Development
    Windows C++, Java, Assembler, Performance Analysis, Troubleshooting

+ Reply to Thread