Application Error

[fth0]

Is the error dialog still open when the log is taken? Doing so will prevent a full log. Error messages get recorded in the log if the window is closed before the log is taken. No error message window from Virtualbox will appear if the VM truly crashes off abruptly with a truly unexpected failure.

Sorry that I have to chime in here in favor of the OP: There is no error message window from VirtualBox involved here. The Windows OS reported an application crash, and the VirtualBoxVM process cannot do anything after "OK" is clicked. If it had an appropriate exception handler installed (e.g. rtR3WinUnhandledXcptFilter), it would have dumped information into the VBox.log file already.

How can I know exactly which bad DLL caused this?

Windows usually create crash dump files (e.g. a minidump file), and you can analyze them with WinDBG Preview. Alternatively, the Windows Event Log may contain information about the crash.

[scottgus1]

fth0, thank you very much for setting me straight. I haven't run across a situation yet where the Hardening error wasn't recorded in the VM log, as far as I can remember (and I no doubt and am remembering wrong), except when Virtualbox itself completely crashed off on the host. I have learned something new today....

And gvvice, I humbly beg your pardon for making such a fuss and for annoying you so. I am truly sorry for my behavior. I'm quite embarrassed. Please forgive me?

As far as figuring out what actual file is causing the problem, I regrettably am not sure. If fth0 or any other forum guru has an idea, I'll be all ears to find out myself.

Once again, I am really sorry.

[fth0]

If it had an appropriate exception handler installed (e.g. rtR3WinUnhandledXcptFilter), it would have dumped information into the VBox.log file already.

This statement of mine could be slightly wrong: VirtualBox has its rtR3WinUnhandledXcptFilter installed during most of the VirtualBoxVM process runtime, but it uses the standard logging mechanisms, and if they are currently locked when the exception occurs, rtR3WinUnhandledXcptFilter cannot create the log messages. In any case, it calls the Windows default unhandled exception filter afterwards, which then creates the Windows error dialog.

---

If fth0 or any other forum guru has an idea

Windows usually create crash dump files (e.g. a minidump file), and you can analyze them with WinDBG Preview. Alternatively, the Windows Event Log may contain information about the crash.

To elaborate a bit on my first suggestion:

On the Windows host, install WinDbg Preview from the Microsoft Store, which is a (somewhat user friendly) modern version of the (in)famous WinDbg. Configure the Windows host to create minidump files on user-mode application crashes (see Collecting User-Mode Dumps for how to do that). Reproduce the VirtualBox crash. Open the minidump file in WinDbg Preview, which will automatically execute !analyze -v and hopefully provide a good backtrace of the crash.

[gvvice]

fth0, thank you very much for setting me straight. I haven't run across a situation yet where the Hardening error wasn't recorded in the VM log, as far as I can remember (and I no doubt and am remembering wrong), except when Virtualbox itself completely crashed off on the host. I have learned something new today....

And gvvice, I humbly beg your pardon for making such a fuss and for annoying you so. I am truly sorry for my behavior. I'm quite embarrassed. Please forgive me?

As far as figuring out what actual file is causing the problem, I regrettably am not sure. If fth0 or any other forum guru has an idea, I'll be all ears to find out myself.

Once again, I am really sorry.

Never mind, we are here to find the way out, as long as the issues can be resolved, all will just be fine.
Checked the crash report in windows, I also can't find anything related to VMBox after the issue happened...
So I don't know how can I provide the necessary info to you to help me solve this, might can check via remote desktop? Not sure.

[scottgus1]

Never mind, we are here to find the way out, as long as the issues can be resolved, all will just be fine.

Thanks very much, gvvice!

OK, so let's see what we can do. First, please uninstall the existing Virtualbox, then reboot and try the 6.1.35 test build (not the 6.1.97 development snapshot on the same page. 6.1.35 has some improvements that may help. Save the test build installer until you update again later. You'll need it if your host's MSI installation database goes south (they do) and the installer will not be available for download after the next even-number version gets released.

Then try the VM again, started from full powered off, not saved state. If the problem happens again, please close all Virtualbox windows, then zip and provide these things:
The VM's vbox.log and hardening log (farthest left and second farthest left tabs)
The whole ".Virtualbox" folder in C:\Users\{logged-on-account} (note the period in the file name).
Extract the Windows minidump and post it to a file-sharing site, then post the sharing link.

We'll see if something can be deduced.

[gvvice]

Never mind, we are here to find the way out, as long as the issues can be resolved, all will just be fine.

Thanks very much, gvvice!

OK, so let's see what we can do. First, please uninstall the existing Virtualbox, then reboot and try the 6.1.35 test build (not the 6.1.97 development snapshot on the same page. 6.1.35 has some improvements that may help. Save the test build installer until you update again later. You'll need it if your host's MSI installation database goes south (they do) and the installer will not be available for download after the next even-number version gets released.

Then try the VM again, started from full powered off, not saved state. If the problem happens again, please close all Virtualbox windows, then zip and provide these things:
The VM's vbox.log and hardening log (farthest left and second farthest left tabs)
The whole ".Virtualbox" folder in C:\Users\{logged-on-account} (note the period in the file name).
Extract the Windows minidump and post it to a file-sharing site, then post the sharing link.

We'll see if something can be deduced.

Tried 6.1.35, it even can't start the VM at all...

20220716_133702.jpg (44.17 KiB) Viewed 2192 times

Don't know where to find minidump files.
By the way, can your forum add log file hidden protection functions, sometimes log might will contains some info that don't want to be pulic?

[fth0]

00:00:02.702274 VirtualBox VM 6.1.35 r152011 win.amd64 (Jun 28 2022 18:44:19) release log
00:00:02.765751 Installed Extension Packs:
00:00:02.765759   Oracle VM VirtualBox Extension Pack (Version: 6.1.34 r150636; VRDE Module: VBoxVRDP)

You didn't install the matching VirtualBox Extension Pack (EP) from the test builds, and the crash probably happened in the vicinity of the USB support, which is provided by the EP. Install the current VirtualBox test build and the corresponding EP.

If you don't need nested virtualization, you should disable it to simplify the configuration.

Don't know where to find minidump files.

Please read again the Microsoft documentation I linked in my previous post.

[gvvice]

00:00:02.702274 VirtualBox VM 6.1.35 r152011 win.amd64 (Jun 28 2022 18:44:19) release log
00:00:02.765751 Installed Extension Packs:
00:00:02.765759   Oracle VM VirtualBox Extension Pack (Version: 6.1.34 r150636; VRDE Module: VBoxVRDP)

You didn't install the matching VirtualBox Extension Pack (EP) from the test builds, and the crash probably happened in the vicinity of the USB support, which is provided by the EP. Install the current VirtualBox test build and the corresponding EP.

If you don't need nested virtualization, you should disable it to simplify the configuration.

Don't know where to find minidump files.

Please read again the Microsoft documentation I linked in my previous post.

Thanks, test version works now, but mididump files seems still can't be generated after the crash, check the attached reg file to see if I did anything wrong.

[fth0]

The EP version still doesn't match the VirtualBox version (you didn't check the current test builds release number, did you? )

The registry keys look correct on first sight. Note that I don't have first hand experience using these keys, so I'm guessing a bit. Two ideas: I don't know if you can leave out the application-agnostic global keys, the documentation is not precise enough in this regard. Additionally, verify that you have WER enabled:

Code: Select all

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"Disabled"=dword:00000000

[gvvice]

The EP version still doesn't match the VirtualBox version (you didn't check the current test builds release number, did you? )

Already updated the EP version for host, for the vm part, I think it should be fine for using the old one?

I will check the crash related later.
Is the log helpful or not?

[fth0]

You're combining VirtualBox 6.1.35 r152011 and the VirtualBox Extension Pack 6.1.35 r152223, which are different revisions and not guaranteed to work with each other. In consequence, one cannot distinguish between a crash resulting from these non-matching revisions or a crash resulting from something else that shouldn't crash. Download and install matching revisions. The VirtualBox Guest Additions can stay on version 6.1.34 r150636.

Other than that, the log filed showed less information about a (potentially same or different) crash than the older log files.

[gvvice]

You're combining VirtualBox 6.1.35 r152011 and the VirtualBox Extension Pack 6.1.35 r152223, which are different revisions and not guaranteed to work with each other. In consequence, one cannot distinguish between a crash resulting from these non-matching revisions or a crash resulting from something else that shouldn't crash. Download and install matching revisions. The VirtualBox Guest Additions can stay on version 6.1.34 r150636.

Other than that, the log filed showed less information about a (potentially same or different) crash than the older log files.

Ok, seems you updated test build file, now I updated it also, don't know why logged less, though still can't get windows crash dumpfile after VM crashed.

[fth0]

The new log files show the same behavior as the previous ones. I can only give you the following hints ATM:

The crash happens in VirtualBox code working with the host's graphics drivers.

VirtualBox loaded rdpendp.dll shortly before the crash, which sounds like a RDP endpoint library.

VirtualBox 6.1.36 will probably be available within the next 24 hours.

[gvvice]

The new log files show the same behavior as the previous ones. I can only give you the following hints ATM:

The crash happens in VirtualBox code working with the host's graphics drivers.

VirtualBox loaded rdpendp.dll shortly before the crash, which sounds like a RDP endpoint library.

VirtualBox 6.1.36 will probably be available within the next 24 hours.

Ok, yes, its related to RDP, as I mentioned before, I connect to the host via RDP, after close and reconnect to the host via RDP, it will always happen.

[scottgus1]

I connect to the host via RDP, after close and reconnect to the host via RDP, it will always happen.

Ah! Is this what this means from the first post?

After the host network disconnected and reconnected again(with shared folders), then wait a little bit later, it will always there.

Virtualbox VMs rarely survive an RDP session, if the session is as deeply intrinsic to the host as Microsoft RDP. "rdpendp.dll" googles to be an MSRDP file, so you appear to be using MSRDP into the host.

Virtualbox is tied into the user account that is logged in. If the log-in status gets interfered with, like MSRDP does, then the VMs can have their Virtualbox service backbone swiped out from under them and crash.

If this only ever happens when you RDP, then I think we have a true bill. You'll need to VNC to the host instead.