c++ with visual studio 2008
if i use assert() from assert.h and compile in debug mode, the application crashes if the assert condition doesn't hold and it prints me in the console on what line in what file this happened. that's quite useful, but i'd prefere to trap into the debugger at this position instead, if the condition doesn't hold
how can I do that?
thanks!
Try running your program under a debugger. Also, if you have a JIT debugger registered with the OS, then this should actually invoke said debugger. If you are on a Windows machine, take a look at this MSDN article or this post.
Related
I have an old VB6 app that uses a lot of 3rd party components, not just visual but also for audio processing, tcp/udp, VoIP, etc...
When I run the app as an EXE (e.g. not in the VB6 IDE), it will crash sometimes with a GPF. It happens after the program has been running for several days and occurs when there is no one around.
Unfortunately the user has clipped the screenshot, but it typically doesn't have any useful information anyway. The description of the crash reported that the crash occurred in ntdll.dll.
My questions:
What tools do I need in order to debug this?
How do I actually get started?
I have the PDB files from the compilation in VB6. The app is compiled to Optimize for Fast Code. What can I do with them in this situation?
I would use ntsd or windbg (link), and run the app under either of the user mode debuggers (if you're not familiar, they have the same commands - ntsd is a console debugger, while windbg is a GUI debugger). Both have a lot of command line options, but ntsd appname.exe will be enough to get started. Use the .sympath command to point the debugger toward the symbol, and you should be on your way. When the crash occurs, you can examine variables and stack in order to figure out what may be missing.
BTW - the error above is an invalid handle error, so the program probably passed a stale or NULL handle to a windows function. The debugger will tell you more.
I've been trying to use programmatic data breakpoints, à la the CBreakpoint example, by using SetThreadContext to set the debug register directly. Most references that I can find indicate the Visual Studio will still break whenever it encounters a data breakpoint, even if it didn't set that data breakpoint itself. However, this doesn't appear to be how Visual Studio 2010 works.
I'm in a situation where my data breakpoint works perfectly when the program is not being debugged (it crashes with STATUS_SINGLE_STEP, which is the exception raised by a data breakpoint). It also breaks properly if I'm debugging with WinDbg. But when debugging it under either Visual Studio 2010, it seems to just keep trucking and ignore the breakpoint. Does anyone have any experience with using a programmatically-set data breakpoint under Visual Studio 2010, under Windows 7? Is there something that I need to do to it them to break? (I tried adding STATUS_SINGLE_STEP to the 'first-chance exceptions' list, with no change in behavior.)
Alternately, is there anything that I might be doing to swallow the STATUS_SINGLE_STEP exception in the debugger? Would a structured exception handler eat the exception before the debugger can see it? Is anything affected by the fact that this is a x86_64 program? Is there some dance I need to do in the Visual Studio 2010 settings?
Did a little testing, got VS 2010 SP1 Ultimate on win7 x64, using a 32bit binary to break correctly on HW breakpoints (both with and without SEH). When using a 64 bit binary however, it doesn't trap the single step (and I had to alter a few types just to get it to compile).
Digging a little deeper, it seems to be VS acting weird, cause although it doesn't trap the single step, I can't get it to correctly step over a section of code that will trigger a HW breakpoint.
I have a feeling that the library isn't correctly setting the DR registers under x64, this may be to do changes in SetThreadContext for x64.
Update
Fiddling around a little more, I noticed that the library you are using doesn't suspend the thread before setting or getting the thread context, MSDN says this is a big NO-NO:
You cannot get a valid context for a running thread. Use the SuspendThread function to suspend the thread before calling GetThreadContext.
However, even using another library that does correctly suspend the target thread and executes all its calls without error still doesn't let VS trap the BP, which makes me think that not only is the library you are using buggy, but VS' x64 debugger is buggy as well.
Have you enabled mixed (native & managed) debugging for your project?
I went to project properties->configuration properties->debugger->debug type set to "mixed"
found this answer here:
https://social.msdn.microsoft.com/Forums/windowsserver/en-US/47ebd835-e538-4ff6-8c91-df45bd46d548/vc-express-2012-x64-clr-breakpoint-not-hit-no-executable-associated-static-library?forum=windbg
There is a function named DebugBreak() that you can use to programmatically break your execution under MSVC 2010 but it stop inside of DebugBreak( disassembly code ). So if you want to break just in your code use __asm int 3 this is very simple and work in all intel compatible CPUs.
And one other note use IsDebuggerPresent() before either of DebugBreak() or __asm int 3 to avoid error in runtime( of course you already know that! :) )
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!
When debugging a program in Code::blocks, how do you specify command line arguments to be sent to the program being debugged. I can't find where to set this for the life of me and google searches bring up settings for debugging the compiler itself, rather than programs written in the compiler. It would be a strange thing to leave out.
Thanks,
Tim.
Ah, looking with a visual studio head on. It's not in the project settings dialog but off the project menu:
Project->Set Programs Arguments
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.