Virtualbox.exe crash -> fixed in svn.

[Jim Ramsay]

After around 24 hours of uptime, my 'virtualbox.exe' process will crash.

The guest at the time was running but not being actively used.

WinXP guest (32bit), Gentoo Linux host (32bit, 2.6.33 kernel)

I am attaching the contents of the "Error Report" that would be sent to Microsoft, as well as the most recent VBox.log file.

[Jim Ramsay]

VBox.log

[Jim Ramsay]

Okay, there's no easy way to cut&paste the info from that Windows "Error Report Contents" window, so here's the first bit transcribed:

Error signature
  AppName: virtualbox.exe   AppVer: 3.2.0.0   ModName: vboxdd.dll
  ModVer: 0.0.0.0   Offset: 00008da5a

... To view the technical information about the error report, click here: ...

Exception Information
Code: 0xc0000005 Flags: 0x00000000
Record: 0x0000000000000000 Address: 0x00000000004a5a5a

System Information
Windows NT 5.1 Build: 2600
CPU Vendor Code: 756E6547 - 496E69 - 6C65746E
CPU Version: 000006F6  CPU Feature Code: BFEBFBFF
CPU AMD Feature Code: 00F9E824

Module 1
Virtualbox.exe
Image Bse: 0x00400000 Image Size: 0x00000000
Checksum: 0x003ee822  Time Stamp: 0x4bf2d6f
Version Information
 Signature:     feef04bd
 StrucVer:      00010000
 FileVer:       (3.2:0.0)
 ProdVer:       (3.2:0.0)
 FlagMask:      0000003f
 Flags:         00000000
 OS:            00000004
 FileType:      00000001
 SubbType:      00000000
 FileDate:      00000000:00000000

...

[Jim Ramsay]

One last interesting thing to note: This only killed one of my 2 running VMs. The other guest which is running a custom linux with a 2.6.30 kernel is still running and functioning normally.

[vasily Levchenko]

This crash relates to networking activity of your guest. Could you please describe the what network activity this guest was doing? Could you please do me a favour? I'd appreciate you'll able to collect application crash dump (please see ​capturing application crash dumps for more information). I'm preparing debug bits to help in understanding of what happenings in NAT stack. I'll upload as soon as they will ready and will provide additional instructions about starting.

And by the way do other guests use host resolver (dns settings)?

[vasily Levchenko]

I've uploaded debug bits at ​VBoxDD.dll. Could you please upgrade your installation up to 3.2.2 and replace VBoxDD.dll with downloaded one? Please start your vm in following way:

# set VBOX_LOG=drv_nat.e.l2
# set VBOX_LOG_DEST=nat.log
# VirtualBox -startvm <your-vm-name>

please attach result log to the ticket. If you'll manage to get crash dump please drop me a message at vasily _dot_ levchenko _at_ Sun _dot_ COM, I'll provide you instruction how to upload the dump.

[Jim Ramsay]

Copied from drwatson "Log Viewer" window.

[Jim Ramsay]

Since I last updated the ticket, but before I saw your comments here, I had upgraded to VirtualBox-3.2.2 With this default VirtualBox-3.2.2 I experienced a crash again last night, and have posted the output of pushing the "View" button in Dr. Watson... But the time listed at the "When" line seems quite old, I'm not sure what's going on there. Perhaps it's an old log file that should be disregarded.

As for what the guest was doing, I'm not entirely sure what time the crash actually occurred, which would give me more information on what if any cron jobs were running at the time. I know I wasn't doing anything actively, and the most probable cron job would be a nightly rsync of the Gentoo "portage" tree.

Since this crash has occurred, I have now set up:

• DrWatson to generate a crashdump and not just a log. I think. I'm relatively new to this whole Windows debugging thing.
• Downloaded your debug-enabled VBoxDD.dll, and restarted the VM as specified.

When the next crash occurrs, I will contact you about uploading the dump.

[Jim Ramsay]

The crash occurred again. I tried to upload the associated VBox.log file, but the file size is 19M in size, and trac will not allow me to upload such a large file.

I will contact you directly for instructions on how to proceed now.

[vasily Levchenko]

Replying to lack:

The crash occurred again. I tried to upload the associated VBox.log file, but the file size is 19M in size, and trac will not allow me to upload such a large file.

I will contact you directly for instructions on how to proceed now.

Instructions have been mailed.

[vasily Levchenko]

Replying to Hachiman:

Replying to lack:

The crash occurred again. I tried to upload the associated VBox.log file, but the file size is 19M in size, and trac will not allow me to upload such a large file.

I will contact you directly for instructions on how to proceed now.

Instructions have been mailed.

Could you please verify a ​build? Does it fix issue for you?

[Jim Ramsay]

Replying to Hachiman:

Could you please verify a ​build? Does it fix issue for you?

Testing now. I will update the bug in a few days once I feel confident of the state of the new VBoxDD.dll

(Note, I am still running with 3.2.2, have not yet upgraded to 3.2.4)

[Jim Ramsay]

Or not, I got an error after copying the test build of VBoxDD.dll in place of the Debug version you previously provided:

VirtualBox - Error
------------------

(X) Failed to open a session for the virtual machine Gentoo.

Unable to load R3 module C:/Progra~1/Oracle/VIRTUA~1/VBoxDD.dll (VBoxDD)
(VERR_SYMBOL_NOT_FOUND)

Unknown error creating VM
(VERR_SYMBOL_NOT_FOUND).

[v] Details
Result Code: E_FAIL (0x80004005)
Component: Console
Interface: IConsole {6375231a-c17c-464b-92cb-ae9e128d71c3}

[vasily Levchenko]

Replying to lack: for record: we've agreed on IRC to check if 3.2.b2 solves the issue.

[Jim Ramsay]

Running 3.2.6b2 and I'm pleased so far, it's been one overnight period and no crash yet.

(Previously the error dialog would be the first thing I'd see after logging on in the AM, most days.)

I'd call my self cautiously optimistic at this point, after a full week of uptime I think I'd be satisfied that this issue is fixed.

[vasily Levchenko]

Replying to lack:

Running 3.2.6b2 and I'm pleased so far, it's been one overnight period and no crash yet.

(Previously the error dialog would be the first thing I'd see after logging on in the AM, most days.)

I'd call my self cautiously optimistic at this point, after a full week of uptime I think I'd be satisfied that this issue is fixed.

How it goes?

Could you please check your logs (recent) for following line:

AssertLogRel E:\tinderbox\win-rel\src\VBox\Main\ConsoleImpl.cpp(4234) Console::getGuestProperty:
RT_FAILURE(vrc) || VBOX_HGCM_SVC_PARM_64BIT == parm[2].type

or something like that? Actually this message were appeared in your initial uploaded log, that assert doesn't stop your vm, just print the message. If it appears again with 3.2.6, could you please update the ticket?

[Jim Ramsay]

Steady as she goes.

Did a grep of my logfiles, no 'Assert' to be found anywhere yet. I will try to search for it periodically and update this ticket if it appears again.

Thanks so much for your time and effort on this fix, it looks like you've done it!

[vasily Levchenko]

thanks for feedback.

[Frank Mehnert]

Please reopen if still relevant.