1

I'm working with Visual C++ installed on a Windows Virtual Machine (VMWare). As there is no way to make the debugger stop at breakpoints, I wondered if there was a problem with the breakpoints mechanism itself, maybe due to the fact I'm working in a VM (?). ___asm int 3 works fine, and I can debug through the code and Disassembly Window, reaching my breakpoints. Is there a way to check if they are inserted correctly?

here the source code window during debugging

code

and here the Disassembly window

disassembly

It breaks at __asm int 3;, but it doesn't at. double myDouble=6;. Is there a way to understand if the breakpoint is actually placed there?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
hank7v
  • 31
  • 7

1 Answers1

0

If you want to just check if your breakpoints are in expected places you can use DebugBreak and __debugbreak.

You can call the DebugBreak Win32 function or the __debugbreak intrinsic at any point in your code. DebugBreak and __debugbreak have the same effect as setting a breakpoint at that location.

To answer your comment:

__asm int 3 now results in native code generation for the function. If you want a function to cause a break point in your code and if you want that function compiled to MSIL, use __debugbreak.

So, it might depend on if you write managed or unmanaged code.

Yola
  • 18,496
  • 11
  • 65
  • 106
  • Hi Yola, is it different from __asm? My problem is that the debugger doesn't stop at the breakpoints. I suspect the breakpoints are not truly added. – hank7v Feb 26 '18 at 17:16
  • This is a C++ question. Does MSVC even give you the option of compiling C++ into managed / non-native code? – Peter Cordes Feb 27 '18 at 05:34
  • @PeterCordes well i've never wrote a line of managed C++, but i saw a lot of discussions on the topic like this one [Difference between managed c++ and c++](https://stackoverflow.com/questions/114238/difference-between-managed-c-and-c) – Yola Feb 27 '18 at 05:39
  • Ok, according to that, "managed C++" is a different language, and unless someone specifically says they're writing "managed C++", you should assume it's regular C++ that compiles to machine code. I'd still recommend using a `__debugbreak` intrinsic instead of inline asm, because it probably compiles to the same thing. – Peter Cordes Feb 27 '18 at 05:49
  • @PeterCordes it's never wrong to ask someone such a question, because people (me as well) often forget to mention important things. – Yola Feb 27 '18 at 05:53
  • Thanks for putting the pictures inline @PeterCordes (I could not, having not 10 reputation points). I see maybe the discussion got beyond my level of comprehension. Just in case you may help (@Yola?), I don't understand why __asm as well DebugMask() work (debugger breaks) and my breakpoints don't. As I'm quite sure my debug settings are correct, I have the doubt it is due to some bug. Is there a way to check if I'm true? – hank7v Feb 27 '18 at 13:54
  • @hank7v: The low-level stuff that debuggers use to set breakpoints should all still work inside a VirtualBox VM. Did you try making a debug build with optimization disabled, in case Visual Studio has a problem trying to set a breakpoint on a source line that was "optimized away"? Or maybe if you set a breakpoint inside a function, it doesn't catch inlined copies of that function? I doubt Visual Studio actually has bugs like that, but I don't use it so it wouldn't hurt to try the most standard thing, and debug a debug build if you weren't already doing that. – Peter Cordes Feb 27 '18 at 17:46
  • Thanks, @Peter, yes I disabled optimisation, actually I use exactly the same config in another VM works fine. same operating system (XP) same VS (Visual C++ 6.0). The only different things are the EXE calling them DLL and few environment variables. I understand it is a naive question. But I supposed DebugBreak worked as a breakpoint, thus I don't understand why in the same position it works and breakpoints not. – hank7v Feb 27 '18 at 18:24
  • 1
    I solved the issue. It was due to a bug, but as you guessed Peter, not in VS but in the framework calling the DLL. It created a copy of the DLL process that interfered with the DEBUGGING (most likely, if I learned well from this adventure, by creating ambiguity). Nevertheless, I would be happy to understand why the DebugBreak() and ___asm were not affected. @Yola, you mentioned they are like breakpoints. What is the difference indeed? – hank7v Mar 01 '18 at 15:55
  • @hank7v i don't know the difference, you can first answer this post with your solution and then create another question. – Yola Mar 02 '18 at 01:14
  • Hi Yola. If you look at my post, you see that it is already the question I asked for indeed, although not so explicitly, I admit... I don't think my solution is the answer to my question, as I just discovered a bug in the EXE executed by the debugger and calling the DLL, but I'm not able to say why the bug affects the breakpoints and not the `___asm int 3;` and I was not able to disentangle a possible VS bug from my EXE bug. But you may be right that posting a new question more explicitly addressing the point may be the right thing to do. Thanks a lot for your help. – hank7v Mar 03 '18 at 08:20