There is no (working) way to invoke a script on a breakpoint right now. But for your thing specifically you can use a ; to separate commands. Note that this doesn't scale nicely, but a command like bp eax; bp ebx should work fine. Another possibility is to write a plugin that does as many commands as you like (possibly in C# using https://github.com/x64dbg/DotX64Dbg)

I just discovered the ; way, it's cool that it works but it's a pain in the ass to work with.
Best I could do is to have a script that runs SetBreakpointCommand, but with each change I need to do the following:

• save script file
• switch to script tab
• reload script
• pause debugged app
• run script
• resume app and go back to cpu tab

If I could do all of the above in one click it would be so much better! Maybe I need to script the script runner

Current breakpoint command just runs a few commands without changing x64dbg to a paused state first, therefore some commands, like "run", could not be used. x64dbg have to properly enter a paused state before starting executing script. This has a big performance penalty. I think we need a separate property for conditional breakpoint where you can specify a label in the script to execute, so x64dbg knows it need to use a slower and different approach to properly handle this. This also means if your script contains no "run" command in this section, then the debuggee will be left in paused state.

Hmm, the ; trick does not seem to work.

The first command gets executed but the remaining ones do not. Am I missing something?

Same thing happens when I use the command box at the bottom of the debugger window as well.

You missed the documentation: https://help.x64dbg.com/en/latest/introduction/ConditionalBreakpoint.html#notes

You should not use commands that can change the running state of the debuggee (such as run) inside the breakpoint command, because these commands are unstable when used here. You can use break condition, command condition or $breakpointcondition instead.

There will be a new option "Script safe breakpoint". When enabled, x64dbg will properly enter a paused state before starting to execute commands, and then the user can use any command.

I think we should consider just making this the default @torusrxxx. The way things are designed currently is only causing confusion... That being said, it's a bit tricky because we'd have to schedule the commands on the command thread?

This way it will be slower, considering all the things that need to do when x64dbg is paused, including updating all GUI views, calling plugin callbacks, sending command to the command thread, etc. Certainly this feature should be disabled when the command is just to set EAX to 0. And don't forget the script will also be responsible to call run afterwards, we can't use break condition anymore (by making x64dbg into paused state the result of break condition is ignored).

Perhaps then it will be better to introduce a way to set a full script in the conditional breakpoint tab? With the recent refactors from #3317 it is possible to set a newline-separated breakpoint command. If the users sets a multi-line script their intention was probably to schedule that script on a different thread (vs modifying the $breakpointcondition variable, which seems to be rather less likely scenario).

If possible, I just want to avoid adding more checkboxes with niche meanings that will only confuse the users...