Windows 2008 r2 x64 Guest Intermittant Crash

[Matt Hopkins]

Host: OSX Yosemite 10.10 - 10.10.1 Guest: Windows 2008 R2 sp1 x64

The guest ends in an aborted state. I can't find any direct cause. It can happen after the VM's been running for 1 min, or for 2 days. I've seen the problem recur a few times when installing the java browser plugin, and the frequency seems to go way up if I'm running Process Explorer from MS internals.

This occurs with numerous Windows 2008 r2 VMs, including clean installs. The issue does not appear to affect Windows 2003, as I have VMs running that stable.

Thanks in advance for any help / guidance.

[Matt Hopkins]

I have a core dump, but it's too large to attach w/ the file upload limit. Where can I place it?

[Frank Mehnert]

Would it be possible to compress it and to send it to me at frank _dot_ mehnert _at_ oracle _dot_ com?

[Matt Hopkins]

Thanks for the response. Sorry, my notification settings must not have been correct as I missed it initially. I'll keep a closer eye on this.

I was having trouble sending an email w/ an attachment that large. A copy of the core dump is available here:

​https://www.dropbox.com/s/brrxcug3yjtqphc/core.25962.zip?dl=0

I've upgraded to 4.20, which seems to reduce the frequency, but it's difficult to tell, as the issue is sporadic.

As mentioned in Ticket 13630, which seems similar, I've attempted:

VBoxManage setextradata <VMname> "VBoxInternal/MM/CanUseLargerHeap" 1

But the problem persists. Next I'll try:

VBoxManage setextradata <VMname> "VBoxInternal/MM/cbHyperHeap" "4194304"

Thanks for any assistance!

[Frank Mehnert]

This setting is only related to that specific problem mentioned in that ticket. I'm currently downloading your core dump.

[Frank Mehnert]

The crash is most likely related to NAT networking. We are investigating.

[Matt Hopkins]

Thanks so much for investigating!! Let me know if there's anything I can do to help.

[Valery Ushakov]

Please, can you give VirtualBox-4.3.21-97167-OSX.dmg a try. Please, attach a VBox.log from it. Thanks in advance.

[Matt Hopkins]

Log file after boot with fix in place

[Matt Hopkins]

Running this version now. So far so good. Attached the new log file. The VM the core dump came from is no longer around, but the VM this log file is from also exhibited the issue.

Thanks!

[Matt Hopkins]

This fix is still holding strong. Thanks for the help with this. I believe we have a Windows 7 host machine exhibiting the same issue. Would the issue be cross platform? If so, would it be possible to get a Windows build of the test case build?

Thanks!

[Valery Ushakov]

Yes, the issue is cross-platform. You can get test builds from the Testbuilds page.

[Frank Mehnert]

Any feedback? Please note that the latest test build from here contains the fix for this problem.

[Matt Hopkins]

We've had one recurrence of the issue on a Windows host. This occurred using build 97167. At the very least, this is much less frequent than we experienced previously. Has there been any additional changes relating to this issue since 97167 that would impact the issue?

Log files for the crash are now attached as crash_97167

[Matt Hopkins]

crash_97167

[Valery Ushakov]

No, there were no relevant changes since 97167.

I assume you are using DNS proxy on Windows as well. I can't reproduce your Windows host problem so far. Have you seen it again since the last time?

[Matt Hopkins]

We've now seen it another two times on the Windows host since the last log was suppied, but the error has not occurred on the OSX host. Possibly this is different issue, since the original issue on OSX seems to be resolved.

Is there any other information that could help track down the issue on the Windows host?

[Valery Ushakov]

You haven't mentioned if NAT dns proxy is enabled on that crashed VMs on the Windows host too. The Mac problem (hopefully fixed now) was in the dns proxy and was triggered by the list of nameservers updated.

crash_97167 log ends with DHCP renewal (which also re-reads the list of nameservers) and based on my quick calculations the crash time (from the log name) seems to match those last log entries assuming east coast timezone if I can still do my math. So it looked like it might be some similar problem, but as I said, I can't reproduce it locally (with lease time artificially reduced to make the potential trigger happen much more often).

[Matt Hopkins]

Sorry, yes. That vm has all the same settings as the OSX vm, including the enabled NAT dns proxy. We'll try and produce another log next time the issue occurs.

[Valery Ushakov]

Replying to thematthopkins:

We've now seen it another two times on the Windows host since the last log was supplied, but the error has not occurred on the OSX host. Possibly this is different issue, since the original issue on OSX seems to be resolved.

I think this remaining issue is indeed a different one, most likely its another manifestation of #13994 where just the right timing of requests and replies may lead to use after free.

[Frank Mehnert]

The original issue (crash in NAT) should be fixed with VBox 4.3.30. Closing.