none
Application randomly getting crashed RRS feed

  • Question

  • My application is getting crashed .The issue is random.I have checked for all possibilities like null pointer,threads etc.

    I am getting event log as below..

    Faulting application name: Demo.exe, version: 1.0.0.1, time stamp: 0x5cf618be
    Faulting module name: Demo.exe, version: 1.0.0.1, time stamp: 0x5cf618be
    Exception code: 0xc0000005
    Fault offset: 0x00070a86
    Faulting process id: 0x2768
    Faulting application start time: 0x01d520111b724728
    Faulting application path: D:\Demo.exe
    Faulting module path: D:\Demo.exe
    Report Id: a7f82aa3-5c8a-4e89-9249-abc198e32edd
    Faulting package full name: 
    Faulting package-relative application ID: 

    Tuesday, June 11, 2019 5:43 AM

All replies

  • Hello,

    it's a memory access violation. You should run the debugger and check, in which line exactly the error occurs and what is the contents of the variable (you say it's not a NULL pointer, so what is it? Maybe you have an array and try to access a value outside the Array Memory).

    If you give us more information about the source code line where the error occurs, then we can try to give you more help.

    Regards, Guido

    Tuesday, June 11, 2019 6:09 AM
  • Hi,

    Thank you for posting here.

    >>Application randomly getting crashed

    As far as I'm concerned, randomly getting crashed are caused by memory management issues. Crashing programs usually generates a core dump file that can be loaded in windbg. Applications can produce user-mode minidump files , which contain a useful subset of the information contained in a crash dump file. A minidump file does not contain as much information as a full crash dump file, but it contains enough information to perform basic debugging operations. To read a minidump file, you must have the binaries and symbol files available for the debugger.

    I suggest you could try to use Windows Debugger (WinDbg) to debug kernel-mode and user-mode code, to analyze crash dumps, and to examine the CPU registers while the code executes.

    For more details anbout solve random crashes, you could refer to the link: https://stackoverflow.com/questions/3437809/solving-random-crashes.

    Best Regards,

    Jeanine Zhang

    Tuesday, June 11, 2019 7:42 AM
    Moderator
  • You can check if you have initialized all the pointers (Maybe to nullptr) in the constructors.
    Wednesday, June 19, 2019 2:48 AM
  • I have checked for all possibilities 

    That's debatable and probably should be reworded to say that you have checked 
    for all possibilities that you can imagine. You may have missed or overlooked
    some possibilities.

    Even if you have checked for the hard-to-define "all" possibilities, you could 
    have missed at least one case of one of those possibilities.

    Never approach debugging with the assumption that your abilities are infallible.

    If you haven't done so yet, run a code Analysis on the program source. Assuming
    that you're using a version of Visual Studio that has that feature. Also try 
    running other static code analyzers on the source, such a Cppcheck:

    http://cppcheck.net/

    Static analyzers often detect things that compilers - and programmers - miss.

    When you build the program set the Warning level to its highest value of 4,
    and be sure to take all warnings seriously. Correct the code as needed to
    eliminate *all* warnings - but do so *without* trying to "hide" them via
    pragmas, casts, etc. Fix them the right way.

    As has already been noted, we can't debug code we can't see. So unless you give 
    us more details you will have to find the cause of the error yourself.

    Randomly occurring errors are quite often the result of using uninitialized
    variables, the contents of which will often be different (random) each
    time the program is run.

    - Wayne

    Wednesday, June 19, 2019 6:57 AM
  • I have checked for all possibilities like null pointer,threads etc.


    I should mention heap corruption as another possible cause for access violations.
    In addition to overruns and underruns, abusing or confusing the heap manager by
    doing things such as deleting an already deleted pointer into the heap can result
    in errors from the heap when later operations on it are attempted.

    - Wayne

    Wednesday, June 19, 2019 7:16 AM