Null pointer issue with launching VirtualBox 5 machines

[PHolder]

Quite frequently I am seeing a null pointer issue when I first launch a virtual machine in VirtualBox 5. I get a pop-up saying: The instruction at: 0x0007FFF615BD564 referenced memory at 0x00000000000018 (I didn't count the # of zeros, sorry, ;-) The memory could not be read.

This seems to happen especially more often when I close the VirtualBox main window as the virtual machine is launching... but it doesn't seem to require that.

The host is running Windows 10, but this happened when I was on Windows 8.1 also. It's 64bit Windows on i7 4770K with 32G of RAM.

I've had it happen on different guest OSes, Windows 10, Windows 7 and Liunux, so I don't think the guest OS matters.

[PHolder]

Just happened again while the machine was rebooting to install patch Tuesday updates, different address again. 0x0007FFF5CCAD564 and still trying to read 0x18. It appears the offset D564 is in common.

Here's a pic: ​http://snag.gy/xjgAS.jpg

[Frank Mehnert]

Any improvement with VBox 5.0.2?

[PHolder]

Well, I've tried a few things, and where I might have had the event in the past, I haven't yet... so fingers crossed that the fix was delivered with 5.0.2. Close this ticket if you like, so long as I can update it again later, or refer back to it, if it happens again.

[Frank Mehnert]

Thanks. Please reopen if necessary.

[PHolder]

Unfortunately it just happened again. ​http://snag.gy/vvjQP.jpg Still the offset 0x18, but the PC was 0x0007FF9D65C21F4 .

I don't see where there is anything I can do help report the problem? Is there some way to report more meaningful information?

[PHolder]

I guess someone needs to update the version above to 5.0.2 also.

[PHolder]

Just to indicate, this is still happening. Here's a new example, with a picture of the Win 10 virtual machine at the point of the failure: ​http://snag.gy/Qg62z.jpg

Again, the offset is always 0x18 and the 5.0.2 bad code is based at an offset of 21F4.

Still waiting for advice on any way I can further help with problem reporting, because all I can do is press the OK but which closes VirtualBox and aborts the virtual machine.

[Mihai Hanor]

Please attach a Vbox.log and a VBoxStartup.log (complete logs, compressed if they're too big) for one of your VMs. Also, when it crashes, do not close the crash dialog, because you'll need to save a memory dump of the crashed VirtualBox process. To do that, launch ​Process Explorer as Administrator, then look for the lowest VirtualBox process in the VirtualBox process tree (usually it's the one with the larger memory footprint), right click it and click Create Dump - Create Minidump. Compress it and attach it here.

[PHolder]

The requested logs, zipped

[PHolder]

I will capture the dump the next time I experience the crash, but have attached the logs requested.

[PHolder]

Just guessing, BTW, I suspect this might be related to the window resizing. There is a weird bug when I try to snap the window to the bottom, where the virtual machine slightly clips... and if you keep futzing with it, it will be okay... but when I launch, it does not stay at the snapped size. But again, this is just a guess.

[PHolder]

Well I managed to cause the dump again, by doing what I mentioned above, and playing with the window resizing, so it will be attached.

[PHolder]

So the minidump, zipped, is around 600k so is too big to attach here. I will post it in a dropbox and link that here.

[PHolder]

Hopefully this Dropbox share works. The minidump file, zipped, is here: ​https://www.dropbox.com/s/9n5awluirjeiw6m/VBminidump.zip?dl=0

[Mihai Hanor]

If you can, please test the latest test build of VirtualBox 5.0

[PHolder]

You never stated whether the information I previously reported led to any bugfix... or what might have actually been root cause, and as I am uncertain of exactly what the cause was I can only test so far...

A quick bit of testing on a test build of 5.0.3, I can't immediately get it to reproduce. On the assumption the problem was related to window resizing as I suggested I can see that it doesn't seem to remember the window position any more, which I don't view as a success. :-/

I will continue to test some more later, and report back here if I see the problem reproduce in this test build.

[Mihai Hanor]

I'm not an Oracle employee, nor a VirtualBox developer and I don't know the cause of your crash. The crash minidump showed me that the crash is inside VirtualBox (VBoxDD). But VirtualBox is being continuously improved, so it makes sense to test the latest build.

[PHolder]

I don't understand why this is closed as fixed without any reference to a fix. It is still occurring in 5.0.4, I just had an occurrence. I am going zipping the minidump now and will host it in dropbox and attach that note when it's ready.

[PHolder]

The new minidump file from VirtualBox 5.0.4, ZIPped, is here ​https://www.dropbox.com/s/bfszb5m354bix6g/VBoxMiniDump504.zip?dl=0

[PHolder]

I've had a rash of these, and captured a minidump each time, but I have my doubts that having more of them is of any value, so I will hold off posting anything until I hear otherwise.

[amedvedev]

We need additional information about it. Could you, please, use the test build https://www.virtualbox.org/wiki/Testbuilds? Also,please, enable the full dump of VirtualBox.exe process as described here - ​https://support.microsoft.com/en-us/kb/931673.

[Frank Mehnert]

Replying to amedvedev:

We need additional information about it. Could you, please, use the test build https://www.virtualbox.org/wiki/Testbuilds? Also,please, enable the full dump of VirtualBox.exe process as described here - ​https://support.microsoft.com/en-us/kb/931673.

Let me add that when you test the latest Windows test build, please let us know which build you tested (exact version and revision) and please always provide the corresponding VBox.log file.

[PHolder]

I want to say this is more than a little frustrating, and I don't feel you're taking this seriously or acting to debug it as I would expect a professional to do. Let me review the situation to explain this:

• You already know (if you have read what I wrote above) that the issue is not reproducible at will
• Asking me to try test builds, which may, or may not, have fixed the issue is not helping, because if it doesn't reproduce, do I know if it's finally been fixed or I am just not having good luck reproducing it
• The problem only occurs when a VM boots, so this means a lot of shutting down and restarting the VM, only to HOPE that I get a reproduction of a problem
• You have the minidump and traceback, which means you should KNOW which variable is NULL. Unless you think I'm wasting your time reporting this (I am NOT) then put some protecting code there, log something useful, and output a dialog indicating you want the log report (rather than crash as you currently do.) This seems a MUCH more productive tact to solve this problem then what is currently being asked.

[aeichner]

amedvedev and Frank weren't just asking you for trying random test builds. amedvedev asked you to enable a full memory dump of the crashing VBox process because the minidump doesn't include enough information unfortunately. In fact I can't see any signs of a crash with the last dump you provided. All threads are inside a syscall and waiting to return. No idea why, maybe something gone wrong while saving the crash dump. The only thing I was able to retrieve from it was that at the time the dump was taken a USB device was unplugged from the VM. Maybe that has something to do with the crash and not the window resizing as you suspected.

If you want to get this issue fixed it will require some more time on your side I'm afraid because we can't reproduce the issue nor can we spend a lot of time trying to reproduce it. This bugtracker is maintained on an best effort base for non paying users and paying customer issues have a higher priority (which I hope you understand).

[PHolder]

Well I had thought maybe this was fixed in 5.0.6, as i didn't have it re-occur on that build, but I just upgraded to 5.0.8 and it's back. This time I used ProcessExplorer to generate a full dump, I got a screen cap of the error dialog, and I copied the log files that had today's time stamps. Hopefully this is what is needed. It's a 118MB file I am sharing from Dropbox, which is located here: ​https://www.dropbox.com/s/hzcp9twvzfhi9ua/VirtualBoxFullDump.zip?dl=0

[sunlover]

Thanks for the dump, it contained information about the crash. Please test if this crash is fixed in the latest Windows build (revision 103580) from https://www.virtualbox.org/wiki/Testbuilds

[Frank Mehnert]

PHolder, it would be nice if you could give the test build a try. Confirming that the bug is fixed (or providing another dump in case it's not fixed) would be really helpful for us.

[PHolder]

Well, as I have indicated in the past, the bug does not reproduce at will. I have gone as long as a month without it happening again, so... I am unsure how I will know if I would have hit it again but it was fixed so it didn't happen. I have been testing with one preview build, and I see there is a newer one I will try that now. I will report back if I hit that issue (or something else.)

[PHolder]

I guess I was just thinking about it, and I wonder if there is some info from sunlover about what was fixed. This might help me test for the fix more intelligently.

[sunlover]

PHolder, according to the dump (which you provided a week ago) the crash happened when the guest resets a USB device attached to the guest.

The reset could happen when a new USB device is attached or when a USB device does not behave correctly and the guest re-initializes it.

I wonder if you remember what did you do with the guest before the crash happened. Anything USB related?

[PHolder]

Hmm, interesting. I am not really using any exotic USB on this device, and nothing specific I wanted in the guest. I have a USB keyboard and mouse, and an Intel F200 camera for use with Windows Hello and a Yubikey security key. If I had to guess what it might be, it would somehow be the F200. I have that on the other host machine that also occasionally crashed. Mind you, it also has the other devices too. Anyway... not had that crash again yet. I have a new one I am about to report though. :-/

[Frank Mehnert]

Let's close this ticket. Please open another ticket if you want to report an unrelated crash.