Virtualbox virtual machine won't start

[Ben321]

I need to run Windows XP on my PC, which currently is using Windows 10. Instead of downgrading my OS, I decided instead to just run Windows XP in Virtualbox. So after finishing the virtual machine wizard (in which I accepted all the default settings), it was time to install the OS, which first means turning on the virtual machine. So I have a completely freshly created virtual machine, but it won't start. It gives me the following error whenever I try to start my virtual machine.

The error is:

Failed to open a session for the virtual machine Windows XP.

The error details are:

The virtual machine 'Windows XP' has terminated unexpectedly during startup with exit code 1 (0x1). More details may be available in 'C:\Users\Ben Hutchinson\VirtualBox VMs\Windows XP\Logs\VBoxHardening.log'.


Result Code: E_FAIL (0x80004005)
Component: MachineWrap
Interface: IMachine {b2547866-a0a1-4391-8b86-6952d82efaa0}

I've attached the log file to this message.

[mpack]

Tutorial: Diagnosing VirtualBox Hardening Issues.

[Ben321]

Tutorial: Diagnosing VirtualBox Hardening Issues.

According to that post

(RULE2) VirtualBox no longer "errors out" when an unsigned DLL is found. Instead the rule is that VirtualBox now merely discards the errant DLL and continues.

But my problem is that it WAS "erroring out". At what version was this fix supposed to be implemented? My version of VirtualBox is "5.1.20-114628". Is there a command-line switch I can use to disable hardening?

Can you please analyze the log file I attached in my first post, and tell me what went wrong?

[socratis]

You didn't read all of it, you failed to identify the key things that might cause this, like the one in your log:

2588.2db0:     ProductName:     SYMEVENT

from Symantec. Get rid of it and try again.

The thing is we can't possibly know what you have or haven't got installed in your system. You're in front of your computer, not us. You've got to figure out the offending application, and then, let them know about it; they shouldn't be injecting themselves into other processes unless they're properly signed and they've updated the Windows certificate database.

PS. For future reference you should ZIP your logs. It helps save a (virtual) tree or two...