loader lock ownership

[Mixa]

Hello,
I have troubles launching virtial machines: Detected loader lock ownership.
VM fails to start with E_FAIL (0x80004005) and is reproduced constantly. Contrary to previous reported cases, it is not connected with Kaspersky Antivirus or any other antivirus, and it affects not all virtual machines.

So, the details:
These 2 lines cause fail

Detected loader lock ownership: rc=Unknown Status 22900 (0x5974) '\Device\HarddiskVolume1\WINDOWS\system32\faultrep.dll'.
Detected loader lock ownership: rc=Unknown Status 22900 (0x5974) '\Device\HarddiskVolume1\WINDOWS\system32\winsta.dll'.

This loader lock presents in all virtual machines logs, but does not affect the launch process:

Detected loader lock ownership: rc=Unknown Status 22900 (0x5974) '\Device\HarddiskVolume1\WINDOWS\WinSxS\amd64_Microsoft.Windows.Common-Controls_6595b64144ccf1df_5.82.3790.5190_x-ww_04280519\comctl32.dll'.

During last month or two it appears occasionally. One or few of existing virtual machines fails to start with thess errors in VBoxHardening.log regardless of guest architecture, VM parameters or guest OS. Other VMs work without problems.

Now one Win7 x86 guest is affected, another one works (it was the exact clone of the first one made a month ago). Looks like VMs in the "current state (changed)" are affected more frequently, then VMs that have snapshots, and the bug disappears when you reset the VM to the previous snapshot (but I'm not sure about these facts).

Host OS: Windows Server 2003 x64 SP2 installed somewhere in 2012
VirtualBox: 5.0.6 r100337 installed in Oct. 2015
No changes were made neither in OS not in VirtualBox during recent months.

• HyperV is not here
• This is not signed / unsigned DLL issue, Server 2003 have no and did not require signed DLLs or drivers.
• Not connected with UAC / Run as Admin: there is no UAC and I always run VirtualBox from admin account
• Microsoft Virtual PC was installed in December, it caused some troubles with Host-Only network adapter, but I know how to avoid them for VMs created earlier. The issue is not connected with Virtual PC, since it did not happen all spring, when both were used intensively.
• SFC / checkdisk passed last week, the issue happened earlier.
• BIOS virtualization enabled. Both VMs good and bad are VT-x/AMD-V and Nested Paging enabled.

VBoxSVC.log from user folder contains dozen of similar errors at the time of VM start:

01:04:06.845703 ERROR [COM]: aRC=E_FAIL (0x80004005) aIID={4afe423b-43e0-e9d0-82e8-ceb307940dda} aComponent={MediumWrap} aText={Unknown exception
01:04:06.845703 F:\tinderbox\win-5.0\out\win.amd64\release\obj\VBoxAPIWrap\MediumWrap.cpp[2245] (long __cdecl MediumWrap::GetEncryptionSettings(unsigned short **,unsigned short **))}, preserve=false aResultDetail=0

{Unknown exception is trimmed? Where is } ?
I do not use VM encryption.

Does anybody know the reason why the issue happens and how to fix it?

[scottgus1]

I think the only thing that will help us here is to zip and post a hardening log when the guest fails to start and the hardening error box pops up.

What "Detected loader lock ownership" actually means in the Virtualbox hardening context could be an insoluble problem, except to a couple of developers who have been initialed into the seventh level of the inner circle's rites and mysteries. The devs have said they play these cards extremely close to the chest, even among the devs. Can't let the malware guys get those secrets.

Server 2003 have no and did not require signed DLLs or drivers.

I think it is not Server 2003 that is highlighting this problem. Virtualbox has stringent requirements for the operating environment, so that malware on the host does not use Virtualbox to get higher privileges. See Diagnosing VirtualBox Hardening Issues.

Zip and post the hardening log when the guest next fails to start, we'll see what can be done.

[Mixa]

Good evening!

Attaching 2 log files - for working and not working virtual machine at the same host.
Some difference since the line:

fcc.fd0: supR3HardenedWinVerifyCacheScheduleImports: Import todo: #0 'vboxoglhostcrutil.dll'.

Both VMs are cloned from the same original. But, different states and snapshots now.

Can't let the malware guys get those secrets

I believe all modern malware will crash upon the start because nobody cares on testing their software on older Windows versions. This is a "good tradition" started by Microsoft aiming the increase of new Windows versions selling / income. I remember somebody brought a worm on his USB drive to the public PC in our office, it failed to start due to absense of some .NET framework installed

[scottgus1]

The exit code in your 'bad' hardening log (0x80000007) is not in our 'Diagnosing' tutorial above. It's rare, perhaps unheard of. I am unsure what to do to fix it. Even more am I unsure of why one guest has the error and another does not, on the same host PC. It seems to me all guests should suffer hardening issues.

In a case like this all I can suggest is switch physical hard drives in the host PC, reinstall W2003 and Virtualbox only, then try the guests. See what happens. If the guests all run, continue installing other software that was on the original install, one program at a time, trying the guests after each install. If the guests fail, the last program installed is probably the offender.

[fth0]

The exit code in your 'bad' hardening log (0x80000007)

A search for this NTSTATUS value will only point you back to the DLL loader lock problem you started with (e.g. In Windows, what is the meaning of a crash with exception code equal to STATUS_WAKE_SYSTEM_DEBUGGER 0x80000007?).

Your VirtualBox version 5.0.6 is rather old. Perhaps a newer version has improved hardening code that can give more information about the unknown adversary (if there is one) ...

[Mixa]

Good night!

Ok, I understand nobody knows why it started to happen.
OS re-install is not the solution, it will take extremely long time to restore all software and settings that I have now.
As I mentioned above, no new sotware was installed recently. The last was in December.

The only thing I can do now is to update to some newer version and post newer logs if the problem will appear again. Could somebody confirm the .vbox xml-base files and .vdi images format did not change since 5.0.6 up to the latest versions? I have x64 host so 6.1.10 must run under Server 2003 without problems.

[scottgus1]

Guests from 4.0.x & onward have had no formatting changes that would prevent them from running in 6.1.x. (After running the guest in newer versions, Virtualbox does sometimes save off a copy of the old .vbox file with a version 1.1x added to the name, to handle slight modifications to the .vbox format, but the guest still runs.) Guests from 3.y.x & earlier probably would still run, too, and if not there is a way to convert them to 4-&-later format.

6.1.x made some changes to 3D acceleration that would break guests using 3D from 5.0.6. The VboxVGA video card no longer has 3D acceleration due to a massive security hole, and the replacement video cards only provide 3D acceleration on Windows 7 & later guests. Probably similar limitations for Linux guests, though I don't know the breakpoint.)

You don't have to upgrade to 6.1.x. 5.2.x & 6.0.x are decent and run well too, and don't have the video card change.

[scottgus1]

One other thing, since this problem has only arisen in the last couple months, you could switch drives and restore the two-month-old host-PC disk images from your backups, confirm that the guests run well, then transfer newer data from the existing drive with the failing guests.