The fact that I cannot even boot a completely clean Ubuntu (OS not even installed, just a VM created and ISO file mounted) eliminates, in my mind, the possibility that our company VM is to blame.
See the FAQ. Hardening problems are problems with the
host
. The guest OS is not relevant thought it can affect the timing of specific crashes.
Thanks for your answer.
I'm on board with that. Just wanted to be sure there was no effect from the VM itself.
However, this excerpt from the post you mention makes little sense to me:
If you find that the VM will not start in normal mode, but will start when run in headless mode, then that makes it pretty much certain that your problem is the graphics drivers.
If that is so, what is then the difference between running in normal mode (guest screen shown as window) and headless mode (guest screen shown as miniature/preview)? I can understand that maybe Trend Micro is preventing some dll injection from happening, but I can leave it running if I just start the VM in headless mode. Shouldn't it cause the same issue there? Or do I fail to understand why this only happens at boot/resume and not any other time while the VM is running?
I also have a VboxHardening issue. It surprisingly happened with no warning---I was workign fine one day, and the next day, the same VM failed to start.
It does work in headless mode (thanks for the tip!). I've attached the log, but I don't understand them at all. I can't figure out from the log which components are successful and which are not.
I am in a large corporate managed environment and so can't turn off the nannyware installed.
Any suggestions?
mbkennel wrote:
I am in a large corporate managed environment and so can't turn off the nannyware installed.
2a04.8cc: FileDescription: Cylance Protect Driver
2a04.8cc: FileDescription: PowerBroker for Windows
2a04.8cc: FileDescription: BeyondTrust PowerBroker for Windows DLL
If you can't completely uninstall them and/or update them to a version that they've addressed the problem, find a way to add an exception for VirtualBox. There's no other option.
socratis wrote:
If you can't completely uninstall them and/or update them to a version that they've addressed the problem, find a way to add an exception for VirtualBox. There's no other option.
I did that in Trend Micro Security Agent for:
The entire Virtualbox program folder
The entire folder that contains our virtual machines
File types VDI, VHD, VMDK and VBOX
Am I missing an exclusion?
The entire folder containing said executables is added as an exception, as stated in my previous comment:
stmtjt wrote:
I <added exceptions> in Trend Micro Security Agent for:
-
The entire Virtualbox program folder
(etc.)
If excluding an entire folder is not sufficient to exclude any executable file contained therein, or if excluding a file by itself or the folder that contains it does not have the same effect, please enlighten me.
Sorry, I can't tell you how your choice of AV does exclusions, you would have to ask the AV provider. If you want to confirm that VirtualBox has been excluded then look at the VBoxHardening.log for the VM. Scroll down until you find the ": supR3HardenedWinFindAdversaries: nnn" line. If nnn is anything other than 0x0 then your AV is still interfering. The lines following should make it clear what AV is responsible.
Also search for the "more than one thread" error as discussed in the FAQ. If you see that then again your AV is still there.
