Sign in to follow this  
snooty

Visual Studio 2005 Debugger

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
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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this