i'm really new to debugging, and debugging is not my strong point so just so i'm not confusing anyone, i'm not asking how to set a breakpoint in a program using ollydbg, but the break feature, somewhat similar to the break that is available in visual c++ debugger when debugging a program there, is this available at all in ollydbg?
if it is then what do i do it use it? or if it's not then is there anything else that i can do to similate a break in a program using the ollydbg WIN32 debugger?
If what you mean is the "Break all" feature of the Visual Studio debugger, which suspends all threads and sets the cursor to the currently executing source line (or one of them, at least, you can use the threads tab to change threads)...
... then this is analagous to the OllyDbg pause function, which again suspends all threads and sets the cursor to the actively executing instruction.
To change between threads you can simply open the threads view (alt+t) and press enter on the required thread. This will take you to the EIP for that thread.
Related
I am trying to dive in a really big codebase. I am using Visual Studio Code. I always used debugger with setting the breakpoints, but this time I just would like to become familiar with a new codebase and see where is the code responsible for particular program commands execution. Is there an option to run debugger step by step without setting breakpoints in VSC? Or where can I find e.g. what functions where called during my program execution? In Call Stack section I see only the threads number.
I see a command
editor.debug.action.runToCursor
if you don't want to set breakpoints. It has no default binding so you will have to make your own. I tested it and it works. When your code stops - at your cursor - you should see the call stack (assuming the call stack panel is not hidden).
I've always wanted to know the inner-workings of Visual Studio's debugger and debuggers in general. How does it communicate and control your code, especially when it's running inside a host process or an external network server (attach to process)? Does the compiler or linker patch your code with callbacks so that the debugger is given control? If it indeed works this way, how do interpreted languages such as JavaScript containing no debug code work?
Generally speaking, Windows provides an API for writing debuggers that let you examine and modify memory in another process and to get notifications when exceptions happen in another process.
The debug process sits in a loop, waiting for notification from events from the process under inspection. To set a breakpoint, the debugger process modifies the code in the debugee to cause an exception (typically, an int 3 instruction for x86).
The compiler and linker work together to make the symbol information about a program available in a format that can be read by debuggers. On Windows, that's typically CodeView in a separate PDB file.
In the Unix-derived world, there's an API called ptrace that does essentially the same sorts of things as Windows debugging API.
For remote debugging, a small program is placed on the remote machine that communicates with and acts on behalf of the actual debugger running on the local machine.
For interpreted languages, like JavaScript, the debugger works with the interpreter to give the same sorts of functionality (inspecting memory, setting breakpoints, etc.).
Windows includes support for debuggers. A process has to enable debugger privilege, and once this is done that process can attach to any other process and debug it using windows debugger functions
http://msdn.microsoft.com/en-us/library/windows/desktop/ms679303(v=vs.85).aspx
For something like javascript, seems like you would need the equivalent of a javascript debugger.
In the case of a Visual Studio multi-process project, you typically have to switch which process the debugger is attached to in order to debug that process. I don't know if there's a way to have pending breakpoints set for multiple processes at the same time. There could be other debuggers that work better with multiple processes, but I haven't used such a tool.
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 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.
1.exe doesn't give enough time for me to launch the IDE and attach 1.exe to the debugger to break into.
I would suggest taking the same approach as with NT services in this case. They will also start and usually not give you enough time to attach the debugger for the start-up routines.
Details are described here: http://www.debuginfo.com/articles/debugstartup.html
In short you add a registry entry for the second exe:
HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Image File Execution
Options\2.exe Debugger =
"c:\progs\msvs\common7\ide\devenv.exe
/debugexe" (REG_SZ)
Change the c:\progrs\msms\ to match your settings.
Hope that helps.
I assume you have the source to 1.exe (if you're debugging it), then just insert a statement near the beginning that will cause it to hang around long enough to attach a debugger. ( getch() if you're desperate and it's not interactive. )
After the attach, just skip to the next statement and let it go.
You could put in some preprocessor commands for debug builds - just remember to build your release in release mode:
#ifdef DEBUG
Thread.Sleep(10000);
#endif
How is 1.exe launched? If you can launch it using CreateProcess(), you can start the process in a suspended state, attach the debugger, then release the new process.
If you are willing to consider a debugger other than Visual Studio, WinDBG can auto-debug child processes (native code only).
You did not mention what language you are using. But if you using C# or VB.NET you can add Debug.Break() or Stop to trigger the prompt to attach debugger to the process.
Or as mentioned above just use something like Console.Readline() or MessageBox.Show() to pause starting of process untill you can attach debugger to it.