Guest runs very slowly under kernel debugger.

[x64]

Host: Windows 7 x64.
Guest: Windows XP x86 SP3.
Kernel Debugger: WinDbg 6.12.0002.633 x64.

A boot up process takes much more time if guest has been restarted under the kernel debugger. First time I saw this bug in version 3.2.2, but in version 3.2.0 everything is ok. Unfortunately, this bug is actual up to this moment, it can be reproduced in the latest 3.2.6 version.

[x64]

I especially want to mention that sometimes when my guest is under kernel-mode debugger, it is not start at all. This makes any newest versions of VirtualBox completely unusable for me.

[Frank Mehnert]

How do you connect your guest with the kernel debugger? Using the serial interface?

[x64]

Yes, using COM-port emulation via pipe:

Port Number: COM1.
Port Mode: Host Pipe.
Create Pipe: on.
Port/File Path: \.\pipe\debug.

[sunlover]

x64, the following command can help to make the guest faster under debugger: vboxmanage setextradata VMNAME "VBoxInternal/Devices/serial/0/Config/YieldOnLSRRead" 1 Make sure that the VM is not running when this command is executed.

[x64]

x64, the following command can help to make the guest faster under debugger:

Thank you, but in version 3.2.0 everything worked fine w/out any hacks. I just want this bug to be fixed in usual way by the VirtualBox developers.

[Frank Mehnert]

Replying to x64:

Thank you, but in version 3.2.0 everything worked fine w/out any hacks. I just want this bug to be fixed in usual way by the VirtualBox developers.

You probably think that it is sufficient to go back to the 3.2.0 code to fix this bug but it's not that easy. We had many reports that the UART emulation drops some characters during the transfer of bursts. The fix in 3.2.x addresses this issue but has the side effect that under certain circumstances the transfer speed is decreased. So finding the right fix (preventing data loss but don't decrease the transfer speed) requires some trial and error cycles.

[x64]

You probably think...

All that I think is I can't use VirtualBox at all due to this issue. And what should I do in this situation if I want to use any newest versions of the product? Tell me, please.

[Frank Mehnert]

I think you can decide this very well yourself. All I did was to add some more information explaining why a proper fix will take longer than you probably expect. But looking at your last comment it seems to me that you don't care.

[x64]

All I did was...

Well, apparently, you can't offer any solution and I should wait for fix indefinitely long time.

...you don't care.

I am user of VirtualBox, but not developer, and I need not care of technical details of the product's implementation. Please, always keep it in mind.

[Frank Mehnert]

Replying to x64:

...you don't care.

I am user of VirtualBox, but not developer, and I need not care of technical details of the product's implementation. Please, always keep it in mind.

I already explained that we are trying to fix this problem but it's a bit more difficult than a one-liner. No, it will not take an indefinitely long time but the fix will not be available within the next days and perhaps not for the next maintenance release.

Please keep in mind that:

• Some users actually DO care about the technical details. So just ignore such information if you don't need / understand it.
• The source code is freely available so everyone is free to send a proper patch. But right, you already said that you don't care the technical details, so please forgive me.
• Our free support for non-paying customers is limited and will be done on a best-effort base. And the more time we have to spend answering such rants the less time we have for the real work.

[Frank Mehnert]

The serial device emulation was changed with VBox 4.0.4, before that fix it was loosing characters under certain circumstances. If the serial port emulation is not fast enough (115200 are often not sufficient), use VirtualKD or something like that.