VirtualBox

Opened 11 years ago

Closed 7 years ago

#11426 closed defect (obsolete)

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

Reported by: Ady Owned by:
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 (1)

VBoxlogs.zip (61.0 KB ) - added by Ady 11 years ago.
4 VBox logs from the same VM

Download all attachments as: .zip

Change History (29)

by Ady, 11 years ago

Attachment: VBoxlogs.zip added

4 VBox logs from the same VM

comment:1 by Al, 11 years ago

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 by Al, 11 years ago

Hi,

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

Al

comment:3 by Dsen, 11 years ago

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 by John Hobbs, 11 years ago

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 by Dsen, 11 years ago

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 by Ady, 11 years ago

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 by Ady, 11 years ago

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 by Frank Mehnert, 10 years ago

Still relevant with VBox 4.3.2?

in reply to:  8 comment:9 by Ady, 10 years ago

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 by Frank Mehnert, 10 years ago

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 by L., 10 years ago

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 by Frank Mehnert, 10 years ago

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 by Ady, 10 years ago

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 by L., 10 years ago

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 10 years ago by L. (previous) (diff)

comment:15 by Dsen, 10 years ago

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.)

in reply to:  15 comment:16 by L., 10 years ago

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 by Ady, 10 years ago

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.

in reply to:  17 ; comment:18 by L., 10 years ago

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'

in reply to:  18 comment:19 by Ady, 10 years ago

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.

in reply to:  15 comment:20 by L., 10 years ago

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 by Ady, 10 years ago

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.

in reply to:  21 ; comment:22 by Frank Mehnert, 10 years ago

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?

in reply to:  22 comment:23 by Ady, 10 years ago

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.

comment:24 by Dsen, 9 years ago

Is it possible to check that with upcoming VirtualBox 5.0 release using some of latest rc?

in reply to:  24 comment:25 by Ady, 9 years ago

Replying to Dsen:

Is it possible to check that with upcoming VirtualBox 5.0 release using some of latest rc?

I want to let you know that I have not forgotten this ticket and that I am following its news. Unfortunately, my host's resources are very limited, and I have invested a lot of time already trying to overcome both, the problems posted by me in this ticket and the limited resources.

There is also the hardening matter (since v. 4.3.14 and the other branches that were relevant at that time).

At some point I am probably going to give Virtualbox v.5 a try. If there is something specific that would contribute to solve / explain the behavior I posted in this ticket, or some other specific relevant info, I am willing to perform some test sooner.

If I happen to have some info relevant to this ticket, I'll post it here.

comment:26 by Ady, 8 years ago

I am hoping the following info could help replicate the original problem(s).

  • Host OS: Windows Vista Home Basic 32-bit SP2.
  • Host RAM: 1GB

I have a VM with:

  • chipset: PIIX3
  • Base Memory: 384 MB
  • Processor's Extended Features: PAE/NX is not enabled.
  • Video Memory: 16 MB
  • First boot device: Controller IDE - CD-ROM
  • Second boot device: Controller SATA - HDD

1_ Attach as (virtual) bootable CD-ROM:

  • gparted-live-0.24.0-2-i586.iso

2_ Boot using gparted-live-0.24.0-2-i586.iso (Default -> Forcevideo -> 800x600x15).

3_ Once the Live graphical desktop of GpartedLive is shown, close any program / window that is opened.

4_ Select "Exit", then "Shutdown".

At this point, everything seems to be OK.

5_ Attach as (virtual) bootable CD-ROM (replacing the prior iso image):

  • Fedora-Live-LXDE-i686-23-10.iso

6_ Boot using Fedora-Live-LXDE-i686-23-10.iso (just to the Live session, not actually installing Fedora).

7_ Once the Live graphical desktop of Fedora-Live-LXDE is shown, close any program / window that is opened (probably none).

8_ Select "Logoff" (or "Logout") from the applications menu, then "Shutdown".

At this point, the shutdown process starts, but the VM crashes.

Notes:

  • Only the VM crashes, not the VBox manager, nor the host OS.
  • I can replicate the same procedure again and again; with GPartedLive there is no crash during shutdown, whereas with FedoraLive the VM always crashes at shutdown.
  • When exiting FedoraLive, the crash occurs whether I choose "Shutdown", or "Reboot".
  • When the crash occurs, the host OS shows the following info:
 Problem Event Name:	APPCRASH
 Application Name:	VirtualBox.exe
 Application Version:	4.2.24.0
 Application Timestamp:	5321dd32
 Fault Module Name:	MSVCR100.dll
 Fault Module Version:	10.0.40219.1
 Fault Module Timestamp:	4d5f0c22
 Exception Code:	c0000005
 Exception Offset:	00001ed7
 OS Version:	6.0.6002.2.2.0.768.2
 Locale ID:	1033
 Additional Information 1:	3ed2
 Additional Information 2:	0ae49d73c5365721c1ba007f70658af2
 Additional Information 3:	1a98
 Additional Information 4:	5b71abb20892edf1134ef9f94fa6aa29

I am not seeing at this time an error message related to QtGuiVBox4.dll, and I do not know whether this current situation (triggered by FedoraLive) is originated by the same problem I originally reported 3 years ago, but at least I can replicate it.

At this time I cannot discard the possibility of some other incompatibility (e.g. between F23's Linux kernel and the version of VBox I am using), or anything else that might have been resolved in VBox in later versions. Until the crash can be first replicated by others in this version of VBox and then somehow it can be proved that it is resolved by later versions, there would be no point for me to keep playing with upgrades and downgrades. I have done this "playing" during a long period already, and I admit I am slightly tired of it.

Again, at least I can replicate this current crash consistently. Hopefully it helps in solving the original issue.

TIA,

Ady.

comment:27 by Mihai Hanor, 8 years ago

Please upgrade to a newer version of VirtualBox, preferably 5.0.10. Attach a complete VM log for the new version, if you still can reproduce the crash.

Last edited 8 years ago by Mihai Hanor (previous) (diff)

comment:28 by Frank Mehnert, 7 years ago

Resolution: obsolete
Status: newclosed
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use