1

I seem to be having an issue using the call stack viewing functionality of Microsoft Visual Studio 2010 Professional.

During debugging, my application crashed, so I inspected it with the call stack view.

The offending line was contained within called showInDGV(...) nothing exciting, just trying to read an uninitialized variable or something...

All well and good, so next thing I did was check to see where the call to showInDGV() was coming from, because it is called from multiple places.

When double clicking the entry in the call stack (the entry that should highlight a showInDGV(...) subroutine call), the IDE highlighted the incorrect line.

Instead of highlighting showInDGV(), it highlighted the next non-empty line below it, which was End Sub

Clearly something is wrong here....

So I inspected the call stack further - turns out Visual Studio is highlithing the wrong line whenever I try to debug using the call stack.

This isn't actually the first time this has happened. In fact, it seems to always happen when working on a large project.

Initially, the call stack works properly and highlights the correct line, but at some point it gets messed up, and then it never seems to fix itself, even after closing and re-opening the program.

Does anyone know the cause/solution to this issue? I figure it might be some sort of corruption in the visual studio project, and I considered copying and pasting the source code into a new project but even if that fixed it, it wouldn't prevent it from happening again.

Improve this question
8
  • 1
    Silly question - did a restart of VS fix it? I've seen really wacky things fixed by simply closing and restarting the program. Commented Jan 2, 2015 at 21:28
  • Clean and Rebuild - it sounds like the symbols are out of date Commented Jan 2, 2015 at 21:30
  • Restarting did not make a difference. I also tried to clean and rebuild it by using the "Clean" functionality in the Build menu, and then clicking "Rebuild". (I tried for the entire solution, as well as the application only, since there were 2 menu options) and even tried combining this with a restart of the application; clean, close, restart, rebuild. Unfortunately, the issue persists unchanged. Commented Jan 2, 2015 at 21:40
  • It often happens to me. Especially irritating when profiling, because you never know if it's the line you are looking at causing the issue, or the one above it. Fortunately, if you are diligent with code, this assumption becomes obvious, and the original issue does not cause any serious problem. And no, I don't know why it happens. Commented Jan 2, 2015 at 21:40
  • Yea, I wouldn't say that its particularly hard to figure out, because you can always go 1 layer deeper into the stack and it will take you to the subroutine. Then you just go back up the stack, finding the subroutine call that is close to the right place. It just slows down the whole debugging process. The total time spent certainly adds up, so I figure it would be in my best interest if I could figure out how to fix this, rather than just dealing with it perpetually. Commented Jan 2, 2015 at 21:46
Load 7 more related questions Show fewer related questions

0

Reset to default

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.