Take the 2-minute tour ×

I have written a BSP level renderer and have ironed out all of the specific - this line caused the crash - errors. The problem is that now, I am getting some nonspecific errors like:

"Unhandled exception at 0x77318db9 in Lantern.exe: 0xC0000005: Access violation writing location 0x00000014."

This happens when I close my program and in Visual Studio, a windows header like _file.c will pop up but it isn't specific to what the error may be. I get other memory issues when loading the program with specific kinds of BSP map data. Does anyone have suggestions for how to debug these general issues? I have an error logger put in place so I can see what functions correctly finished before there was trouble but it doesn't always help me pinpoint the error.

Is there a guide to error debugging using Visual Studio 2010. How do you debug errors that you run into when they are similar to what I have described? Is there a way to find the function that caused the error?


share|improve this question

2 Answers 2

Looking at that particular error I would guess you have a null pointer somewhere, since it's fairly unlikely you'd be poking around 0x00000014 otherwise.

Run the program in the debugger, and when it breaks you should either be at the place where the error occurred, or be able to look at the call stack window to move farther back in execution and maybe find out where it went wrong. If you're corrupting the stack then it will be more difficult to track down.

If you're still getting hard to interpret results it can help to #if 0 out portions of the function that you suspect might be going wrong to narrow down the possibilities.

share|improve this answer
Thank you. A null pointer makes sense. When you say run the program in the debugger, do you mean, run the compiled EXE and attach the debugger or something else. Also, what am I looking for in the call stack. Lots of stuff in there. –  Satchmo Brown Nov 12 '11 at 9:18
After you've compiled you can press F5, click the green arrow, or select Debug->Start Debugging to run the program in the debugger. If you need to specify a working directory or arguments you can do that in the project property sheet under Debugging. –  Retired Ninja Nov 12 '11 at 9:24
Ahh yes. Then I have been using the debugger. Still getting that same bizarre message on exit though. Oh well. What can you tell me about the call stack? –  Satchmo Brown Nov 12 '11 at 9:25
Such messages are not bizarre... They are just the consequence of bizarre code. Does this happen, after your program appears to have left your 'main' function (or equivalent of it)? If yes, then you've probably ran into some kind of deinitialization problem with global variables. Does the stack contain '_onexit' or similar entry? –  Paul Michalik Nov 12 '11 at 12:38
up vote 0 down vote accepted

I figured out what the error was. Apparently, when using SDL, the application will have trouble if you link SDL.lib and SDLmain.lib with #pragma comment and not through the linker in the project settings.

Maybe a bug in their code, not sure.


share|improve this answer

Your Answer


