Find previous debug line in Visual studio 2005 - visual-studio-2005

I'm trying to debug a C++ project in VS 2005.
In debug mode how can i find the previous line that got executed.? i.e Consider the control is in line 5000. How can i find the previous line which got executed before coming to line 5000. Actually there are few goto statements involved. Call stack is just displaying the previous functions which were called.
Though i know it is not a good practice to use goto, this is an existing project which I'm debugging. Thanks in advance.

This information is lost. You should single-step in the code or add logging to know which lines were executed.

If you got to line 5000 by a goto or a jump (rather than by a call), then there is no record of where you came from. You will just have to go back and trace through the code and watch it as it jumps to line 5000.

If you can recompile the source (which I guess you can since you've got debug information) you might want to sprinkle the code with calls to OutputDebugString each with a different bit of text - for example before each label and each goto.
That way when your line gets hit you can check which messages got dumped to the output window to find the execution path.

Related

Debugging in VS Code without breakpoints

I'm trying to use the Visual Studio Code debugger to run a Go application to try and understand the code base.
I have to manually set breakpoints to pause execution but doing this may result in missing some part of the code.
So I was wondering if there is a way to pause after every line without having to manually set breakpoints. Any help?
If you are using gdb you can use 's' to step line by line.

Debugging in Visual Studio hangs unless paused and continued

I have a .NET Core 2.1 solution containing 2 F# projects, one class library and one executable. When I run the executable project with the command:
dotnet run --project ServerProject
it shows the Suave.IO log message immediately:
Smooth! Suave listener started in 92.632ms with binding 0.0.0.0:3000
However when I try to debug in Visual Studio (2017 or 2019 Preview) nothing appears on the dotnet.exe window at all — unless I pause debugging and continue, at which point it will carry on as usual and display the log message immediately.
I have set breakpoints to try and figure out where it gets stuck but nothing special happens there at all. My code loads some data from a CSV and it somehow gets stuck at the stage where it converts the CSV's rows into some records. All breakpoints and printf statements before this function get hit but the subsequent ones don't. And every time I pause debugging it seems to pause at a different point of this cell parsing code, so it's not even hanging in the exact same place every time.
I'm fairly new to the .NET world so I'm not even sure where to start investigating. Any help would be appreciated!
EDIT:
Adding this to say that this has been happening consistently for many months now. Any ideas would be really appreciated.

creating a save point when debugging in visual studio

I have an error which is occurring only very late in my code (after it's been running for ~20 minutes) and so trying to pinpoint exactly where it is is tricky because I have a lot of recursive function calls and if I go too far the important variable values may have been changed. Is there a way I can set a kind of save point where all the variables have their values saved and which I can jump back to after I've done some exploring rather than having the run the whole thing again from the beginning?
I found this and just wanted to point out that Roger Lipscombe's comment is what I was also looking for:
Precisely: IntelliTrace https://learn.microsoft.com/en-us/visualstudio/debugger/intellitrace?view=vs-2022
and
Historical Debugging (which is part of IntelliTrace) https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2015/debugger/historical-debugging?view=vs-2015&redirectedfrom=MSDN
Only available on the enterprise version of Visual Studio
I have a workaround for this kind of issue: Using the Data Breakpoint, at least, it could output and save the value manually, and it also can help you check that what value was applied to your code line, I just get this idea from this case I met before:
Visual Studio. Debug. How to save to a file all the values a variable has had during the duration of a run?
If IntelliTrace tool is helpful for you like Roger Lipscombe's suggestion, one idea is that you could use IntelliTrace Standalone Collector tool without the VS in one machine:
https://msdn.microsoft.com/en-us/library/hh398365.aspx

Is there an operation Step Back in NetBeans during debug process?

In NetBeans when you insert Breakpoint and Debug project, it runs code until the Breakpoint and stop right in a line where we put Breakpoint. And afterwards we can execute our code step by step. If we Press F8 which is Step Over operation, NetBeans executes next line. Sometimes we want to go back to the previous executed line because we want to change that line and see how it will work.
So, the question is how can I say NetBeans to Step Back (if we can call this like this), so instead of executing next line code it executes previous line code? I remember in Visual Basic 6.0 (now I don't know because don' t use it anymore) we could manage current execution line, i.e. we could just drag and drop debug pointer to the line we want during the debugging and it would start to execute code right from the place we put it. Is it possible in NetBeans?
Update 1
I use NetBeans for debugging PHP application. PHP uses php_xdebug-2.1.0RC1-5.3-vc9-nts.dll to to debug PHP code.
I think he was referring to the pop top most call stack.
http://wiki.netbeans.org/FaqDebugBackup
It's not only a matter of Netbeans (or to say it more generally: your IDE), it's also a matter of the debug capabilities of your jvm.
AFAIK, no jvm does currently have this feature.
What might be possible (in Eclipse it is) is to step to the beginning of the method, but you have to be careful about the state of your objects, because you may reach a state which you won't within a normal execution.

"One or more breakpoints cannot be set and have been disabled. Execution will stop at the beginning of the program."

I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally

Resources