Stepping behaviour can get hijacked by breakpoints

[ynwarcs]

Basically, if a breakpoint triggers while you're stepping through some unrelated code, the debugger will:
a) break at the breakpoint, regardless of whether its condition is evaluated as true or false.
b) "hijack" the stepping behaviour, i.e. the debugger will no longer break on the next instruction of the step operation.

Repro steps:

• Compile the following program:

#include <Windows.h>

void foo()
{
	Sleep(3000u);
}

int main()
{
	while (true)
	{
		foo();
	}
	return 0;
}

• Run the executable, attach WinDbg to it.
• Set a normal breakpoint at the instruction that calls foo in main.
• Set a breakpoint with /w "false" at the instruction that calls Sleep in foo.
• Wait until program breaks at the first breakpoint.
• Step over the instruction.
• Observe that the debugger breaks on the second breakpoint, despite the condition being false. Additionally, the debugger doesn't respect the step operation and won't break on the instruction following the foo call if you resume execution.

[wmessmer-msft]

Thank you for the report. It would appear that 'gc' (go w/ continuation of the previous operation) is broken if a different breakpoint is hit during a step operation. That also affects "/w" conditional breakpoints. This is now fixed internally and should be in the next external debugger release.