C++ Debugging Access Violation in VS 2010

Question

I'm kind of new to Visual Studio, and I'm getting Access Violation error in VS 2010 C++ project. Access Violation error sometimes points me to "free.c" microsoft file, sometimes to pieces of project code. The thing is, code isnt mine, but I have to implement thing or two into it. So the question is: how to trace the exact piece of code where Access Violation is rooted?

Just if someone is interested: I'm working with OSG and Qt, trying to create new thread for running OSG rendering in background. In simple example (just 3d-model + qt button) everything works fine, but when I try to implement Qt button into project it constantly gives me Access Violation

Thank you for your time!

Edit:

• this is where yellow arrow points ntdll.dll!77972c39()
• [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
• kernel32.dll!7776c3d4()
• this is where green arrow points msvcr100.dll!free(void * pBlock) Line 51 C
• osg75-osg.dll!52f245f1()
• osg75-osg.dll!52f2785e()
• osg75-osgQtd.dll!osgQt::QGraphicsViewAdapter::assignImage(unsigned int i) Line 565 + 0x59 bytes C++
• osg75-osgQtd.dll!osgQt::QGraphicsViewAdapter::setFrameLastRendered(const osg::FrameStamp * frameStamp) Line 477 C++
• osg75-osgQtd.dll!osgQt::QWidgetImage::setFrameLastRendered(const osg::FrameStamp * frameStamp) Line 54 C++
• osg75-osgViewer.dll!545b5a2e()
• osg75-osgUtil.dll!52c8b6a3()
• msvcr100.dll!malloc(unsigned int size) Line 89 + 0x3b bytes C
• msvcr100.dll!operator new(unsigned int size) Line 59 + 0x8 bytes C++
• osg75-osg.dll!52eac085()
• ..blah blah calling osg dlls and stuff..

meanwhile found out that problem appears not only when I try to create new thread but in few more various situations (even when I try to add someting to root group), so what I really need is to catch what causes Access Violation

Answer 1

Is there a chance you are mixing Debug and Release in the same application? Remember it is not generally safe to use Release dlls in a Debug application or Debug dlls in a release application since the Visual Studio release and debug heaps are incompatible.

So that was the solution, thanks to Drescherjm.

Answer 2

Sounds like an invalid pointer. First thing to do when it happens is to go up on the stack until you get into the project code (you can generally assume that things like "free" work fine), which might give you an indication which pointer is messed up. Beyond that it's figuring out how it might have gotten the invalid value.

It could, of course, be much worse. Access violations are pretty much a generic "some error" type; an invalid pointer, for example, could also be created by some code trashing random memory and hitting that pointer. Makes it very difficult to find the culprit, since it never actually addresses the pointer. If it does appear to hit the pointer "reliably", you could try setting a data modification breakpoint on the pointer, which breaks whenever that data is modified.

Of course, there can be many other things going wrong. There is no easy "click here, click there, and it tells you the line that is broken".