How do you start a debug mode in Virtualbox GUI tool?
I've been playing with VirtualBox implementations of Xubuntu. I'm learning provisioning test boxes with content using both VBoxManage and Vagrant. Unfortunately my boxes work very erratically. I'd like to enable the debug mode in VirtualBox to better understand why the boxes sometimes freeze up.
Current top menu: VirtualBox VM / Machine / View / Input / Devices / Window / Help. I'd like to be able to get to the / Debug / top menu with its selection of Statistics / Command Line / Logging / Show Log as displayed in the VirtualBox Graphical User Input (GUI) tool, [select Virtual Machine --> Settings --> User Interface.]
As I understand it, I'm looking for the Built In Debugger. I've found the instructions, but they don't make sense to me.
The debugger can be enabled in three ways:
Start the VM directly using VirtualBox --startvm, with an additional
--dbg, --debug, or --debug-command-line argument.
Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment
variable to true before launching the VirtualBox process. Setting
these variables (only their presence is checked) is effective even
when the first VirtualBox process is the VM selector window. VMs
subsequently launched from the selector will have the debugger
enabled.
Set the GUI/Dbg/Enabled extra data item to true before launching the
VM. This can be set globally or on a per VM basis.
I know how to start my virtual boxes in two ways. 1) Open the Virtual Box GUI, click on the machine of interest, then start it up. 2) Start the box up from the folder that contains my custom Vagrantfile, then $ vagrant up
.
Its not clear to me from the above link on Virtualbox, how to set up vagrant or VBoxManage or VirtualBox GUI to start up a box with Debug mode enabled (or better yet, enable Debug mode when building a custom box...). I can't believe someone built up a nice GUI then omit the chance to implement Debug into the tool.
Note: I'm using MacOS for my host; I've had best luck using bstoots/xubuntu-16.04-desktop-amd64
as the base for my guest virtual machine box. Anybody been here before? Tips and hints as to how to start a box with debug enabled? Many thanks.
debugging vagrant virtual-machine virtualbox
add a comment |
I've been playing with VirtualBox implementations of Xubuntu. I'm learning provisioning test boxes with content using both VBoxManage and Vagrant. Unfortunately my boxes work very erratically. I'd like to enable the debug mode in VirtualBox to better understand why the boxes sometimes freeze up.
Current top menu: VirtualBox VM / Machine / View / Input / Devices / Window / Help. I'd like to be able to get to the / Debug / top menu with its selection of Statistics / Command Line / Logging / Show Log as displayed in the VirtualBox Graphical User Input (GUI) tool, [select Virtual Machine --> Settings --> User Interface.]
As I understand it, I'm looking for the Built In Debugger. I've found the instructions, but they don't make sense to me.
The debugger can be enabled in three ways:
Start the VM directly using VirtualBox --startvm, with an additional
--dbg, --debug, or --debug-command-line argument.
Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment
variable to true before launching the VirtualBox process. Setting
these variables (only their presence is checked) is effective even
when the first VirtualBox process is the VM selector window. VMs
subsequently launched from the selector will have the debugger
enabled.
Set the GUI/Dbg/Enabled extra data item to true before launching the
VM. This can be set globally or on a per VM basis.
I know how to start my virtual boxes in two ways. 1) Open the Virtual Box GUI, click on the machine of interest, then start it up. 2) Start the box up from the folder that contains my custom Vagrantfile, then $ vagrant up
.
Its not clear to me from the above link on Virtualbox, how to set up vagrant or VBoxManage or VirtualBox GUI to start up a box with Debug mode enabled (or better yet, enable Debug mode when building a custom box...). I can't believe someone built up a nice GUI then omit the chance to implement Debug into the tool.
Note: I'm using MacOS for my host; I've had best luck using bstoots/xubuntu-16.04-desktop-amd64
as the base for my guest virtual machine box. Anybody been here before? Tips and hints as to how to start a box with debug enabled? Many thanks.
debugging vagrant virtual-machine virtualbox
add a comment |
I've been playing with VirtualBox implementations of Xubuntu. I'm learning provisioning test boxes with content using both VBoxManage and Vagrant. Unfortunately my boxes work very erratically. I'd like to enable the debug mode in VirtualBox to better understand why the boxes sometimes freeze up.
Current top menu: VirtualBox VM / Machine / View / Input / Devices / Window / Help. I'd like to be able to get to the / Debug / top menu with its selection of Statistics / Command Line / Logging / Show Log as displayed in the VirtualBox Graphical User Input (GUI) tool, [select Virtual Machine --> Settings --> User Interface.]
As I understand it, I'm looking for the Built In Debugger. I've found the instructions, but they don't make sense to me.
The debugger can be enabled in three ways:
Start the VM directly using VirtualBox --startvm, with an additional
--dbg, --debug, or --debug-command-line argument.
Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment
variable to true before launching the VirtualBox process. Setting
these variables (only their presence is checked) is effective even
when the first VirtualBox process is the VM selector window. VMs
subsequently launched from the selector will have the debugger
enabled.
Set the GUI/Dbg/Enabled extra data item to true before launching the
VM. This can be set globally or on a per VM basis.
I know how to start my virtual boxes in two ways. 1) Open the Virtual Box GUI, click on the machine of interest, then start it up. 2) Start the box up from the folder that contains my custom Vagrantfile, then $ vagrant up
.
Its not clear to me from the above link on Virtualbox, how to set up vagrant or VBoxManage or VirtualBox GUI to start up a box with Debug mode enabled (or better yet, enable Debug mode when building a custom box...). I can't believe someone built up a nice GUI then omit the chance to implement Debug into the tool.
Note: I'm using MacOS for my host; I've had best luck using bstoots/xubuntu-16.04-desktop-amd64
as the base for my guest virtual machine box. Anybody been here before? Tips and hints as to how to start a box with debug enabled? Many thanks.
debugging vagrant virtual-machine virtualbox
I've been playing with VirtualBox implementations of Xubuntu. I'm learning provisioning test boxes with content using both VBoxManage and Vagrant. Unfortunately my boxes work very erratically. I'd like to enable the debug mode in VirtualBox to better understand why the boxes sometimes freeze up.
Current top menu: VirtualBox VM / Machine / View / Input / Devices / Window / Help. I'd like to be able to get to the / Debug / top menu with its selection of Statistics / Command Line / Logging / Show Log as displayed in the VirtualBox Graphical User Input (GUI) tool, [select Virtual Machine --> Settings --> User Interface.]
As I understand it, I'm looking for the Built In Debugger. I've found the instructions, but they don't make sense to me.
The debugger can be enabled in three ways:
Start the VM directly using VirtualBox --startvm, with an additional
--dbg, --debug, or --debug-command-line argument.
Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment
variable to true before launching the VirtualBox process. Setting
these variables (only their presence is checked) is effective even
when the first VirtualBox process is the VM selector window. VMs
subsequently launched from the selector will have the debugger
enabled.
Set the GUI/Dbg/Enabled extra data item to true before launching the
VM. This can be set globally or on a per VM basis.
I know how to start my virtual boxes in two ways. 1) Open the Virtual Box GUI, click on the machine of interest, then start it up. 2) Start the box up from the folder that contains my custom Vagrantfile, then $ vagrant up
.
Its not clear to me from the above link on Virtualbox, how to set up vagrant or VBoxManage or VirtualBox GUI to start up a box with Debug mode enabled (or better yet, enable Debug mode when building a custom box...). I can't believe someone built up a nice GUI then omit the chance to implement Debug into the tool.
Note: I'm using MacOS for my host; I've had best luck using bstoots/xubuntu-16.04-desktop-amd64
as the base for my guest virtual machine box. Anybody been here before? Tips and hints as to how to start a box with debug enabled? Many thanks.
debugging vagrant virtual-machine virtualbox
debugging vagrant virtual-machine virtualbox
asked Mar 19 '18 at 21:45
zipzitzipzit
1,98931636
1,98931636
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:Users%username%.VirtualBoxVirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:Users%username%VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
add a comment |
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:Program FilesOracleVirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
I'm curious... why didn't you just edit your first answer?---(additional edit)---
etc?
– zipzit
Nov 13 '18 at 19:50
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f49372856%2fhow-do-you-start-a-debug-mode-in-virtualbox-gui-tool%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:Users%username%.VirtualBoxVirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:Users%username%VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
add a comment |
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:Users%username%.VirtualBoxVirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:Users%username%VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
add a comment |
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:Users%username%.VirtualBoxVirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:Users%username%VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:Users%username%.VirtualBoxVirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:Users%username%VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
answered Nov 13 '18 at 17:02
Bogdan BaudisBogdan Baudis
613
613
add a comment |
add a comment |
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:Program FilesOracleVirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
I'm curious... why didn't you just edit your first answer?---(additional edit)---
etc?
– zipzit
Nov 13 '18 at 19:50
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
add a comment |
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:Program FilesOracleVirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
I'm curious... why didn't you just edit your first answer?---(additional edit)---
etc?
– zipzit
Nov 13 '18 at 19:50
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
add a comment |
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:Program FilesOracleVirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:Program FilesOracleVirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
edited Nov 13 '18 at 18:16
answered Nov 13 '18 at 18:09
Bogdan BaudisBogdan Baudis
613
613
I'm curious... why didn't you just edit your first answer?---(additional edit)---
etc?
– zipzit
Nov 13 '18 at 19:50
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
add a comment |
I'm curious... why didn't you just edit your first answer?---(additional edit)---
etc?
– zipzit
Nov 13 '18 at 19:50
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
I'm curious... why didn't you just edit your first answer?
---(additional edit)---
etc?– zipzit
Nov 13 '18 at 19:50
I'm curious... why didn't you just edit your first answer?
---(additional edit)---
etc?– zipzit
Nov 13 '18 at 19:50
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
There is more than one school on this ... add, replace .. most of the forums work on the "add" paradigm .. maybe the "replace" is better ... but not obviously so ...
– Bogdan Baudis
Nov 14 '18 at 21:59
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f49372856%2fhow-do-you-start-a-debug-mode-in-virtualbox-gui-tool%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown