Is it possible to break debugging as TRACE(the debugger message output macro) is called, the message from trace appears on output, but I am unable to break the debugger as it does. (Am using visual studio 2003/windows).
I do not have the source code for this application. I'm simply attaching to the process.
Put a breakpoint on one of your TRACE calls. Do whatever you need to do to make it fire. Step In. Put another breakpoint in that code. Remove your first breakpoint.
Edit: Put a breakpoint on the OutputDebugStringW and OutputDebugStringA APIs in kernel32.dll - it's those APIs that the TRACE macro calls.
In the Breakpoints window, go New / Break at Function, and enter _OutputDebugStringW#4. Repeat for _OutputDebugStringA#4.
Related
Is there a way to do something like DebugBreak() where when that function is hit the debugger breaks, but continue running when no debugger is attached?
I have a lua error handler that presents a user-friendly error message when something goes wrong, but if I'm debugging I want to stop execution as soon as I've detected something wrong.
I don't want to set a breakpoint in the debugger UI. I want a line of code that causes the debugger to break so I can share this breakpoint with co-workers.
You can use IsDebuggerPresent to check for an attached debugger, and then conditionally invoke DebugBreak:
if (IsDebuggerPresent()) {
DebugBreak();
}
I'm having some difficulties determining what is causing a process to exit. I have a breakpoint in some shutdown code that I'm debugging, but, after breaking in the debugger at the breakpoint and stepping once, the whole process exits immediately. Every thread reports an exit code of -1 in the output window. There are a large number of threads in the process at that time, and the code base is quite large, making searching for the culprit difficult.
I've tried installing a std::atexit function, but this doesn't get hit. I've also tried overriding SetUnhandledExceptionFilter, in case it is caused by a crash, and it also doesn't get hit. The project has exceptions disabled (#define _HAS_EXCEPTIONS=0), so I cannot call std::set_terminate or std::set_unexpected.
Is there some other way to determine what is causing the process to exit? Some option to break in the debugger when the process is about to terminate?
Run your app with debugger and read the debug output. If the app terminates because C++ exceptions, or SEH, you’ll read it in the output window.
If you’ll see nothing interesting there, it means your app called ExitProcess/ExitThread/exit, or worse, TerminateProcess/TerminateThread/_exit.
You can put breakpoints on these. Set a breakpoint at startup, launch debugger. Ensure you have debug symbols loaded for relevant DLLs, kernel32.dll for ExitProcess and friends, some other DLL for exit, e.g. ucrtbase.dll. Press “New / Function breakpoint” in the Breakpoints window, type e.g. “ExitProcess”, press OK.
You can also try using gflags tool from Windows SDK.
If you’ll find (by reading Windows Logs > Application) the reason was self exit, you can check “Enable dump collection” in gflags, then you’ll be able to load the dump in WinDBG and get the complete call stack telling you who called what.
Unfortunately, the latest version of the tool is broken beyond repair.
But you can install older Windows SDK. You only need “Debugging tools for Windows” from there, no need to install the complete SDK.
Can anyone help we out to see the Call Trace in the Trace 32 debugger. I remember such option is available in UDE debugger. Is such option available in the Trace32 as well.
Example:-When a interrupt has raised then I wanted to know what all function s are called in sequence before reaching my break point(if have a break point in some part of code).
To view the call stack use command Frame.view (or Var.Frame if you have an older copy of TRACE32). From the Menu it is View > Stackframe.
I'm reading source codes of a huge project.Some functions are encapsulated in dlls.
So I want to add breakpoints before every functions defined in codes,in order to follow the process of this project by F5 and avoid the disassembly window show on visual studio.
There are thousands functions in codes, I can't add every breakpoints by manual work.Is there any method or add-in to help me to do this work?
Tks!
Good approach in your case would be start with F10 instead of F5. And in VS you can check all calls with one break point. You should make use of call stack window provided by Visual studio. Whenever a break point will be hit, it will show the whole path from where the call was initiated. After a break point hit, the "call stack" tab will appear with other tabs at the bottom of VS like Error List, Output, Find Results.
I am getting this error with my c++ code:
http://imageshack.us/photo/my-images/193/vcerror.png/
The only problem is it doesn't point me to where the problem is... I understand the string subscript is out of range but I have no idea where it could be.
I was wondering if there is anyway I am able to find where it is? I have a rough idea so I have put a breakpoint in there but how VC++ does breakpoints is horrible. I step-through but it only shows me the code from the C++ files themselves, not my own code.
So, I step over and the error shows straight away.
How can I track down this problem?
Basically, you need to look at the callstack and have all your symbols setup.
I'm going to take a wild guess and suggest that you may not know how to use the "call stack" window.
In a debug session of your program and no breakpoints set, allow your program to run until it hits the assert dialog. Press "retry" to allow control to be passed to the debugger. Another dialog may pop up to prompt you to "break" or "continue". Select break. You should be broken into the debugger at this point.
Then make sure you can see the call stack and have at least one watch window up.
Debug->Windows->Call Stack.
Debug->Windows->Watch->Watch 1
You can double-click on any item in the call stack window to jump to the exact line of code where execution is expected to return to. (Sometimes the little arrow on the editor window is pointing to the next line of code to run after the previous call returns). Double click on the function line in the call-stack window that is directly below the top call stack line. That's likely std::basic_string::operator. What value is getting passed into this function? If hovering over the variable name doesn't work, add it to the "Watch" window. Also, add a watch for "this" so you can analyze the actual size and capacity of the string.
Double click on the function call in the call-stack below where you are currently at. This should take you to the actual buggy line of code in your program. Add another watch for the string variable and should be able to figure out what went wrong.
The rest is up to you.
I'm assuming this is a standalone EXE project with everything build by the IDE. If it is not, then make sure the PDB files from each binary produced is in the same directory as the corresponding binary. Again, if this is a simple EXE project in Visual Studio, this is automatic. Just to be sure, make sure you "Clean" your build first, then do a complete rebuild. That sometimes fixes debugging kinks.