Error setting hardware breakpoint (bpnew)!

[XriChee]

Hi mrexodia,
I observe "Error setting hardware breakpoint (bpnew)!" using my own script inspired by something I found on internet.

I search the memory for specific content
findallmem 0x10000,374438423933393633384545
Then iterating a loop trying to set HWBP to all (max 4) locations found in memory.

This happens at instruction:
bph addr,"rw",1

x64dbg (Apr 11 2024)

This happens sometimes (periods when it works as it should and then it does not work). So far I'm unable to catch what is the trigger.

However, it is interesting that following the address in Dump and setting the HW BP manually (Dump -> right click -> Breakpoint -> Hardware, Access -> Byte) sets the BP correctly

Kindly any idea how to work it around or how to fix this behavior?

[mrexodia]

There are two reasons it could technically fail:

1. The memory cannot be read (seems unlikely considering it found a pattern match there)
2. The breakpoint already existed (actually impossible, because this is checked in the bph command implementation right before creating it)

Is the executable running when this happens?

[XriChee]

The executable is paused. I scan the memory for the pattern and expect to set the BPH's. After that I continue running the debuggee.

1. Very unlikely, because it is able to find pattern (all existing patterns)
2. In case the BP is already existing, the message is different "Hardware breakpoint already set!"

• All breakpoints have been deleted, either manually or BPH

4. There is different behavior of "bph" instruction in script and setting it by mouse (Dump -> right click -> Breakpoint -> Hardware, Access -> Byte)
5. Right now I noticed interesting behavior - the VM (VMware Workstation 15 Player, 15.5.0 build-14665864, Windows 7 SP1 ) has been hibernated since Friday. Before hibernation (hibernated with debug session in progress) I experienced problems, now after turning it on again

• I set one BPH manually
• started my script - 4 pattern occurences found
  • observed:
    • 1 msg "Hardware breakpoint already set!"
    • all other 3 breakpoints are set correctly

6. It seems to me like different handling of BPH's when setting them manually vs. in script. Maybe setting it manually (seems like fixed after setting it manually, not deleting manually) cleans some counter and afterwards script runs fine?

[XriChee]

Another interesting behavior - after a restart of debuggee trying to manually delete existing BPH from previous session:

[XriChee]

Hi again.
Isn't it possible that some BPH's remain in the dd64 file after the restart although they make no sense (they cannot exist)? The Debug registers are filled, but such BPH's don't really exist. Afterwards when trying to delete such BPH there is a check if BPH exists. Because it doesn't exist it cannot be deleted. Not sure how would be possible to fill DRx with not existing BPH.

[mrexodia]

Yeah it could be that the bug is related to this. Did you confirm that the bug reproduces after a restart when such a hardware breakpoint wasn't deleted from the database? You can use the dbclear command (+ restart) to fully clear the database.

It seems to me like different handling of BPH's when setting them manually vs. in script. Maybe setting it manually (seems like fixed after setting it manually, not deleting manually) cleans some counter and afterwards script runs fine?

x64dbg/src/gui/Src/Gui/CPUDump.cpp

Lines 118 to 129 in f518e50

	hardwareAccessMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_byte"), tr("&Byte"), "bphws $, r, 1"));
	hardwareAccessMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_word"), tr("&Word"), "bphws $, r, 2"));
	hardwareAccessMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_dword"), tr("&Dword"), "bphws $, r, 4"));
	#ifdef _WIN64
	hardwareAccessMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_qword"), tr("&Qword"), "bphws $, r, 8"));
	#endif //_WIN64
	hardwareWriteMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_byte"), tr("&Byte"), "bphws $, w, 1"));
	hardwareWriteMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_word"), tr("&Word"), "bphws $, w, 2"));
	hardwareWriteMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_dword"), tr("&Dword"), "bphws $, w, 4"));
	#ifdef _WIN64
	hardwareWriteMenu->addAction(mCommonActions->makeCommandAction(DIcon("breakpoint_qword"), tr("&Qword"), "bphws $, w, 8"));
	#endif //_WIN64

As you can see, the command executed in the dump menu is bphws <address>, rw, 1 which is the same as your script. In general almost all GUI actions are just executing commands in the background.

It would be helpful for me if we could craft a test executable that triggers this bug. Also could you run minidump hwbp-bug.dmp and upload the hwbp-bug.dmp (in the same folder as x64dbg.exe)? This will help to rule out any strange memory regions that might cause ReadProcessMemory to fail...