Visual Studio 2005 Debugger
Author
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?
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.
Author
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.
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.
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.
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!
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!
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.
Author
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).
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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
