Jump to content
  • Advertisement
Sign in to follow this  
snooty

Visual Studio 2005 Debugger

This topic is 4315 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How can I use VS2005 to trace the point of crash? For instance, if the following is outputed: Data Abort: Thread=8d9d12f0 Proc=8c247550 'Test.exe' AKY=00004001 PC=0002e198 RA=0002dccc BVA=1e000000 FSR=00000407 From experience, I know the error is probably caused by dereferencing a null pointer. But how do I know where that pointer is dereferenced?

Share this post


Link to post
Share on other sites
Advertisement
Simply put a breakpoint near the start of your program. Run your program, then start stepping through it (ie, F10). Once you step over a function that causes the crash, restart, but this time place the breakpoint on that function and step into it (F11). Once in that function, step through it (F10) until it crashes again. Rinse and repeat until you find the line of code causing the crash.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mantear
Simply put a breakpoint near the start of your program. Run your program, then start stepping through it (ie, F10). Once you step over a function that causes the crash, restart, but this time place the breakpoint on that function and step into it (F11). Once in that function, step through it (F10) until it crashes again. Rinse and repeat until you find the line of code causing the crash.


Wow. That's kinda clumsy, if I have several thousand lines of code.
I was expecting VS to have something more sophisticated. Apparently, that's my false hope.

Thank you anyway.

Share this post


Link to post
Share on other sites
I really shouldn't take more than a few minutes to track it down that way. Or, if you just recently added some code, start there and you'll find the problem even faster. I don't see how that's clumsy.

If your several thousand lines of code is all in one large function, then it may take a bit longer and you should reconsider the design. But if your program is broken up in to nice sized functions, it won't take long at all.

Share this post


Link to post
Share on other sites
Just run your application inside the debugger. If you have the code, load up the solution and run in debug mode.

If you don't have the code, then clicking on tools -> Attach to ... (or something, can't check right now) allows you to run with a debugger attached.

Whenever the application crashes, you can see the stack trace, etc. If you have debug information (pdb files and the like) you can better see the likely cause (note that assembly listings are available too).

Good luck!

Share this post


Link to post
Share on other sites
Run in the debugger. When it crashes, it does not automatically terminate the debugger. The execution pointer is usually sitting at the line where the error occured. You can even move the execution pointer (a yellow arrow in the left gutter) back a few lines and then single step to observe variables and determine which one, specifically, is null and why.

Share this post


Link to post
Share on other sites
Strange. I always test the programs in the debugger, but when the fore-mentioned error occurs, the call stack will turn blank, there is no assembly listing, and the yellow arrow disappears too.

However, it is still debugging, and if I do something else in the program, it is still responsive.

PS. I have all the source code (well, except the APIs).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!