CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 7 of 7
  1. #1
    Join Date
    Dec 2012
    Posts
    3

    0xC0000005 - Access violation (Each time from a different dll)

    I have been given a task to debug a C++ project. I have not written a single line of code in this project!!

    This project executes for about 5 minutes without problem. Then it ends with an exception "Unhandled exception at (some .dll name) in EITos.exe: 0xC0000005: Access violation reading location "

    Now every time I execute the program. The error is from a different dll. Sometimes it is a dll created by other programmers, sometimes it is related to QT. So I don't think this is a code problem. Is there any project setting that would affect this?

    I am asking some general tips and hints as to how to debug this problem.

  2. #2
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Location
    Florida
    Posts
    12,635

    Re: 0xC0000005 - Access violation (Each time from a different dll)

    Start by running the crashing program in the debugger.

  3. #3
    Join Date
    Dec 2012
    Posts
    3

    Re: 0xC0000005 - Access violation (Each time from a different dll)

    Yes I am doing that right now. If I see the call stack window, every time it crashes. The names listed are different. Hence I am not able to pin point what is causing the problem.

  4. #4
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Location
    Florida
    Posts
    12,635

    Re: 0xC0000005 - Access violation (Each time from a different dll)

    Do the arguments you're passing to the DLLs look valid? Is there any sign of stack corruption? You're probably just going to have to do a lot of stepping and looking for where things are going wrong.

  5. #5
    Join Date
    Apr 1999
    Posts
    27,449

    Re: 0xC0000005 - Access violation (Each time from a different dll)

    Quote Originally Posted by Shreyes View Post
    I have been given a task to debug a C++ project. I have not written a single line of code in this project!!
    You can't use that as a reason to not be able to debug a crashing program. There isn't any reason whatsoever for not able to, at the very least, figure out what is causing the issue. It really doesn't matter if you wrote no lines, or even if you didn't know what the program is supposed to do.

    If you have the source code, can build the application, and then run it, then there is no reason to not be able to figure out what is causing the problem. You may not be able to fix the problem right away, but to find out why something is happening doesn't require any knowledge of how the program was written, given that you can build/run the program under the debugger, and you are competent in the C++ language.
    Now every time I execute the program. The error is from a different dll. Sometimes it is a dll created by other programmers, sometimes it is related to QT. So I don't think this is a code problem.
    Why would you conclude it isn't a code problem?

    If you overrun an array, not handle pointers and/or dynamically allocated memory correctly, not check your return values from functions and just assume they "work", if the app is multithreaded and not handling synchronization issues correctly, etc...etc.., can cause these issues. In C++, any mistake in handling these issues causes undefined behaviour in a program.
    Is there any project setting that would affect this?
    The last thing to look at are project settings. You only look for project settings after you've determined what the problem is by debugging the program.
    I am asking some general tips and hints as to how to debug this problem.
    Step by step. When it crashes, look at the call stack and see where the function call originates. Don't just look at the top function in the stack and conclude "it's different than before" -- look at the entire stack and see where the original function call was made. That should have been the first thing you should do. Be happy it crashes and has a call stack, regardless of what the functions in the call stack are. You have something to work with, and just ignore the other scenarios where the call stack is different.

    Now that you have a call stack, go to the origin of the call. Once you know the origin of the problem, inspect the parameters passed at the point of origin. Are the parameters valid? Is there a chance that memory corruption could have occurred to make them invalid (if they are invalid at that point)? Then go through each function in the stack, asking these questions to yourself, at the same time, looking at the source code around the function calls to see if something could have gone wrong. If the app is multithreaded, investigate whether a thread may have changed the value(s) when the function was called, causing a race condition or other synchronization problem.

    Regards,

    Paul McKenzie

  6. #6
    Join Date
    Mar 2006
    Posts
    151

    Re: 0xC0000005 - Access violation (Each time from a different dll)

    Adding code to force the CRT to check the integrity of the heap before calling the DLL functions might help. I would do this by running it several times and, each time it crashes, add a call before the call into the DLL, and also at several points in the call stack leading up to it. Then run again.

    Code:
    _ASSERT(_CrtCheckMemory());
    WhateverCallToDllFunction(argument1, argument2);
    _ASSERT(_CrtCheckMemory()); // Might help to identify corruptions caused by bad arguments to DLL
    Note this only works in a debug build.

    If one of the assertions fails, add more of these statements at points in the call stack leading up to the failure. This can be a really quick way to find things like array overwrites.

    Also, manually step over calls to the DLLs and make sure the stack pointer ($esp in the registers window) is the same value after the call as it was before.
    Last edited by GeoRanger; December 22nd, 2012 at 01:05 AM. Reason: Fixed a grammar error.

  7. #7
    Join Date
    Dec 2012
    Posts
    3

    Re: 0xC0000005 - Access violation (Each time from a different dll)

    Quote Originally Posted by Paul McKenzie View Post
    You can't use that as a reason to not be able to debug a crashing program. There isn't any reason whatsoever for not able to, at the very least, figure out what is causing the issue. It really doesn't matter if you wrote no lines, or even if you didn't know what the program is supposed to do.

    If you have the source code, can build the application, and then run it, then there is no reason to not be able to figure out what is causing the problem. You may not be able to fix the problem right away, but to find out why something is happening doesn't require any knowledge of how the program was written, given that you can build/run the program under the debugger, and you are competent in the C++ language.
    Why would you conclude it isn't a code problem?

    If you overrun an array, not handle pointers and/or dynamically allocated memory correctly, not check your return values from functions and just assume they "work", if the app is multithreaded and not handling synchronization issues correctly, etc...etc.., can cause these issues. In C++, any mistake in handling these issues causes undefined behaviour in a program.
    The last thing to look at are project settings. You only look for project settings after you've determined what the problem is by debugging the program.
    Step by step. When it crashes, look at the call stack and see where the function call originates. Don't just look at the top function in the stack and conclude "it's different than before" -- look at the entire stack and see where the original function call was made. That should have been the first thing you should do. Be happy it crashes and has a call stack, regardless of what the functions in the call stack are. You have something to work with, and just ignore the other scenarios where the call stack is different.

    Now that you have a call stack, go to the origin of the call. Once you know the origin of the problem, inspect the parameters passed at the point of origin. Are the parameters valid? Is there a chance that memory corruption could have occurred to make them invalid (if they are invalid at that point)? Then go through each function in the stack, asking these questions to yourself, at the same time, looking at the source code around the function calls to see if something could have gone wrong. If the app is multithreaded, investigate whether a thread may have changed the value(s) when the function was called, causing a race condition or other synchronization problem.

    Regards,

    Paul McKenzie
    Thanks for the elaborate reply!!
    I am not giving any reasons and I did not mention that I cannot debug a crashing program!
    I am extremely time limited as I am a student and this is my student job. So I came to some quick conclusions and thought I might find some quick fix.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured