Visual Studio 2008 dialog

[foxmuldr]

Is there a way to stop the Visual Studio 2008 (and hopefully 2005 and 2003) dialog which reads "foo.exe has triggered a breakpoint", then with buttons "Break" and "Continue".

I want it to always break.

Anybody know how?

[Zerkei]

Is there a way to stop the Visual Studio 2008 (and hopefully 2005 and 2003) dialog which reads "foo.exe has triggered a breakpoint", then with buttons "Break" and "Continue".

I want it to always break.

Anybody know how?

Can you post a little bit of your code? i don't understand the question that well.

[WingedPanther]

I think he wants to configure the debugger to always break.

[Zerkei]

I think he wants to configure the debugger to always break.

that's what i was guessing but i wasn't sure.

[foxmuldr]

int main(int argc, char* argv[])
{
_asm int 3;
return(0);
}

Compile, and press F5 to run. When it hits the "_asm int 3" line it will say "foo.exe has triggered a breakpoint" in a dialog box. I'd like it to just stop at that line of code with the instruction pointer right there rather than making me navigate through the dialog box before continuing.

The "INT 3" assembly instruction is a built-into-all-x86 instruction set debugger interrupt. It is a single-byte opcode back from the days of assembly, of 0xCC. It's the reason why all of your memory variables in "debug" (not release) mode are initialized to 0xCC or some multiple of 0xCDCD (which is it's two-byte cousin), instead of 0x00 as in release mode.

It is extremely useful for ALWAYS causing a debugger breakpoint, regardless of the ones set by VS (which may be lost by context), and also from external code that may not be known at launch-time, but is dynamically loaded through program execution.

It can also be replaced by the assembly instruction "NOP", or "no operation", which doesn't do anything, but is a single-byte placeholder of 0x90. To remove that "_asm int 3" opcode of 0xcc, show cs:eip (or cs:rip) in a memory window, then replace the instruction byte with 0x90, and that breakpoint goes away. (By the way, this how the debugger today handles single-step debugging through compiled code. In the old days of assembly when one line of code meant one instruction executed, the single-step "INT 1" interrupt was used. However, when today you can have many lines of assembly executing a single line of C++ or other language code, the debugger inserts a 0xCC byte at the start of the next high-level-language instruction's assembly code, then when trapped back to the debugger, it replaces 0xCC with whatever should've gone there. Very powerful, but very low-level -- often too low-level for many modern "developers".)

Microsoft makes this valuable feature difficult to use because they require extra mouse navigation and clicking and is very annoying.

I've tried adding the unhandled exception thrown to the Exceptions list, but that doesn't fix it.

- Rick

[Zerkei]

int main(int argc, char* argv[])
{
_asm int 3;
return(0);
}

Compile, and press F5 to run. When it hits the "_asm int 3" line it will say "foo.exe has triggered a breakpoint" in a dialog box. I'd like it to just stop at that line of code with the instruction pointer right there rather than making me navigate through the dialog box before continuing.

The "INT 3" assembly instruction is a built-into-all-x86 instruction set debugger interrupt. It is a single-byte opcode back from the days of assembly, of 0xCC. It's the reason why all of your memory variables in "debug" (not release) mode are initialized to 0xCC or some multiple of 0xCDCD (which is it's two-byte cousin), instead of 0x00 as in release mode.

It is extremely useful for ALWAYS causing a debugger breakpoint, regardless of the ones set by VS (which may be lost by context), and also from external code that may not be known at launch-time, but is dynamically loaded through program execution.

It can also be replaced by the assembly instruction "NOP", or "no operation", which doesn't do anything, but is a single-byte placeholder of 0x90. To remove that "_asm int 3" opcode of 0xcc, show cs:eip (or cs:rip) in a memory window, then replace the instruction byte with 0x90, and that breakpoint goes away. (By the way, this how the debugger today handles single-step debugging through compiled code. In the old days of assembly when one line of code meant one instruction executed, the single-step "INT 1" interrupt was used. However, when today you can have many lines of assembly executing a single line of C++ or other language code, the debugger inserts a 0xCC byte at the start of the next high-level-language instruction's assembly code, then when trapped back to the debugger, it replaces 0xCC with whatever should've gone there. Very powerful, but very low-level -- often too low-level for many modern "developers".)

Microsoft makes this valuable feature difficult to use because they require extra mouse navigation and clicking and is very annoying.

I've tried adding the unhandled exception thrown to the Exceptions list, but that doesn't fix it.

- Rick

I'm not sure, since i don't program in C++ but vb.net.
In vb.net you can just click the line in the GUI and it will make a breakpoint and highlight it in red, or at least i read so.

[foxmuldr]

I'm not sure, since i don't program in C++ but vb.net.
In vb.net you can just click the line in the GUI and it will make a breakpoint and highlight it in red, or at least i read so.

You can do that in C++ as well, but when you are loading external modules which are not known in advance, the INT 3 serves well.

We're losing a lot with this generation of developers (I'm 40 yrs old). We're being flooded with developers who have never had to use lower-level tools to write code, or never had to use a command line, or never had to step through non-graphical debuggers, etc. When you use toolsets, you lose something in your mind that is there when you don't use them. It's the visualization of the state for what it is, rather than what's presented to you.

Toolsets limit imagination and problem-solving abilities, whereas understanding the underlying architecture (at least to some degree), fosters the ability to tackle any problem, even ones for which there isn't already an open-source project on SourceForge that can be copied.

- Rick