VirtualBox

Ticket #11426 (new defect)

Opened 15 months ago

Last modified 5 weeks ago

VBox 4.2.x crash QtGuiVBox4.dll 4.7.3.0 and MSVCR100.dll 10.0.40219.1

Reported by: Ady Owned by:
Priority: major Component: other
Version: VirtualBox 4.2.6 Keywords: QtGuiVBox4.dll MSVCR100.dll
Cc: Guest type: other
Host type: Windows

Description

I've been using VBox 4.1.x without big issues. Every time I try uninstalling v.4.1.22 so to update/upgrade to VBox v.4.2.x (every time there is a new VBox 4.2.x update), I get crashes, so I have to uninstall and downgrade back to v.4.1.22.

In most (if not all) cases, VBox manager is the one crashing, not the VM. In fact, I have seen the host OS, Vista Home Basic x32 with SP2 and all Windows Updates, reporting the crash of VBox manager while the VM is still working, and I am able to finish my session in the guest. Then I don't have any choice but to close VBox (or close and send info to MS).

When I downgrade to VBox 4.1.22, I keep my VMs (which are located in the same physical HDD but in a different partition than the VBox manager program). So when I re-install v.4.1.22, I can use the same exact VMs as with v.4.2.x, and there are no crashes.

I have seen other forum topics and bug tickets regarding QtGuiVBox4.dll and/or MSVCR100.dll, but they are either (too) old or seem to me not exactly related to the behavior I am seeing with VBox 4.2.x.

I have also tried with less RAM assigned to a VM, and with different types of guests (from FreeDOS to several Linux LiveCDs and to Linux installations as guests), and the crashes occur almost always.

If there is a specific preference or setting I should be changing or testing, please let me know.

I have also been posting reports at  https://forums.virtualbox.org/viewtopic.php?f=6&t=51889

Maybe the following info might be useful, as it repeats itself (specially the one about QtGuiVBox4.dll):

Product
Oracle VM VirtualBox Manager

Problem
Stopped working

Date
2013Jan26 13:26 PM

Status
Report Sent

Problem signature
Problem Event Name:	APPCRASH
Application Name:	VirtualBox.exe
Application Version:	4.2.6.0
Application Timestamp:	50d1d0ed
Fault Module Name:	QtGuiVBox4.dll
Fault Module Version:	4.7.3.0
Fault Module Timestamp:	50085702
Exception Code:	c0000005
Exception Offset:	0016bee3
OS Version:	6.0.6002.2.2.0.768.2
Locale ID:	1033
Additional Information 1:	f61b
Additional Information 2:	2eef8746f809bffc851f433fa3a47dc3
Additional Information 3:	5513
Additional Information 4:	9d9ceca6bad9b1aad2812fa32f91fde9

Product
Oracle VM VirtualBox Manager

Problem
Stopped working

Date
2013Jan25 19:22 PM

Status
Report Sent

Problem signature
Problem Event Name:	APPCRASH
Application Name:	VirtualBox.exe
Application Version:	4.2.6.0
Application Timestamp:	50d1d0ed
Fault Module Name:	MSVCR100.dll
Fault Module Version:	10.0.40219.1
Fault Module Timestamp:	4d5f0c22
Exception Code:	c0000005
Exception Offset:	00010a40
OS Version:	6.0.6002.2.2.0.768.2
Locale ID:	1033
Additional Information 1:	5bc5
Additional Information 2:	40f9f5a8af0ca8da6f1b3003e39b55c1
Additional Information 3:	0e1d
Additional Information 4:	563fa9434bb661b960ec2f78bcc92833

And, as said, when going back to VBox 4.1.22 each time, there are no crashes. They re-appear every time I update VBox to a new v4.2 release.

I'm attaching VBox logs.

Please advice.

TIA, Ady.

Attachments

VBoxlogs.zip Download (61.0 KB) - added by Ady 15 months ago.
4 VBox logs from the same VM

Change History

Changed 15 months ago by Ady

4 VBox logs from the same VM

comment:1 Changed 12 months ago by Al

Hi,

I also have seen crashes reported in QtGuiVBox4.dll on various releases (4.2.8-83876, 4.2.10-84105) and most recently 4.2.12-84980 on Windows 7 x64.

It seems to happen when I shutdown an VM instance and the focus returns to the Oracle Virtualbox Manager. It also seems that I can prevent the crash by having another window open in front of Virtualbox Manager so the focus returns to the other application rather than Virtualbox manager.

Al

Problem signature:

Problem Event Name: APPCRASH Application Name: VirtualBox.exe Application Version: 4.2.12.0 Application Timestamp: 5167d6dc Fault Module Name: QtGuiVBox4.dll Fault Module Version: 4.7.3.0 Fault Module Timestamp: 50085ba6 Exception Code: c0000005 Exception Offset: 000000000018c06c OS Version: 6.1.7601.2.1.0.256.48 Locale ID: 1033 Additional Information 1: 1d98 Additional Information 2: 1d985baa09ac61a81304e07bb5997ab0 Additional Information 3: 3d8e Additional Information 4: 3d8e1ffc3b70f55abddd7ed544a20221

comment:2 Changed 12 months ago by Al

Hi,

I disabled the "Preview" window on "Oracle VM VirtualBox Manager" and that seems to have stopped the crashes.

Al

comment:3 Changed 12 months ago by Dsen

Hello.

Al, thanks for you report.
It may be related or not to the thing Ady observing, but at least I know now there is something crashing in VM preview.

Ady, thanks for your report too.
I need any clues about how to reproduce the issue or at least about when VBox Manager crash does happens. I mean something about is it happens only on VM starting, shutdown, power off, settings dialog open, etc. And does is happens if all VMs are powered off or only when some VM(s) is active.
Also, could you please check if the disabling VM preview section in VBox Manager details pane (right side of VBox manager) helps in your case (you can disable it through the context-menu).
Thanks in advance!

comment:4 Changed 11 months ago by JHH

I disabled the VM Preview and that resolved the problem described below which is very similar to the problem described in the above posts.

Guest OS: Win 7 Professional 64-bit w/AMD Quad Core w/16GB RAM
I began experiencing the problem described above today after creating a Windows Server 2012 virtual machine and creating 4 linked clones of the VM. The problem occurred every time I launched one of the Linked VMs.

Please note that I did not encounter this problem until I attempted to launch the Linked Clones.

VBox App Info:
VirtualBox.exe File Version: 4.2.12.0
Product version: 4.2.12.r84980

Problem Event Name: APPCRASH
Application Name: VirtualBox.exe
Application Version: 4.2.12.0
Application Timestamp: 5167d6dc
Fault Module Name: QtGuiVBox4.dll
Fault Module Version: 4.7.3.0
Fault Module Timestamp: 50085ba6
Exception Code: c0000005
Exception Offset: 000000000018c06c
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: e66a
Additional Information 2: e66a724e416909e929cad28ec2720455
Additional Information 3: d3dd
Additional Information 4: d3dd482afded9f5b771e2c4eda6a5ed8

I hope this assists in resolution in some way. Please advise if you need further information. And please advise if I made a mistake posting this here.


John

comment:5 Changed 11 months ago by Dsen

Hello John,

Thanks for your comment!
Unfortunately I still not able to reproduce the issue on my hosts, but I have few ideas about what can be the reason.

  1. Could you please describe the configuration of VM which you were doing a clones from? I especially interested if there were a snapshots (online/offline) taken there before the clones been taken.
  2. Also, its interesting if you were starting clone from VM manager (by enter-key or double-click for example) or from the console using some cli method (like VirtualBox --startvm or VBoxManage). Actually the most important thing here - was VM (clone) you starting the only one selected in VM manager at that moment or there was a group of them selected?

Thanks in advance!

comment:6 Changed 10 months ago by Ady

First, I apologize I didn't reply before.

I though I should get some kind of (email) notification when a reply is posted here, but it never happened. I just happened to take a look by chance. (Am I missing the relevant setting somewhere?).

Now, regarding the crashes...

I can already tell that the probability to crash VBox 4.2.x is lower if I:

  1. start VBox;
  2. wait a few seconds (or even a minute);
  3. start the VM;
  4. wait a few seconds, and if any VBox message appears (like about using the mouse inside the VM or about selecting the boot device if I pressed F12), then I wait even more before actually clicking or pressing any key;
  5. now the guest actually starts and I use it normally.

But the probability of a crash is higher if I don't pause each time, or if I first made some change to the VM settings or to the available images. For example, I:

  1. start VBox;
  2. open the Virtual Media Manager;
  3. release and remove ISO images that are currently attached to the relevant VM;
  4. close the Virtual Media Manager;
  5. open the VM's storage settings and add a new (different) ISO image;
  6. close the VM's storage settings with OK;
  7. start the VM, to be booted with the newly attached ISO image.

Then the probability of this QtGuiVBox4.dll crash is higher. After VBox crashes, I can still correctly close the specific opened VM (by whichever method the guest in that live ISO image has, for example). Then I have to choose to close VBox (which had crashed). The host OS is still usable. If I reboot my host (just to be sure it is not the specific state of the host in that specific moment that may affect further actions), I can successfully start the same exact VM (with the recently attached ISO image), and by following the first "method" (waiting, and no new settings being changed), then the probability of VBox crashing is lower again.

As I already said, I don't have any of these problems with 4.1.x, and I can change settings and I can always start the modified VM, without "pauses", and it doesn't crash.

All this behavior was happening back then, when I was still testing each and every release of 4.2.x. Tired from crashes, I kept using 4.1.24 for the last few months.

Maybe with this info someone can at least try to replicate the behavior in VBox 4.2.x.

I just now downloaded VBox 4.2.12 (I have not tested this version yet) and I'll be trying it under the following 2 circumstances:

  1. As long as I can, I'll pause my security utilities (antivirus, for example);
  2. As suggested here, I'll disable the preview, just in case it helps.

If I happen to identify more details regarding these crashes, I'll report them. If you have more questions or specific instructions for me to test, please don't hesitate to ask. (BTW, is there any way to receive email notifications when some post is modified or a new one is added to this bug ticket?)

TIA, Ady.

comment:7 Changed 10 months ago by Ady

Testing 4.2.12, with my antivirus disabled and also with the VBox preview disabled, I received again the same behavior:

Application Name: VirtualBox.exe
Fault Module Name: QtGuiVBox4.dll

And, again, the probability for this crash is higher when I edit the VM's settings, specially when I add a new ISO image as bootable device (VM's settings -> storage).

After VBox crashes and after it is closed (remember, the VM is not necessarily crashing, but I shut down the guest OS before further tests), I can start anew Vbox, start the same VM, and this time VBox does not crash.

So, it seems it is not about something in my host nor in my guest OS, but about editing the VM settings, specially if the edition is about adding a new bootable ISO so to boot the VM from it. To be clear, the storage device is the same (in my case), and I change the (ISO) image so to boot the VM with a new one.

This might suggest that the behavior is related to the VM storage settings, or to some change in the Virtual Media Manager (which registers the changes to the storage media in every VM).

Hopefully this helps you so to replicate the crash.

TIA, Ady.

comment:8 follow-up: ↓ 9 Changed 5 months ago by frank

Still relevant with VBox 4.3.2?

comment:9 in reply to: ↑ 8 Changed 5 months ago by Ady

Replying to frank:

Still relevant with VBox 4.3.2?

From 4.2.0 until 4.2.16, all versions had the same problem.

In 4.2.18 the behavior is much better. I have seen this crash in 4.2.18 a couple of times (in comparison to prior 4.2.x versions crashing almost every time). OTOH, I admit I have been using VBox much less than before, in part because of these crashes.

I have not updated VBox to 4.3.x yet, since my experience when I went from 4.1.x to 4.2.x was so inconvenient, and having "only" 2 crashes with QtGuiVBox4.dll I found myself somewhat reticent to update.

Is there any concrete indication that 4.3.x would behave better regarding QtGuiVBox4.dll ?

Regards,

Ady.

comment:10 Changed 4 months ago by frank

Actually there were no big changes in QtGuiVBox4.dll but as major parts of the GUI were rewritten in VBox 4.3.x it makes indeed sense to update. The latest 4.3.x release is 4.3.6 so any testing of this new release would be appreciated.

comment:11 Changed 3 months ago by L.

Have the same issue with 4.3.6-91406

VB manager always crashes after the guest has been properly shutdown, seems to be related to the configuration file. I have created a second user (on the same host), configured a virtualmachine configuration with the same settings and using the same vdi file. With the second user I have no problem.

Host OS: Win7 64Bit VB: VirtualBox-4.3.6-91406-Win Extension pack: Oracle_VM_VirtualBox_Extension_Pack-4.3.6-91406 Guest OS: Win8.1 64Bit

Steps to reproduce: start guest, without login on, shutdown host. Then Virtualbox manager stops working with exception:

Problem signature:

Problem Event Name: APPCRASH Application Name: VirtualBox.exe Application Version: 4.3.6.0 Application Timestamp: 52b1cae6 Fault Module Name: QtGuiVBox4.dll Fault Module Version: 4.8.4.0 Fault Module Timestamp: 51cd5a50 Exception Code: c0000005 Exception Offset: 0000000000194fcc OS Version: 6.1.7601.2.1.0.256.1 Locale ID: 1033 Additional Information 1: 1d98 Additional Information 2: 1d985baa09ac61a81304e07bb5997ab0 Additional Information 3: c618 Additional Information 4: c6189eacdb935e6e9395e1344f7940f0

Noticed, that in the failing configuration, there is still a reference to the old version, e.g. "/VirtualBox/GuestAdd/Components/VBoxGuest.sys" value="4.3.4r91027".

Why is it still there, when does it update or should it be updated? Why the reference? Could this be the root cause?

comment:12 Changed 3 months ago by frank

The 4.3.4 reference comes from the VirtualBox Guest Additions. If you installed the 4.3.6 Guest Additions then the corresponding guest property will be updated to 4.3.6 once you successfully booted your guest. If VirtualBox crashes during shutdown that could be also the reason why the settings file is not updated and the new (4.3.6) property is not written to the settings file.

comment:13 Changed 3 months ago by Ady

In my case, I don't use GuestAdditions. I might even boot a "Live" Linux ISO image in a VM, even without a vdi (nor with any other format of permanent storage).

Also, if I close VBox manager after making any changes (e.g. a new ISO image attached) to the VM properties (while the VM is also powered off), wait a few seconds and start VBox manager again, then I can run the VM and VBox does not crash (as long as I don't "eject" the ISO image and replace it with another one).

So I don't need to create a new user in my host; closing VBox and starting it again (while my VM is powered off) is usually enough to avoid this crash. It's really annoying and a waste of time anyway.

Here is another case:

I have also tested booting from a vdi (Porteus frugal installation in it, MBR plus one FAT32 partition).

Once Porteus was up, I attached a new ISO image (seen as optical media in the VM) by using the VM bar (device -> ...). To be clear, the "IDE / PATA second port" where I attached the new ISO image was already there in the VM; I just added the ISO image after the Guest OS was already up and running.

By the time I close the guest OS, I see the VBox manager crashed.

FWIW, I use "low" screen resolutions, such as 800x600, both in the host and in the guest. I set 4MB of "video memory" setting of the VM properties. Changing to 6MB, I also saw VBox manager crashes.

In some cases, the guest Live OS starts with a higher screen resolution than what I want, so I use different "display modes" (full screen, seamless, ...) until I change the guest screen resolution to my desired 800x600. Then I usually go back to "fullscreen mode".

When the "OS type" (in the VM properties) is set to 'Windows', VBox manager claims that at least 6MB for video memory is needed. But the same VM could be used for some other OS type (not a Windows OS guest). Since I have seen crashes while using higher video memory values, I am not sure this setting is related or not.

The point is that VBox 4.1.x worked correctly with this same VMs every time, and 4.2.x is not.

I am still using VBox 4.2.20 for now, sometimes wishing to go back to 4.1.x again.

comment:14 Changed 3 months ago by L.

Hi Frank,

Thanks for your quick response.

It makes sense that VBMgr updates the settings after a proper shutdown. However it refers to an old version and the guest is working properly.

So why is it there?

This sounds like VBmgr needs to know what Addition version the guest has installed?

If that is true, than a guest environment (image) is not as isolated as I would expect, initialy a guest start diffently by VBMgr whith different Addition versions?

If its not true and these properties are just for the record (logging) shouldn't these be stored in the log file? VBMgr knows what version is installed on the host and could read these settings.

However, thanks to Addy's response, I dived deeper in the difference between the failing and success configuration files.

Found a diffence between 'Mini toolbar' settings (although I'm almost 100% sure I configured the success configuration the same).

The failing configuration file has no settings:

ExtraDataItem name="GUI/MiniToolBarAlignment" ExtraDataItem name="GUI/ShowMiniToolBar"

There are no ExtraDataItem with those name, how comes it lacks this setting in the failing vbox-config file?

When changing the 'Show in Fullscreen/Seamless': if 'Show in Fullscreen/Seamless'=true (checked), VBMgr crashes after shutdown. if 'Show in Fullscreen/Seamless'=false (unchecked), VBMgr does not crash after shutdown.

Tried this several times, reproducible on demand.

Position of the mini toolbar (top/bottom) does not make any difference. Also it does not matter if I before shutdown hover the mouse over the toolbar (so it becomes fully visible for a short time) or not.

Hopes this helps to solve the annoying bug (and get answers to my other questions too).

Last edited 3 months ago by L. (previous) (diff)

comment:15 follow-ups: ↓ 16 ↓ 20 Changed 3 months ago by Dsen

Hi L.

The thing you described is very interesting.
So to be precise, you:

  1. have latest 4.3.x VBox,
  2. have VM with ExtraDataItem name="GUI/ShowMiniToolBar" set to "true".

And VBox Manager (not VM GUI itself, but exactly VBox Manager GUI) crashing when this VM being shutdown? Is it related *only* to VM being shutdown in fullscreen/seamless mode? (Asking because mini tool-bar is used only in those cases.)

comment:16 in reply to: ↑ 15 Changed 3 months ago by L.

yep,

latest version 4.3.6.x only in fullscreen/seamless mode

windows shows message "Oracle VM VirtualBox Manager has stopped working"

after "Close the program" there is no virtualbox.exe in taskmanager anymore.

Have to start "C:\Program Files\Oracle\VirtualBox\VirtualBox.exe" to get the VBMgr GUI back.

So how to proceed to solve this bug?

comment:17 follow-up: ↓ 18 Changed 3 months ago by Ady

Are we sure we are talking about the same bug?

As I said before, when I see the crash I then wait a few moments and restart VBox manager (which previously crashed), then restart the VM (which was correctly shut down from the guest OS) and I can complete the guest session without a new crash. That is, if I don't make any changes such as attaching a new ISO or floppy image.

During this "second" run of VBox manager and the VM, I am not changing VM properties such as the aforementioned "VM properties -> general -> advanced -> show in fullscreen/seamless".

So it doesn't seem to be just one setting by itself. If it were, I would see the same crash the second run too. The QtGuiVBox4.dll crash in VBox 4.2.x has to be related to at least a combination of 2 things, such as new attached images, some setting and perhaps some memory leak.

As a remainder, when I:
1_ attach new images while the VM is powered off; then,
2_ close VBox manager; then,
3_ wait several moments; then,
4_ restart VBox; then,
5_ start the VM,

the crash is avoided (as long as I don't perform changes to the attached images).

So, in my experience the crash is not just about specific settings, but something else must be combined with some specific setting. And going back from VBox 4.2.x to 4.1.x avoids the crashes at all (I have tested this several times already).

As suggested in prior posts since I opened this ticket, just in case it might be of any influence I also disable my antivirus each time I use VBox, and I also disable VBox "preview". I didn't have to perform these actions when I used VBox v4.1.x.

Can a (relatively low) "video memory" value (and/or screen resolution in host and/or guest OS) in the VM properties be of any influence in generating this crashes? I doubt it (based on my experience), but I have not received any clear response about this. If there is such possibility, is there any procedure to test this? Can someone please try to replicate it?

It is also possible that QtGuiVBox4.dll is crashing in VBox 4.2.x for different reasons that the ones present in VBox 4.3.x.

comment:18 in reply to: ↑ 17 ; follow-up: ↓ 19 Changed 3 months ago by L.

The ticket is described as "VBox 4.2.x crash QtGuiVBox4.dll"

By comment off Frank, "The latest 4.3.x release is 4.3.6 so any testing of this new release would be appreciated.", I am using 4.3.6 and still get a reproducable crash in QtGuiVBox4.dll.

I get the same detail crash message as when you created this ticket (... Fault Module Name: QtGuiVBox4.dll ...)

In my case I can simply reproduce it by changing the setting 'fullscreen/seamless' mode.

I could have created a new ticket, but than it would be probably marked as 'possible duplicated'

comment:19 in reply to: ↑ 18 Changed 3 months ago by Ady

Replying to L.:

I could have created a new ticket, but than it would be probably marked as 'possible duplicated'

I truly appreciate all reports here.

I just want to open the possibility that we are talking about 2 different situations generating crashes in VBox manager related to QtGuiVBox4.dll. It's up to the developers to know what to do with these reports.

FWIW, I have changed my "VM properties -> general -> advanced -> show in fullscreen/seamless" to "off" (unchecked). After closing and restarting VBox, I attached a new ISO image to the IDE port of the VM (This time, when I say "new" I mean that it was not listed in the Virtual Media Manager at that moment, but it was there in the past but I had previously removed it some time ago, so this specific ISO image was not "completely" new).

Then I started the VM once or twice (I don't remember this so accurately). Eventually VBox manager crashed (not the VM). In this opportunity, the VM was not in fullscreen nor seamless modes when I saw the crash.

Usually (since this crashes) I would close VBox after each change, and I would re-run it before actually starting the VM. This procedure seems to reduce the chances of crashes. But this time I didn't close VBox before starting the VM, so to test the current settings. Unfortunately, it crashed.

I don't know if there is some method to completely "clean up" the installation of VBox before re-installing. I have tried a "clean up" in the past, and it did not help.

During the next few days I *may* test the new 4.2.22 and perhaps even 4.1.30. This has been annoying me for a whole year already.

comment:20 in reply to: ↑ 15 Changed 3 months ago by L.

From the failing configuration, I removed the harddisk and shut down VBoxMgr. Restarted VBoxMgr, I re-added the same vdi, and the problem is gone.

the old vbox config had the setting: <AttachedDevice type="HardDisk" hotpluggable="true" port="0" device="0">

After adding the vdi again, its <AttachedDevice type="HardDisk" port="0" device="0">

No hotpluggable setting there, who set it?

Seems the crash has something to done with hotpluggable????

I'm lost, can't remember I ever saw a setting indicating I wanted to attach a hotpluggable disk.

comment:21 follow-up: ↓ 22 Changed 5 weeks ago by Ady

In vbox 4.3.8, the changelog includes items such as:

  • AHCI: ejecting a CD/DVD medium failed under certain conditions
  • AHCI: disk hotplugging fixes

among others.

I don't know if this bug #11426 could be related to AHCI specifically, but items as the aforementioned, when accompanied by my experience with vbox 4.2.x (as I described in prior posts), at least triggers the following questions:

Are the changes (specially, bug fixes) in 4.3.x backported to 4.1.x and/or 4.2.x?

Is there any way to know whether additional versions will be released for the 4.1 and 4.2 branches?

For the time being, I am back using 4.1.30, since 4.2.x still makes my life harder.

TIA,
Ady.

comment:22 in reply to: ↑ 21 ; follow-up: ↓ 23 Changed 5 weeks ago by frank

Replying to Ady:

In vbox 4.3.8, the changelog includes items such as:

  • AHCI: ejecting a CD/DVD medium failed under certain conditions
  • AHCI: disk hotplugging fixes

among others.

I don't know if this bug #11426 could be related to AHCI specifically, but items as the aforementioned, when accompanied by my experience with vbox 4.2.x (as I described in prior posts), at least triggers the following questions:

Are the changes (specially, bug fixes) in 4.3.x backported to 4.1.x and/or 4.2.x?

The first fix will be available as part of the next 4.2.x maintenance release, the second will not.

Is there any way to know whether additional versions will be released for the 4.1 and 4.2 branches?

VirtualBox is currently the actively maintained stable version. Important fixes are also backported to VirtualBox 4.2.x. VirtualBox 4.1.x gets only very important fixes these days.

For the time being, I am back using 4.1.30, since 4.2.x still makes my life harder.

Would you test this 4.2.23 snapshot to check if it fixes any of your problems?

comment:23 in reply to: ↑ 22 Changed 5 weeks ago by Ady

Replying to frank:

Would you test this 4.2.23 snapshot to check if it fixes any of your problems?


Thank you frank for your reply.

I have installed VBox 4.2.23-92752 (updating from 4.1.30). Since I am still unable to make an exact step-by-step procedure so to replicate the crashes in 4.2.x, I'll just keep using it until I experience a new crash. In such case, I'll report back here.

I see new maintenance stable versions released (4.1.32 and 4.2.24 among others). I wonder whether I should keep 4.2.23-92752 for now, or if instead I should update again, to the new 4.2.24.

I am also thinking about the possibility that some other program running in my host system could be working correctly while using VBox 4.1.x, but could, perhaps, have some "bad interaction" when using VBox 4.2.x. For instance, could a program such as "drivegleam" (which sometimes I run in my host, for CPU and HDD load monitoring) cause such different interaction depending on the VBox version?

TIA,
Ady.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use