virtualbox.org

Win 10 host, win98SE guest. Occasional memory errors that crash the guest session. Same error, different numbers each time. Could it be as simple as the host needs a defrag?

Please change the graphics chipset to VBoxVGA (not VBoxSVGA or VMSVGA).

Can you please also post the hardening log (VBoxHardening.log, zipped please), as memory protection faults can be caused by unsigned DLLs which are discarded by the hardening feature.

If I'm reading the stack trace correctly then the crash is happening in VBoxDD.DLL - which means that the crash is happening in a user level device simulation. If changing the graphics chipset doesn't make a difference then I sugest you try turning off unnecessary devices to test if it makes a difference. I'd start with the audio next.

Requested log attached. If I switch from SVGA I am stuck with a 640x480 screen - that doesn't work for me. I can try running the Screen Doctor (or whatever its called) again tomorrow with the VGA. I am gone for the rest of this afternoon.

I am having a very similar issue (in terms of error message) on Win10 Host with Centos7.6 guest.

irishlazz wrote:Requested log attached. If I switch from SVGA I am stuck with a 640x480 screen - that doesn't work for me. I can try running the Screen Doctor (or whatever its called) again tomorrow with the VGA. I am gone for the rest of this afternoon.

That isn't how it works. The so-called VBoxVGA graphics chipset is also SVGA. The VBoxSVGA chipset is a new design introduced in VBox v6.0.0. It has bugs. And the VMSVGA chipset is not intended for Windows guests at all. In any case both of the latter require you to install GAs which do not exist. That is why I asked you to revert to VBoxVGA. A look at the user manual should tell you the same (section 3.6.1).

There's no need to run a screen doctor: plenty of others have installed the BearWindows SVGA driver in a Win98 VM, so you aren't exactly exploring new ground. My own Win98SE VM has a 1024x768x32bpp display. It uses the VBoxVGA emulation and the BearWindows driver.

1248.728: supR3HardenedMonitor_LdrLoadDll: rejecting 'C:\Users\kayeness\AppData\Local\Microsoft\OneDrive\19.012.0121.0011\amd64\FileSyncShell64.dll' (C:\Users\kayeness\AppData\Local\Microsoft\OneDrive\19.012.0121.0011\amd64\FileSyncShell64.dll): rcNt=0xc0000190

This is the only problem I see in the hardening log. You should check why this apparant system DLL has an invalid signature, but unless your media was located on OneDrive (which I'm sure you would have mentioned), I don't see how this can cause the crash. Though it may still be worth looking for a fix to confirm that.

I just realized that this topic is in the wrong forum (Windows Hosts). Your choice of forum should be dictated by the subject matter, not a fun fact from your biographical data. I'll move the topic to "Windows Guests".

mpack wrote:I just realized that this topic is in the wrong forum (Windows Hosts). Your choice of forum should be dictated by the subject matter, not a fun fact from your biographical data. I'll move the topic to "Windows Guests".

Since it seemed to me that the error is occurring on the host side of the relationship I thought I was choosing the correct forum.

Now running VGA with tolerable resolution. I'll let you know if the error recurs. As for OneDrive rejection - that software serves no purpose on this machine and can be uninstalled if it is an issue.

Switched to Bear driver. Uninstalled OneDrive. Still got this error. Both vbox and vboxhardening logs in zip. Physically the only attachments to this PC are the rehometer, monitor, keyboard, mouse & Ethernet cable.

mpack wrote:.... If changing the graphics chipset doesn't make a difference then I sugest you try turning off unnecessary devices to test if it makes a difference. I'd start with the audio next.

What is the better approach for this, disabling through the VBox settings, or from within the Win98 device manager?

In the VM settings. You want the hardware to not exist, not merely ask the guest OS to stop using it.

Incidentally, looking at the new log, are you trying to set a 1024x768 x24bpp graphics mode? Don't. It should be 32bit, matching the host, so that images can simply be "blitted" to the host window. Currently VirtualBox has to translate every pixel for display, which should slow graphics down considerably. Basically, always match the host, plus I doubt your host is using 24bpp graphics.

You had me wondering if I had mistyped "24bpp" in my previous post, but I'm glad to see that I didn't.

I'm not saying that this has anything to do with the error.

The 24bit would have been a misplaced click. So now VGA 32, Bear. Unhitched the not needed Audio, floppy, and USB drivers. Got the VB crash again while running a test. Also still getting the fatal OD/VXD/VMM error if I try to plot data in the old program. I can live without the plot, but it might be a clue to this crash/error. Latest vbox and hardening logs attached.

irishlazz wrote:I can live without the plot, but it might be a clue to this crash/error.

Perhaps, but with the info given I have no idea what it might reveal. It's not as if it's an old DOS program and has to switch to graphics mode to display a plot. A crash then would be a big clue. But Win98 is not DOS, it runs in a graphics mode all the time. You'd have to identify some other piece of hardware that is used at that time. You have to think subtle, e.g. I was suspecting the audio "ting" that might accompany a task complete dialog box, hence the audio suggestion.

Strange... your previous hardening log showed an error code of 0 at the bottom, therefore I took little interest in it. Now it shows a 0xC0000005 protection error typical of a hardening problem. Of course it's crash handler may just have picked up a non-hardening related crash.

I see you have Symmantec Antivirus installed. I wonder why you need to install third party security on a Win10 host (which already has it), but set that aside. At the very least you need to test the effect of disabling third party AV. If you can produce a VBoxHardening.log that has no mention of Symantec and still has the crash, that is good proof that AV is not implicated.

The PC is repurposed from general use and has the standard image. I have admin rights on the PC but am still locked out of some things. For example, I can click to "Disable Sym Endpoint Protection", but I can't make any changes within the settings. So the attached is after a crash following the Disabling of SEP. Still several mentions of Sym. in regard to Firewall. I'm also experiencing great difficulty in com1 flow of information again.

The provided log still shows Symmentec AV enabled. It's basically pointless to upload a new log unless this has changed.