First chance exception hunting.

Started by
4 comments, last by Evil Steve 15 years, 9 months ago
I get the following line in the output window using VS2008; First-chance exception at 0x7c4ea4e1 in Game.exe: Microsoft C++ exception: long at memory location 0x0012db0c.. My app doesn't break, so i'm assuming that the exception is handled somehow, but i'd like to see whats causing it to see if it might give me a problem. I know that you can get certain exeptions to throw using the 'Exceptions' dialogue in the 'Debug' drop down menu. But i'm not sure which one to check. It had been caused by numerous changes i made and i'm not sure which bit is doing it, any help tracking it down? The application seems to run ok btw. Thanks.
Advertisement
Use your Debugger to iteratively stop over your code till you track down what causes it.

I'm guessing (And I really mean guessing), it's something to do with SetWindowLong().

Alternatively, if the memory address is always the same, you could set a data breakpoint (See the linked article on how to do that).
Hmmmm no easy way then!? Stepping through it is then. I have done anything with SetWindowLong() but i will check it out. Memory location keeps changing so data breakpoint didn't work. I will see what i can find.
Quote:Original post by JimmyDeemo
Hmmmm no easy way then!?
That way is easy. The bug is probably in your initialization code, so you can just step through the code to find it. It shouldn't take more than 5 or 10 minutes to track down to the Win32 call that's doing it (Since 0x7c4ea4e1 is in a Win32 library, looks like user32.dll or kernel32.dll).
Ah i guess i should have mentioned. I'm working with a scenegraph structure built by a colleague, and it seems like its one of them thats throwing the exception. So i guess what i mean by 'no easy way' was 'no quick way' as in stepping through i'm going to have to traverse through the tree order to find the offending item. I will keep at it though.
Quote:Original post by JimmyDeemo
Ah i guess i should have mentioned. I'm working with a scenegraph structure built by a colleague, and it seems like its one of them thats throwing the exception. So i guess what i mean by 'no easy way' was 'no quick way' as in stepping through i'm going to have to traverse through the tree order to find the offending item. I will keep at it though.
You could try logging the current item rendered / updated, and work from there. The one causing the problem will be the last one logged before the exception.

This topic is closed to new replies.

Advertisement