Basically, if a conditional breakpoint triggers while you're stepping through some unrelated code on another thread, the debugger will break at the breakpoint regardless of the condition being true or false. This also deletes the implicit breakpoint at the step-over/step-into address, so if you want to continue stepping you have to go back to the address and set an explicit breakpoint.

I checked the behaviour in other debuggers and WinDBG also has this same bug, but Visual Studio and IDA's debugger handle it properly: the condition is evaluated and the debugger only breaks if the condition is true. Additionally, the implicit breakpoint is not destroyed, so continuing will lead to the program properly breaking at the step-over/step-into address.

Repro steps:

• Compile the following program:

#include <thread>
#include <Windows.h>

int main()
{
	auto lambda = []()
		{
			while (true)
			{
				OutputDebugStringA("Hello from the other thread\n");
				Sleep(1200u);
			}
		};

	std::thread workerThread(lambda);

	while (true)
	{
		OutputDebugStringA("Hello from the main thread\n");
		Sleep(3000u);
	}

	workerThread.join();
	return 0;
}

• Run the executable, attach x64dbg.
• Set a normal breakpoint at the Sleep call on the main thread.
• Set a breakpoint with condition "0" at the Sleep call from the worker thread.
• Wait until program breaks at the first breakpoint.
• Step over the Sleep call.
• Observe that the debugger breaks on the second breakpoint, despite the condition being false.