Hardware breakpoints don't work in Virtualbox

Being worked on at the moment, but will not show up until after 1.6.2.

Replying to sandervl73:

Being worked on at the moment, but will not show up until after 1.6.2.

Anything on this? Doesn't work in 1.6.4 Thx.

hi guys , virtualbox is the more user friendly virtual machine , for use , configuration and installation under linux. but with that lack you disappoint all a community of driver developers and reverse engineers.we are waiting for this more than one year now !!!!!

Yelling loud any writing dozens of exclamation marks does not help. Where did you attach the patch to fix that bug? The VirtualBox source code is freely available.

Here are files for testing this issue

---

Where did you attach the patch to fix that bug? The VirtualBox source code is freely available.

Not everyone can spend enough time to explore the source of VirtualBox to fix that bug. So many of them choose VMware instead VirtualBox solely because of this problem.

I've implemented it for VT-x and AMD-V, but haven't had time to test it yet. Hopefully later this week.

Successfully tested with windbg (kernel debugging session). Code is already in SVN.

Replying to marius_mtm:

It seems that doesn't work setting hardware breakpoints in Virtualbox (Olly Debugger).

What does "don't work" means? I'm trying to figure out if this is the same problem I'm seeing.

With ddd/gdb, when it hits a breakpoint it (sometimes? always?) causes the host and guest to lock hard. System completely locks up. Cannot CTRL+ALT+DEL, must physically reboot the entire system.

I'm attempting to debug a simple C++ app on my Debian Etch-64bit guest. Host is Ubuntu 8.04-64bit. VB is 2.0.2.

Anyway, the problem is fixed with the next major release (2.1, not 2.0.4).

Replying to frank:

Anyway, the problem is fixed with the next major release (2.1, not 2.0.4).

That's just the things -- this problem, or a different one that I'm seeing? At this point I cannot confirm whether or not the problem I'm seeing is the same thing, or something else.

Replying to frank:

Anyway, the problem is fixed with the next major release (2.1, not 2.0.4).

This is causing me lots of pain. (The inability to debug my C++ applications.) Do we know approximately when VB 2.1 is scheduled to be released? Or is there a workaround that can be applied to VB 2.0.4?

Fixed in 2.1 for VT-x and AMD-V.

Replying to sandervl73:

Fixed in 2.1 for VT-x and AMD-V.

And what about processors without hardware virtualization?

Still not work to me, windows xp sp3 host, and windows 2003 RC2 sp2 guest, set "ba" command on windbg but doesn't work, vmware and host are work fine.

netip: with or without VT-x/AMD-V? I have tried it myself and it worked.

No response, closing.

Actually this is still valid. Hardware breakpoints don't work with software virtualization.

I can confirm this problem. VT-x not enabled (actually even not available).

I can also confirm this problem. Hardware breakpoints used to work normally until I enabled VT-x in the BIOS.

Furthermore, what seems to be happening is that the value of the Dr6 register is corrupted, so debuggers receive the corresponding debug event through the Win32 API, but they can't relate it to any of their breakpoints. At least that's what's happening to me right now.

In my machine the value of Dr6 is always 0xffff4ff0 no matter what breakpoint is hit. This is clearly wrong since at least one of the four low order bits of the register should be set when a hardware breakpoint is hit, and in my experience all other bits are always cleared (see the Wikipedia for further reference).

I forgot to mention, VT-x is enabled in the BIOS but disabled for the virtual machine I'm using.

I can verify this, Olly refuses to break on any hardware breakpoint, regardless of whether VT-x is enabled or not, with Vista as host and guest.

Do you have a chance to test it on XP?

I have XP (32 bits) as guest and Ubuntu 8.11 (64 bits) as host.

Sorry, I read "can't" instead of "can", my bad :P

MarioVilas?: I don't know how you come to your DR6 conclusion, but access breakpoints hit in windbg (kernel debugger) show up in DR6. Just checked again myself.

Why don't you first attach your VBox.log to prove that VT-x is indeed turned on?

It seems to work fine with both Ubuntu host/Vista guest and Ubuntu host/XP guest. I haven't tried Vista host/XP guest yet though.

Also keep in mind that hardware breakpoints are a scarce resource, so debuggers tend not to use them for code breakpoints. They just insert 'int 3's. I had to force windbg to use them (ba e 1 address).

I'm afraid I could no longer reproduce that weird DR6 behavior :( however hardware breakpoints are still not working for me.

I'm attaching my VBox.log, it says nothing about VT-x (when it was disabled, I used to see a line saying "No VT-x or AMD-V CPU extension found. Reason VERR_VMX_MSR_LOCKED_OR_DISABLED"). The GUI shows this:

Base Memory: 512 MB Processor(s): 1 Boot Order: Floppy, CD/DVD-ROM, Hard Disk VT-x/AMD-V: Enabled Nested Paging: Disabled