Windows debugger - stopping at the wrong place

[XVilka]

Environment information

• Operating System: Windows 10 x86_64
• Cutter version: 2.1.0
• Obtained from:
  • [ ] Built from source
  • [x] Downloaded release from Cutter website or GitHub
  • [ ] Distribution repository
• File format: PE

Describe the bug

Failure to toggle a breakpoint and stopping somewhere else instead

0x7ff92da006b1      jmp 0x7ff92da006b3
0x7ff92da006b3      add rsp, 0x38
0x7ff92da006b7      ret
0x7ff92da006b8      int3
0x7ff92da006b9      int3
0x7ff92da006ba      int3
0x7ff92da006bb      int3
0x7ff92da006bc      int3
0x7ff92da006bd      int3
0x7ff92da006be      int3
0x7ff92da006bf      int3
0x7ff92da006c0      mov qword [rsp + 0x10], rbx
0x7ff92da006c5      mov qword [rsp + 0x18], rsi
0x7ff92da006ca      push rbp

To Reproduce

Steps to reproduce the behavior:

1. Open C:\Windows\System32\calc.exe:

2. Set a breakpoint on some function:

3. Press "Continue"
4. Observe that Cutter/Rizin stopped at this (obviously wrong) place:

Expected behavior

Breakpoint reaches or at least it doesn't stop at this particular place

[XVilka]

@GustavoLCR since you are the Windows expert, could you please take a look?

[GustavoLCR]

That's the loader breakpoint (LdrpDoDebuggerBreak). Cutter should probably have a way to tell the user an exception happened (in this case, a breakpoint that wasn't set by the user)

[ITAYC0HEN]

I think it is printed to the console. Another click on Continue should stop at the right place (it's common in windows Debugger. Usually, debuggers have the option to disable such breakpoints. Se our debugger specifications)