4.3.20 VM window keeps squeezing into smallest possible size

[wroot]

Uninstalling and reinstalling VirtualBox on the host will do absolutely nothing if the problem is in the guest registry.

As i said this is happening with read-only LiveCD linux machines, booting from ISO, no vhd assigned. Worked fine with 4.3.12 and now suddenly it can't boot normally from the same ISO. If i create a new machine and assign an ISO to boot (and install eventually) it behaves the same (small window) on first boot up from the ISO.

About Revo. I have checked and now i remember why i have stopped using it (Free version). It doesn't show 64-bit applications (you need paid Pro version for that). VirtualBox installs as 64-bit version if you use 64-bit host OS. Well, there are probably some other registry cleaners to clean up it completely after uninstall.

[socratis]

this is happening with read-only LiveCD linux machines, booting from ISO, no vhd assigned

Can you please post:
- a link or a name to a failing Linux LiveCD
- the "LiveCD.vbox" and
- the "vbox.log" for the LiveCD VM that fails.
I trust that you have tried to create the "recipe" (LiveCD.vbox) from scratch and it has failed as well, but I'd like to see the above three things. Remember to compress the above log and vbox before attaching them, please.

[wroot]

Linux Mint 17.1 MATE 32-bit http://www.linuxmint.com/edition.php?id=173
Attached a zip with vbox file and the logs from the same folder. I have assigned a new ISO (17.1) today while using VB 4.3.12, ran it, was ok.Then i have updated to VB 4.3.20, ran it, experience the shrinking window issue, shut it down. Zipped the logs and config.

[socratis]

Sorry for the long post that follows.

Thank you very much for the information. I downloaded the iso you referenced to try it out. I have a VM called "LiveCDs" that I use for cases like that. I modified it so that the .vbox files matched as close as possible (except UUIDs, MACs, sound, etc.). I couldn't reproduce it.

Same thing with a fresh VM that matched your configuration. There was one striking difference between the two files that seemed to be relevant to your problem. I don't know if it is the result of recording the state of the VM, or actually suggests how to run the VM (I believe it's the former). BTW, my monitor is 1920x1200, I don't know about yours, but it seems that I can handle a maximum windowed guest at 1440x1050 resolution and you can handle a 1024x768 (purple in the logs below).

Yours: <GuestProperty name="/VirtualBox/GuestAdd/Vbgl/Video/SavedMode" value="259x69x32"
Mine : <GuestProperty name="/VirtualBox/GuestAdd/Vbgl/Video/SavedMode" value="1440x1050x32"

Now, to the comparison of the two VBox.logs. Right after we both added DNS info and were offered a DHCP-initiated address (at 00:37.489145 in your log), the problematic info starts coming in. Keep in mind that there are several times before that, where the video mode seems to have changed successfully.

Mine

00:00:31.346682 Guest Additions capability report: (0x0 -> 0x4) seamless: no, hostWindowMapping: no, graphics: yes
00:00:31.523042 Guest Additions capability report: (0x4 -> 0x4) seamless: no, hostWindowMapping: no, graphics: yes
00:00:31.523115 VBVA_INFO_SCREEN: [0] @0,0 1440x1050, line 0x1680, BPP 32, flags 0x1

Yours

00:00:41.260227 Guest Additions capability report: (0x0 -> 0x4) seamless: no, hostWindowMapping: no, graphics: yes
00:00:41.260383 UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 259x69
00:00:41.260577 VMMDev::SetVideoModeHint: got a video mode hint (259x69x0)@(0x0),(1;0) at 0
00:00:41.409801 Guest Additions capability report: (0x4 -> 0x4) seamless: no, hostWindowMapping: no, graphics: yes
00:00:41.409899 VBVA_INFO_SCREEN: [0] @0,0 1024x768, line 0x1000, BPP 32, flags 0x1

After that, there are several lines indicating that the video mode is trying(?) to change, something that is missing from my logs. Note that the line below are not necessarily continuous in your log.

Yours

00:00:41.986645 UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 259x69
00:01:07.339123 UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 1680x946
00:01:07.339354 VMMDev::SetVideoModeHint: got a video mode hint (1680x946x0)@(0x0),(1;0) at 0
00:01:17.289947 UIMachineView::sltPerformGuestResize: Sending guest size-hint to screen 0 as 259x69
00:01:17.290252 VMMDev::SetVideoModeHint: got a video mode hint (259x69x0)@(0x0),(1;0) at 0

Finally, at the end of the logs there are the following differences, which may be related to what's finally written in the .vbox file.

Mine

00:01:24.401886 NAT: zone(nm:mbuf_ext_refcnt, used:0)
00:01:06.588310 Changing the VM state from 'DESTROYING' to 'TERMINATED'.
00:01:06.610894 UIMachineView::storeGuestSizeHint: Storing guest size-hint for screen 0 as 720x400

Yours

00:01:24.401886 NAT: zone(nm:mbuf_ext_refcnt, used:0)
00:01:24.404469 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={f6916ec5-a881-4237-898f-7de58cf88672} aComponent={Keyboard} aText={The console is not powered up}, preserve=false
00:01:24.412584 Changing the VM state from 'DESTROYING' to 'TERMINATED'.
00:01:24.460429 UIMachineView::storeGuestSizeHint: Storing guest size-hint for screen 0 as 720x400
00:01:24.484314 ERROR [COM]: aRC=E_ACCESSDENIED (0x80070005) aIID={8ab7c520-2442-4b66-8d74-4ff1e195d2b6} aComponent={Console} aText={The object is not ready}, preserve=false

Oh, and another thing that I don't know how it got there, but I believe it's because you created the "recipe" in 4.3.12 and it got transferred to 4.3.20. I have the key '<LongMode enabled="false"/>' and you don't. Which results as "00:00:02.107748 fHMForced=true - 64-bit guest" in the logs of your VM.

Now what? I would try to start with a new VM in 4.3.20, not one "translated" from 4.3.12, just to make sure it's not something 'lost in translation'. See if you can repeat the problem. If so, I would definitely head to the bugtracker.

Thanks for reading so far

[wroot]

Thanks for the investigation There is already a ticket filed by someone else on this thread. Not sure if i should file another one (if i can at all, not sure about the permissions in the bugtracker). Attaching another zip of a new machine created in VB 4.3.20. I have also tried to create a machine without any ISO or vhd and it also starts with a squeezed window, but it actually hangs for some reason.

[Perryg]

@wroot,

I suspect that your issues are starting with the following reason.

Code: Select all

00:00:01.122572 supR3HardenedErrorV: supR3HardenedScreenImage/Imports: cached rc=VERR_LDRVI_NOT_SIGNED fImage=1 fProtect=0x0 fAccess=0x0 cHits=32 \Device\HarddiskVolume7\Windows\System32\user32.dll

You should post to the bugtracker ticket and provide your information.

[socratis]

For the love of Zeus! How on earth did I miss that one??? Thanks Perry, that might explain a lot of things...

[Perryg]

@socratis,

It happens. I suspect that something that wroot has installed on the host has replaced user32.dll, seems to be a common issue these days, whether it was a virus software package or other program. It really sucks for Windows users.

[wroot]

@wroot,

I suspect that your issues are starting with the following reason.

Code: Select all

00:00:01.122572 supR3HardenedErrorV: supR3HardenedScreenImage/Imports: cached rc=VERR_LDRVI_NOT_SIGNED fImage=1 fProtect=0x0 fAccess=0x0 cHits=32 \Device\HarddiskVolume7\Windows\System32\user32.dll

You should post to the bugtracker ticket and provide your information.

Perryg, you have nailed it I have done sfc /scannow and after a reboot the issue has gone away. But i will have to replace user32.dll again (removing windows activation module:)). Probably it is related to all the issues since 4.3.14 with the anti-virus software. Some sort of security hardening and checking for signing of system files. Also probably possible in some other scenarios (other than mine) when installing some software. I have filed a ticket, but i'm not sure if it won't be closed https://www.virtualbox.org/ticket/13676

Will have to use 4.3.12 for now.