I tried using the debugger in Visual C++ 2010 Express on a few files to familiarize myself with the with breakpoints, step into, and etc. but many times if I use one of the step commands (at least step into) it will open another file like "ios" or "ostream" and do the command there instead of the actual program I'm working on. It seems to always happen after the last statement in my program and once it does it won't let me use the step commands on my own program anymore until I restart debugging. It's really annoying and sometimes it won't even let me use step into, over, or out even once. It will just open "ostream" or something and use it there.
Does anyone have a solution to this?
You're stepping into the CRT (C++ Runtime). Hit Shift+F11 and you'll step out. You can avoid stepping into the runtime by right-clicking the line, and using the "Step into specific" option to step directly into your code
Related
This question already has answers here:
debugging a process spawned with CreateProcess in Visual Studio
(3 answers)
Closed 7 years ago.
I have a program running which loads up a separate program to do some work for it. That separate program is run from the first, using Process.Start() and I need it to load into the Visual Studio debugger to single step through it.
Unfortunately, though I can run the first program in a debugger session, it still starts the second as a "proper" process. I need to have this second program open up in a debugger session. Normally I would just attach a debugger to the process once it's started but, in this case, I need it to breakpoint very early on (in the CInitDialog() function) and, as fast as I am, I can't outrun the code in this case.
A solution I found right here on Stack Overflow said to use Debugger.Launch() but that appears to be specific to C#.
I also thought of trying to cause a crash in the code (such as with a null pointer reference) to load up the debugger but I suspect this would mean single stepping would then be unavailable to me.
How can I do this?
Visual C++ has a similar feature to the C# Debugger.Launch(), it's called DebugBreak(). This actually breaks the application and it will present you with a dialog box asking how you want to handle it:
If you select Debug the program at that point, it will then ask you whether you want to do it in a new Visual Studio session or an existing one. I tend to have the solution already open so I can effectively attach to that one - opening a new instance gives you just the file rather than the entire solution.
So you can simply insert that call in your code where you want to break, and allow the first program to run it as per normal. The second program will start up and break where you've placed the statement and you can then single-step and do all the other wondrous things a debugger allows.
I've had several times where I was writing a program using Visual Studio and something, somewhere along the line breaks. Naturally, my first thought is to set a breakpoint early on in the program and then step through the code slowly, line by line until I reach the error.
But often times I find that everything works correctly when slowly stepping through code in the debugger. However, when I just try to run the program without breakpoints something goes wrong.
Why does this happen? Is stepping through the code line by line actually different from just running the program in dubug mode?
(I'm not talking about debug vs release, i'm talking about debug vs line-by-line debugging)
One reason could be that you have timing issues between multiple executing threads that occur differently when the program runs "at full speed" and when you pause a thread in a debugger.
It could be due to a some thread unsafe operations that seem to happen correctly when stepping through the code but not at run time. Compiler optimizations are ruled out because you are sure that you are running a debug build.
Running inside the debugger materially alters the runtime options for eg. heap operations so that errors can be detected and surfaced to the user.
See here.
When a process is run under any debugger, certain heap debug options
are automatically enabled for all heaps in the process.
This is not for sure your issue, but a likely candidate.
With visual studio you can attach to a running process, hit 'pause' (or called break), and even without symbol files or source, you've paused the process and can see a disassembled view.
I would like to achieve this but at the very start of the process. Attaching and pausing as quickly as possible is not the solution I'm looking for :)
For example, if the application was a console based c++ app, gdb can set a break point on main() [or any named function it can find for that matter]. Can something similar be done with visual studio?
But this question is for the more general case - I'd like to be able to start a process and have it pause immediately upon entry (immediately after the kernel launches the process).
http://blogs.msdn.com/b/greggm/archive/2008/09/12/attaching-a-debugger-at-startup.aspx
There are some level of support. But if I were you, I would use WinDbg directly.
I want to run the Visual Studio debugger on a .Net program that has been obfuscated. (It's my own program - I'm not trying to crack someone else's program.)
When I compile the program with "System.Diagnostics.Debugger.Break()", or if I attach the debugger to the running process, then the debugger shows "No Source Available". This I understand - there is no source that corresponds to the obfuscated version of the program. But when I click "Show Disassembly" it shows a Disassembly window with "No disassembly available."
Why? Any suggestions as to what I can do to get the disassembly to work?
Under Debug Options I do have "Enable address-level debugging" and "Show disassembly if source is not available" checked.
Thanks.
EDIT
Just to try to explain a bit more ...
The program in question is my own program, and the obfuscation program being used is also my own program. The obfuscation program runs ILDAsm.exe, modifies the ILAsm code, and runs ILAsm.exe.
My obfuscation is apparently introducing problems so the program no longer works correctly. To understand how/why it isn't working I'd like to trace it. But for some reason Visual Studio debugger says "No disassembly available", and then I can't do anything at all. (When the non-obfuscated program is run under Visual Studio the Disassembly window can be opened and shows the expected information. It's only the obfuscated version that produces this problem with VS debugger.)
EDIT 2
Haven't been able to find an answer to my question, but I do have a sort of workaround now.
I've installed WinDbg and confirmed that it can attach to my obfuscated program and can at least single-step it and show the current execution location in a disassembly window. But I've never used WinDbg before, and it looks a bit daunting.
I've also followed the advice seen several places to load sos.dll into WinDbg. Maybe that will help.
But I'm guessing that what I'll actually end up doing is throwing lots of temporary logging statements into my program around the places where it's not working, and hopefully gain some understanding that way.
OK, I happened to stumble on what I was doing wrong.
As I mention in the first edit of my question, my obfuscation is being done by running ILDAsm.exe, modifying the ILAsm statements, and then running ILAsm.exe. It turns out I was missing the /Debug option on the ILAsm.exe run. So even though my Visual Studio builds were Debug builds, the JIT conversions at run time were Release/Optimize conversions.
With /Debug specified on ILAsm.exe I'm getting a PDB file, and when Visual Studio debugger connects to my program I'm getting IL source code display and, if I request it, disassembly display too! So now all is well!
I have a VB app that I need to monitor while it is running. I added some variables to the Watch window, but while the app is running the watch window is greyed out. The only way that I have found to see the variable values is to use Debug -> Break All, but this stops the program.
I have used other IDEs and they allow active variables to be monitored. Is this possible in VS?
Sorry if this is a noob question.
UPDATE: To be clear, my app is communicating with a piece of lab equipment and and as data is sent or received or errors are detected counters are incremented. I would like to watch these counters but I don't want to build a screen to do this since they are for debugging. I just assumed that this is basic functionality in any IDE
SHOCKED: It seems that Visual Studio does not offer this (what I would consider) basic functionality. For those that seem to think that this is not possible with an interpreted language, consider this thought experiment. If you pressed Break All quickly followed by a Continue then you would refresh the watch window - correct? Why then can't Visual Studio do this as a single Refresh Watch command or better yet allow this function to automatically run at a period specified by the user. No debug writes, no log files, no stopping your program mid-stream and creating timeouts. I am just shocked that you cannot do this. Its a little like not having breakpoints.
Which IDE or development environment shows - in real time - the values of variables in the Watch window, without having to hit any breakpoints, while the application is running?
Visual Studio doesn't provide this. In order to get updated values in the Watch window, or edit items there, the app needs to be at a breakpoint or debugging.
After you've done "break" to give control of the program to the debugger, then you can "step" through the code using function keys like F10 and F11. During each 'step', the program evaluates one or more statements; after each step it stops (until the next step), and while (only while) it's stopped you can 'watch' its current state.
There are other ways too to break into the debugger (to use the Watch window while the program is stopped): other ways like to set 'breakpoints', and use the 'run to cursor' feature.
Of course, but stopping a program that is actively receiving or sending data to a some other process, driver, etc, stops this communication and causes timeouts and other problems.
That's true. To watch values change in real-time, I use a log file:
Add statements to my code, such that when I change the value of a variable I emit a new line to a log file (showing the changed value)
Run the program
Watch new lines being appended to the log file using a utility like tail -f.
I've never see a debugger with the functionality you mention. The closest thing to the functionality you mentioned (and which isn't exactly the functionality you mentioned) is How to: Set a Data Breakpoint (Native Only).
What you're attempting to do is not possible in Visual Studio. All of the variable inspection windows (watch, locals, autos, etc ...) rely on the debugee process being in a break state in order to function.
This is true of essentially any debugger I've worked with in the past. At least those which use a compiled language.
I'm curious as to what IDE's you're referring to? Did they deal with interpreted languages?
Make sure you are in "Debug" build and Microsoft Debugger is running as a service and not blocked/disabled.
This should help you: How to trace and debug in Visual C++ .NET and in Visual C++ 2005
my 88 year old memory remembers an old version of visual studio allowing a watch window to function while debugging.
OK, just me.