Application Error when opening Optical Drives list

[krypto]

Host is Windows 10 64-bit, tested on two different computers and the crash seems to be quite easy to reproduce and fix.

So if you try opening the list of optical drives when a virtual machine is running (at least a windows virtual machine) when this bug is active, you'll get the following error:

Code: Select all

VirtualBoxVM: VirtualBoxVM.exe - Application Error
The instruction at (random address) referenced memory at 0x0000000000000008. The memory could not be read.
Click on OK to terminate the program

Even if you're not running a VM, the list of optical drives will open extremely slowly.

This has been reported as a ticket a while back virtualbox(dot)org/ticket/18388 (can't post links yet)

The reason this happens, is because there is one or more entries in the GUI/RecentListCD that are unreachable, such as images from a network drive. You can't use VirtualBox itself to delete the invalid entries from that list, as VirtualBox requires the image locations to be accessible for it to be able to display and remove them from the recent images list.

The solution is to open up %HOMEPATH%\.VirtualBox
Edit (or delete) VirtualBox.xml and remove the invalid entries manually from the ExtraDataItem name="GUI/RecentListCD" line.

To reproduce this bug, just add a bad entry to the list, eg. <ExtraDataItem name="GUI/RecentListCD" value="\\192.168.0.257\Folder\Image.iso"/> <ExtraDataItem name="GUI/RecentListCD" value="\\192.168.0.254\Folder\Image.iso"/>, start your virtual machine and while it's running, open up the Devices -> Optical Drives -list. The VM will hang and you'll eventually get the error message.

EDIT: IP address must be possible, windows will not even attempt a connection to an impossible IP address.

[mpack]

I don't reproduce that here. I added your bad network ISO path to my recentcd list (Win10 1909 Pro 64bit host), started a VM, went to Devices|Optical Drives|list... and the bad file was not listed. No hang, not even a pause.

IMHO apparant hangs are usually just the Windows host taking a long time to decide that a network connection it used to have doesn't exist any more. Crashes in file selection dialogs are caused by third party (not Windows native) host drivers which like to filter drive accesses somehow, e.g. AV related. If your host has anything other than Windows Defender AV installed then I'd treat it with suspicion.

[krypto]

Both computers are running fresh installations of Windows 10 Pro x64 1909 build 18363.752 with just Windows Defender, one from SSD and one from M.2 drive. Guest OS needs to be booted up, otherwise the VM will not crash and will instead just hang for a minute or two.

The missing files are not listed. Only if the network path is available/the files are found will they be listed. That's also the reason why they can't be removed with the VirtualBox GUI. You also need to close all instances of VirtualBox before you make any modifications to the xml, otherwise it will not use those entries as stated in the header of the xml.

Code: Select all

<!--
** DO NOT EDIT THIS FILE.
** If you make changes to this file while any VirtualBox related application
** is running, your changes will be overwritten later, without taking effect.
** Use VBoxManage or the VirtualBox Manager GUI to make changes.
-->

[mpack]

You also need to close all instances of VirtualBox before you make any modifications to the xml, otherwise it will not use those entries as stated in the header of the xml.

Um. I've been using VirtualBox for a wee while now, so I'm quite familiar with such things. Note my post count and join date on the right.

[krypto]

I realize that, however this forum and posts will be read by other people who might not realize that they need to actually close VirtualBox before the changes take effect. Not to mention that even a "power user" might not take such things into consideration since messing with xml files manually isn't what one would normally do.

I used the network address as an example, but it might be that a clearly faulty IP could be downright rejected by the router (or in this case Windows). If you wish to reproduce the bug, it would probably be best to use an address that's not in use, but could be part of the local network.

EDIT: When I say "you", I am refererring to the reader, not you personally.
EDIT2: Yeah, figured that there was something wrong with the IP. Fixed the OP. IP can be anything, as long as it's not in use and doesn't respond.

[fth0]

The crash happens inside QT5WidgetsVBox.dll, which is a VirtualBox specific GUI component. I can reproduce the crash often, but not always, when using the mouse to enter the submenu Device > Optical Drives. When entering the submenu with the keyboard instead, and not touching the mouse afterwards, the crash doesn't occur. Maybe it depends on the mouse movements after entering the submenu.

When entering the submenu Device > Optical Drives, my Windows host sends several groups of ARP requests to resolve the IP address to a corresponding MAC address, for a total time of about 30 seconds. Afterwards, the submenu is either displayed, or the crash happens. My Windows host usually sends 3 ARP requests with 1 second intervals in between, so the 30 seconds seem to stem from a higher layer protocol (probably SMB/CIFS).

the crash seems to be quite easy to [...] fix

Well, then fix it and propose the patch in the ticket.

Edit: If I use an IP address that exists, but rejects TCP port 445 (SMB/CIFS), the submenu appears after about 12 seconds, but the crash only happens very rarely, so that does not reduce the time to reproduce the crash. Additionally, the submenu is cached for about 30 seconds, so after a failed reproduction attempt one has to wait 30 seconds.

[krypto]

Well, then fix it and propose the patch in the ticket.

The "fix" is manually editing the xml file so that VBox doesn't crash anymore