Windows 98SE will not install

[tezza]

Hi, Windows 98SE won't install on my system.

Here's the sitation.

I have two Win 98SE installation packages. One is a bootable CD, the other a non-bootable one.

With the bootable installation CD, the error appears immediately. With the non-booable one (where setup is started with MS-DOS), the machine goes a fair way through the process..installing the system on the hard drive. The error appear when the system reboots to load WIN98 from the hard drive to complete the installation .

The error is the same in both cases. It says "

VirtualBox.exe - Application Error

The instruction at 0x77839A95 referenced memory at 0x000C000C. The memory could not be written."

Installation cannot proceed from this point.

I'm using Virtual Box Version 5.2.8 r121009 (Qt5.6.2)

The machine I am using is a 32-bit Intel(R) Core TM i5 CPU running Windows 10.

In the virtual machine, the acceleration tab in the System property is greyout out (I've checked CMOS and it looks as if the motherboard doesn't support hardware virtualisation). All extended features (PAE/NX, I/O APIC) are switched off. RAM is set for 64MB.

Other OS's (MS-DOS, Windows 95, Windows 2000, Xp and 7) install just fine.

The Log attached is that produced from the bootable CD.

[tezza]

Log file for the bootable Windows 98 SE install attempt

[michaln]

Could you please provide the bootable ISO for easy reproduction?

FYI, your CPU is of course 64-bit, though your host OS is not. Also, the acceleration bits are grayed out because of this: "VT-x is disabled in the BIOS for all CPU modes". Whether you can enable it or how, I don't know. Your CPU is definitely capable of hardware virtualization.

[tezza]

Replying to michaln:

Could you please provide the bootable ISO for easy reproduction?

Sure, it's here: ​https://www.dropbox.com/s/4m73w66sndxwooi/Windows%2098%20Second%20Edition.iso?dl=0

Please let me know when you've picked it up so I can remove the share.

FYI, your CPU is of course 64-bit, though your host OS is not. Also, the acceleration bits are grayed out because of this: "VT-x is disabled in the BIOS for all CPU modes". Whether you can enable it or how, I don't know. Your CPU is definitely capable of hardware virtualization.

Right. I can't find anyway to activate it in BIOS though. I don't think it would be related to this problem though, would it?

[michaln]

Got the ISO, thanks!

The disabled VT-x is very likely related to the problem, but it's hard to say for sure before understanding what exactly the problem is (I'm sure the ISO will help).

[tezza]

Replying to michaln:

Got the ISO, thanks!

The disabled VT-x is very likely related to the problem, but it's hard to say for sure before understanding what exactly the problem is (I'm sure the ISO will help).

I discovered a way to switch on VT-x in BIOS. That was indeed the problem. Windows 98SE installs just fine now. It obviously needs it.

[michaln]

Actually no, Windows 98 does not need VT-x, but there is some bug in the non-VT-x execution engine. For whatever reason the bug only affects 32-bit hosts, not 64-bit hosts.

So if you enabled VT-x and the problem is gone for you that's great, but for us the bug remains and we still need to fix it.

[Socratis]

@michaln,

Can you please be a little bit more specific on the versions of VirtualBox that this "bug" affects? Is it a raw-mode issue?

I've seen plenty of tickets/forum reports lately about guests failing without the availability of VT-x and my advice so far was to switch to 5.1.x or 5.0.x, where raw-mode support is "better", not "phased-out". It wasn't too far off of an advice, but any more information that you could share, would be appreciated.

Thanks in advance...

[michaln]

I don't know which versions are affected, and so far all I know is that the problem is reproducible on 32-bit Windows 10 host and not reproducible on 64-bit Windows 7/10 host. The VM is crashing in the recompiler, which is less likely to be used without VT-x, but not guaranteed not to be used (except on OS X hosts which don't have it at all).

Also "failing" is a lot broader symptom than "crashing".

[Socratis]

Replying to michaln:

Also "failing" is a lot broader symptom than "crashing".

I'm talking about Guru Meditations with VERR_TRPM_PANIC (if I'm not mistaken) as the main error. And in all cases enabling VT-x (if possible), fixes it.

As I said, I don't remember that many reports about the non-availability of VT-x. I'd have to say that the reports started pouring in after 5.2.8 was out. Definitely not 5.2.10 because the majority of the people haven't been able to use 5.2.10 for "technical reasons".

[michaln]

As you can see, a guru meditation is not what was reported here. Whether the underlying problem might be related is anyone's guess at this point.

[michaln]

This particular crash is far from new, it goes at least as far back as 4.3.40. I'm beginning to wonder if it ever worked. It's something about that particular Windows 98 SE bootable ISO.

[michaln]

The crash does not happen with VirtualBox 4.2.36 (or 4.2.30 or 4.1.36 or 4.0.14). It does happen with 4.3.0 and likely all following versions. So this broke between the 4.2 and 4.3 series, several years ago.

[Socratis]

Replying to michaln:

It's something about that particular Windows 98 SE bootable ISO.

OK, now we're getting somewhere. Because there are a gazillion of people that have installed Win98SE with no problems whatsoever. I didn't ask all of them if they had VT-x or not, but chances are that someone would have had such a limited host. If you're talking about "this CD", well, that's a whole different ball game.

It does happen with 4.3.0 and likely all following versions. So this broke between the 4.2 and 4.3 series, several years ago.

Aye caramba! That's what I mean a nicely sleeping bug... ;)

[lean_geek]

Same issue with winME floppy.

[michaln]

Same issue as in a crash with the message "The instruction at XXX referenced memory at 0x000C000C"? 32-bit Windows host?

[Socratis]

michaln,

Let me fill you in the details by lean_geek, pretty much a summary of the discussion that took place in the thread "​Virtualbox :application error breakpoint has reached". For the gory details, you can read the thread, but here's the summary:

• Host: Win7-32, Intel Atom N450
• VirtualBox: 5.2.8 r121009
• Guest template: WinME
• Boot medium: Floppy, a copy of which you can find in ​https://drive.google.com/file/d/1bkfzGeimKZuGUszvlh56hzDRjbDrw7w_/view?usp=drivesdk
• Booting results:
  • the instruction at 0x075790 reffered memory at 0x000c70 the memory
  • exception breakpoint at 0x007000 ,click ok to terminate the application.
  • A breakpoint has been reached. 0x80000003) occurred in the application at location 0x65c080e6. <-- That last one was in a nested VM of mine, see below.

The issue was dismissed as a "Host doesn't have VT-x capabilities" (I apologize lean_geek) because everything we tried (on VT-x hosts) was booting just fine. And given that the raw-mode is losing the "fight", we thought that this was a "VT-x is not available" issue.

And I tried to prove it as well. Host OSX, Guest Win7-32, installed VirtualBox 5.2.11 on the Win7 VM. Now my Win7 "host" doesn't have VT-x (obviously). So, creating a new VM in the Win7 "host" and repeating the steps that lean_geek gave us, resulted in a crash at boot as well.

However, I monitor the Bugtracker, and somehow it clicked last night when I saw the update on this ticket, and I urged lean_geek to come here and post the details. Well, it seems that he was in "Tweeter mode", so here is the summary.

Socratis

[michaln]

The crashes with Windows 98 SE and Windows Me are indeed related. The symptoms are a bit different but the underlying problem is the same. The trigger seems to be some more or less highly specific instruction sequence in the Win9x boot sector.

While hardware virtualization is very highly recommended, a crashing VM process is still a bug.

A fix is now in svn, we'll have to see how well it works.

[michaln]

Not confirmed, but it may be possible to avoid the crash by running 'VBoxManage modifyvm <vmname> --hwvirtex off' (the GUI can't be used to do that on the affected systems).

[Socratis]

Confirmed!

Running "VBoxManage modifyvm "WinMe" --hwvirtex off" and booting from the WinMe floppy image mentioned in comment:15, allows the VM to boot with no crashes.