Virt. mach. crashes on host desktop lock/unlock cycle

[GDK]

Used VB ver. is 4.3.26, about the reason later in this post
Guest is Ubuntu 10.04 LTS Desktop or 14.04 LTS Desktop 64Bits.
Host is Windows 7 64Bits.
Guest Additions of matching version installed.
Extensions Pack of matching version is installed.
16GB RAM physically. 8GB or 2GB (case by case) for guest.

The problem is that if user carries out the host desktop lock-unlock cycle while a virt. mach. is running,
the virt. mach. instance looks like to be gone after unlock. It means its instance is not no longer visible in host GUI.
The host desktop lock has arbitrary duration. Some times few minutes, some times more than 10 minutes.
There are also cases when the problem does not occur at all.

There was period of time in the last past, when 4.3.26 showed the problem significantly more seldom than 4.3.30 or .34.
That's the reason why I got stuck on 4.3.26. However, since few days ago 4.3.26 does not show this behavior any more.
It means same often with 3.26 as 3.34.

As mentioned the test above ran with two virt. mach. running in parallel. One showed the problem, the another one survived the
host desktop lock-unlock cycle. goodcase.zip was captured on the latter one. Yes, you are right the guest OS version
is not the same in good-case as in the bad-case. Please note that are test runs where the virt. machine with the another os
crashes as well.

In most cases the virt. machine do not get any job from user to accomplish for the duration of host desktop lock-unlock cycle.

My admin is examining if I am allowed to show you my VBoxStartup.log unfiltered.

[socratis]

My admin is examining if I am allowed to show you my VBoxStartup.log unfiltered.

There is absolutely nothing sensitive in the logs. If you post a log please do not try to obfuscate the information by replacing what you think might be sensitive information with xxx-xxxxx-xx-xxxxx or 192.###.#.##. We have to guess the missing details and that helps no one.

It's like going to the doctor and saying "I'm in severe pain in my left ####, but the top @@@@@ of my ### is not affected. HELP ME!!!"

[GDK]

These are the policies of local network the affected machine emerges in. Not my choice.
I got your comment. So, the logs will be provided if judged as eligible, or not at all. Not my choice.
If VB community will not be able or willing to help without access to VBoxStartup.log this thread will be closed and a search for alternatives started.

[GDK]

Approximately same time ago as the problem started to exist I did few changes in configuration of these two vm's
-) shared clipboard had been enabled; was disabled previously
-) mouse had been set to USB tablet, even though the host setup has a USB mouse
-) USB controller had been enabled, however no eHCI, nor xHCI
What I will do as next is to revert these changes and continue my observations if problem still there.
Reporting on this will follow as soon as reasonable results available.

Still no feedback from my admin.

[michaln]

The thinking is approximately like this... if it's worth your time to obfuscate things in the log, you can afford an Oracle support contract. If you want free support for a free product, you don't get to choose the conditions under which support is provided.

[GDK]

The thinking is approximately like this... if it's worth your time to obfuscate things in the log, you can afford an Oracle support contract. If you want free support for a free product, you don't get to choose the conditions under which support is provided.

I forward your comment to my admin. It is not my problem, nor my job.
Me will do what I can do on my own.
Nor my reporting here seems to been carefully read; michaln's last comment the best evidence.

[GDK]

As up to now not a single crash occurred. Though not a one but few settings were reverted I suppose the USB tablet related one is deciding. No reboots were made since fix in virt. mach. config, but sleep cycle every night, and several host desktop lock/unlock cycles every day since then.
If shared clipboard is used then it is enabled only for duration of its usage, just to not provoke the crash of running virt. mach. if the shared clipboard should be the reason of addressed problems. No further reporting will follow. Still no feedback from admin.