VirtualBox & NS_ERROR_FAILURE error

Updated: March 4, 2022

Recently, on one of my systems, VirtualBox stopped working. No matter which virtual machine I tried to launch, it would throw the same error. The popup window would read: Failed to open a session for the virtual machine [Whatever the name is]. In the details box, it would say: NS_ERROR_FAILURE (0x80004005).

Weird. The message is cryptic and generic, and doesn't really give you a clue as to might be wrong right away. Well, I set about troubleshooting, and after some trial and error, this little guide was born. Now, in all likelihood, it won't solve ALL your problems (with the same error code), but you might get just enough guidance to figure out what in your specific system is not working. Follow me.

Error message

Problem in more detail

As the popup message doesn't tell me much, I had to look in the system logs. Here, I found a far more useful piece of information. Namely, it seems like the VirtualBox VMSVGA graphics driver was crashing, and the error was pointing at the libX11 shared library.

Feb  3 12:21:09 kernel: [] VMSVGA FIFO[11413]: segfault at f8 ip 00007fcf4df5ada4 sp 00007fced9329c40 error 4 in[7fcf4df40000+133000]

At this point, I figured something must have gone bad with my VirtualBox instance. So I decided to go through it step by step, methodically. First, rebuild the VirtualBox modules with vboxconfig. This also restarts the service.

sudo vboxconfig Stopping VirtualBox services. Starting VirtualBox services. Building VirtualBox kernel modules.

However, this did not alleviate the problem right away. Then, I tried to think a bit more. What other component of VirtualBox may be at fault, but which isn't necessarily covered by the vboxconfig setup process. And I thought, VirtualBox Extensions pack?

I looked at what I had installed on my affected system, and I noticed that my VirtualBox and the Extensions pack had different versions. This is not a good thing, and can lead to unexpected behavior, which seemingly, did occur on my system. In Linux, the problem is exacerbated that, on launch, VirtualBox will check for updates to the Extensions pack and allow you to install it, whereas the core program itself relies on a system update. If these two do not happen in sequence, system first extensions second, then, you could end up in a situation where your virtual machines may not run, as above.

VirtualBox, About

Extension version, incompatible


The fix here is to remove the offending pack, and then install one matching the VirtualBox program, or vice versa. Either way, they must match. I went to File > Preferences > Extensions, and clicked on the Remove button. But then, I got the same error as earlier, while trying to remove the pack, that is!

Command-line cleanup

The fix to the second issue is to perform a cleanup operation in a terminal window - you can also use the command to install or remove extension packs (and even force removals).

VBoxManage extpack cleanup
Successfully performed extension pack cleanup

Now, I went back to the GUI, and I was able to remove the pack. Good. Then, I downloaded and installed a new one, a version that matches the main program version:

Install new extension pack

And now, the virtual machines run just as before!


In a way, the problem above is entirely self-made on my side. But then, there ought to be ways to make the whole thing more robust. For instance, not allow incompatible extension packs to be installed. Keep more than one version available (as a sort of restore), and use that if a default one fails. Provide more detailed messages. Provide extensions through the VirtualBox Linux repository, just like the main program.

If you encounter something similar, please note that the error code will most likely encompass a wide range of issues, and you won't necessarily be able to figure out the root cause for your VirtualBox problem just from looking at it. Instead, you may end up reading half a dozen bug reports or forum posts with the same starting point and a completely different solution/outcome in each case. My article is no exception in that regard, but I did carefully follow through the system log information, which allowed me to narrow down my focus and figure out the real culprit. Anyway, that would be all for today. Take care.


You may also like: