AccessViolationException occurs when render window closes.

Hello,
I am very new to Mogre. I have read many topics that involve an AccessViolationException, but the ones I have seen so far have all dealt with trying to accomplish a complex task. I narrowed my code down to simply creating the Root object, defining the resources, creating the render system, and creating the render window. The error occurs WHENEVER the render window closes. This error has happened all throughout the basic tutorial series for me as well, but I have ignored it until now. It's probably something simple/stupid. I hope it is at least.

The details of the exception object are as follows:
System.AccessViolationException was unhandled
Message=Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Source=Mogre
StackTrace:
at Ogre.Root.{dtor}(Root* )
at Mogre.Root.!Root()
at Mogre.Root.Dispose(Boolean )
at Mogre.Root.Finalize()


I've tried to trap the AccessViolationException error and other types of errors, but with no success, because I think it is happening within Mogre.dll? Hopefully someone can help. I have a basic understanding of memory concepts, but I much prefer not to deal with all that unless I have to (which is why I chose Mogre vs Ogre), so my knowledge of all that stuff is fairly limited. Thanks in advance for any advice.

Again this happens whenever I close a render window, regardless of loading any resources or creating a scene. A blank render window will raise the same exception when I terminate the render loop.

The first thing I would do is check your Ogre.log file. Chances are the error has been logged in there.

Also, when your wrapping Mogre code in a try catch block you *must* catch SEHException's specifically otherwise they will be ignored.


try
{
// some mogre code here
}
catch(SEHException sehEx)
{
// some Ogre exception happened
if (OgreException.IsThrown)
throw new Exception(OgreException.LastException.FullDescription, ex);
}
catch(Exception ex)
{
// normal .NET exception
}


Also, when your wrapping Mogre code in a try catch block you *must* catch SEHException's specifically otherwise they will be ignored.
But if you do that, it is difficult to trace an exception because the exception is catched very late (and you cannot check the debug values etc.). And Mogre always throws an exception, e.g. if I try to load an invalid mesh; I never "missed" an exception.

Back to topic:
Have you destroyed all resources before you try to exit your program? Usually this happens if you forgot to unload an resource. I think the scenemanager has some function like "DestroyAll...". Call them all in "DestroyScene".
And you should definitly check the log, its very informative.
If the exception still occurs and you have no idea why AND you have VS Standard or better: Use the debug builds (in the sdk, suffix: "_d"). If you do that, you have to change the plugin names in plugins.cfg (because the files now have ends with an "_d", your references e.g."Mogre.dll" to "Mogre_d.dll" and turn "Debug unmanaged code" in VS on. This makes it possible to step through Ogre's source code and to track down this error.

But if you do that, it is difficult to trace an exception because the exception is catched very late (and you cannot check the debug values etc.). And Mogre always throws an exception, e.g. if I try to load an invalid mesh; I never "missed" an exception.
What you just said sounds interesting but I'm not exactly sure what you mean? Are you saying there is a better way to handle loading an invalid mesh that won't throw an exception?
There is an option in all versions of Visual Studio to break on exceptions rather than letting them fall into the catch block.

I mean, if I do something wrong (e.g. load an invalid/not present mesh), it throws an exception in MeshManager.Singleton.load(...). Just like exspected. But if I surround the whole program in a Try-Catch-Block (like in the tutroial projects), ALL exceptions are catched *there*, and I have to find the file and line in the excpetion description. That makes debugging difficult.

I mean, if I do something wrong (e.g. load an invalid/not present mesh), it throws an exception in MeshManager.Singleton.load(...). Just like exspected. But if I surround the whole program in a Try-Catch-Block (like in the tutroial projects), ALL exceptions are catched *there*, and I have to find the file and line in the excpetion description. That makes debugging difficult.
Right sorry. We must've misunderstood each other. What I meant was to only wrap little bits of code in a try catch block, not the whole program. My real point was that it has to be an SEHException not a normal .NET Exception. Of course, you don't have to do it this way if you can handle the error some other way and know it will never throw an exception.