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! :) )
Related
I have a .NET Core 2.0 C# program that starts another .NET Core 2.0 C# program. I want to automatically attach the VS 2017 debugger to the sub-process, either as soon as it starts or at a certain point in its execution.
I tried adding a System.Diagnostics.Debugger.Launch call to the sub-process code and this does pop up the VS JIT debugger dialog, but:
If I don't check "Manually choose debugging engines" it debugs only native code. The process is stopped at a breakpoint, as expected, but I cannot debug my C# code.
If I do check it and check "Managed" I still cannot uncheck "Native" - it says "For the debugger to handle the current exception, 'Native' code must be selected." It then starts mixed-mode debugging, but does not enter break mode. If I break manually I can see that the thread that called Debugger.Launch has the following stack trace:
ntdll.dll!ZwWaitForMultipleObjects()
KernelBase.dll!WaitForMultipleObjectsEx()
kernel32.dll!WaitForMultipleObjectsExImplementation()
[Managed to Native Transition]
(my method that called System.Diagnostics.Debugger.Launch)
It's just "stuck" in this method and I cannot step out of this to continue running my managed thread, so this is completely useless.
How do I attach the debugger in such a way that I can stop at a breakpoint, inspect managed variables and then continue?
Debug.Assert is probably the easiest if they own the second process. Assuming that’s available in .NET Core.
You could look here for more information on why their Debugger.Launch is behaving like it does:
https://blogs.msdn.microsoft.com/jmstall/2006/02/16/ifeo-and-managed-debugging/
i coded a big project in c++ that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs after 5 seconds. It just doesn't reply anymore and is tagged as inactive in taskmanager. I tried to analyse the error with the windows debugger tools and application verfier, but i found nothing. Even when I set the "_NO_DEBUG_HEAP=1", the error doesn't occur, it just happens when I start it with ctrl + f5 or outside from visual studio. I'm not even sure if the _NO_DEBUG_HEAP works... Anyone have an idea what could be wrong ?
Any number of things may cause this.
Based on my passed experience, I suggest tackling this by removing code until the behaviour disappears... then determining why removing the code in question corrected the behaviour. (the removed code may not have been the cause, only a catalyst for the symptom)
If I was tasked with taking a quick glance to spot the error, I would think to look for buffer overrun related issues. This type of error has more safeguards in debug than executing a final build. That's just a stab in the dark based on buffer overruns being a common issue that kinda fits the symptom.
-dm
Common things to check:
Are you sure your application is setting any memory used to zero,
if it is assuming the memory has to be zeroed out?
Visual Studio might be initializing the memory given to the
application.
Is all the memory allocated being deallocated?
There are no un-initialized pointers being used?
There are no un-initialized variables being used?
64 bit exe crashing outside visual studio but working inside visual studio
Does the problem only happen on one computer?
You can use check_heap to check the validity of the heap
in the program:
Program crashes only in Release mode outside debugger
You can use the Windows debugging tools to show heap
corruption - there is a tool called "gflags" that comes with the
Microsoft "Standalone Debugging Tools for Windows"
https://msdn.microsoft.com/en-us/windows/hardware/hh852365
This URL shows how to run gflags against your .EXE:
Visual Studio - how to find source of heap corruption errors
I really need to figure out when my Fortran project is reading an element of a vector. I use data breakpoint on a daily basis but I could not find a way to set a data breakpoint when my code access (i.e. read) a memory address, while I always set it for breaking when the address is modified. Is there a way to do this on Visual Studio 2010? (I use intel visual fortran compose XE 2011 as compiler). Or maybe updating to a more recent visual studio?
Just as a note, I saw here that gdb does that Can I set a breakpoint on 'memory access' in GDB?
thanks
A.
Ps: I emaild the guys from GDB and they said its not possible to do it with it.See their answer below:
Hello,
Currently the type of created watchpoint is hardcoded to "write". This is because
Visual Studio has no support for other types of watchpoints (in GUI and infrastructure).
Perhaps it would be possible to enable read watchpoints in the GDB console,
however it also would require a hack, as the console actually works "through"
Visual Studio (it does not pass commands directly to GDB).
I am also not sure whether this feature really works in GDB. GDB has a lot
of commands which have very limited target scope, e.g. they only work
for single threaded programs, or just for Linux and not when using
gdbserver, etc. A read watchpoint looks like a mechanism that is very
platform dependent. Please check if GDB your platform supports read watchpoints.
Also let us know if this feature is critical for you.
Best regards
Some workarounds (except using WinDBG):
Inject a NaN value if it is about a floating point element. And enable trapping of operations with NaN. This will catch not a read, but a first arithmetic operation with the value. Thus copying of the element will be missed, but an attempt to perform an operation will throw an FP exception exposing the place it occurs.
Unmap a memory page with the value. It's very unexact and will react for access to 4Kb of data around the value... But it still may work for some cases. Check description of MapUserPhysicalPages() for Windows, and munmap() for Linux.
You can use Mike Morearty's Hardware Breakpoints.
I have not tested them on Visual Studio 2010, but I have succesfully used it in VS 2008, 2015 and 2017.
int x = 0;
HardwareBreakpoint hb;
hb.Set(&x, sizeof(x), HardwareBreakpoint::Read);
// Some random code.
int y = x; // The breakpoint pauses the execution on this line.
Note that HardwareBreakpoint object must be in the scope while you want that breakpoint to be alive. When it goes out of the scope, the breakpoint will stop functioning.
I have a complex C# project that I ported over from C++ and now I'm in the middle of debugging. Things are working great most of the time but more often than not I have huge problems with Visual Studio and debugger attached to WP7 emulator. For some strange reasons, my debug session is often abruptly terminated while stepping through the code without any indication from VS or any trace left in the Output window.
There are even some cases when a breakpoint is hit and then when I hover over a particular variable, VS simply exits the current debugging session. If I refrain from inspecting the variable contents, nothing happens and VS waits happily forever.
As the app is a memory hog by definition, I am wondering whether I am hitting any debugger / WP7 / emulator limits of any kind. Why would a mouse over variable terminate debugging session? Most of all, why is there no trace of what happened? I am left to wonder whether this is a VS issue or an emulator issue or even an app issue.
What are your computer specs?
I have seen similar problems on computers with low specs, especially computers with low memory.
Try clearing out memory hogs from your PC (CCleaner is a good tool) and running Visual Studio in administrator mode.
I have found this post which has helped me immensely. It appears that having ToString() overrides can sometimes crash the debugging session. I have implemented mine for the sole purpose of having customized value representation of variables/values in the debugger.
After removing all the ToString() overrides I am able to debug normally again. The thing that still puzzles me is the fact that no exceptions are leaked from my ToString() overrides so I wonder why debugger behaves the way it does but at least the problem is solved for now.
I hope this helps someone.
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.