I don't know anything about running old OSes on bare metal modern systems, so hopefully you get some better advice, but:

I wonder if the system is going to sleep for some reason? Are you able to disable the APM BIOS? I think this was something you could do on old machines, but I suspect you probably can't these days.

Yes, you should be able to debug over the serial port. I don't know if it would provide any useful information, but perhaps it's worth a try. I've never tried it myself, but I think that you should be able to either get Windows to just output debug messages as plain text, or allow you to attach a debugger which would use some debugging protocol (but as for whether the debugger would be more useful to you, I don't know). I think that you need to install the Windows SDK for your version of Windows, and then maybe it'll provide a batch file that switches to a debug kernel. You may or may not need to install the debug kernel - see below - but note I imagine it might blow away any patches you've installed.

MSDN mentions this from the Windows 3.1 SDK:

2.1.9 System Debugging Log Application (DBWIN.EXE)

System Debugging Log Application allows you to display messages produced by the debugging version of Windows, even if you are not running a debugger and if you do not have a debugging terminal. It even makes it possible for you to see some errors when it is running with the retail version of Windows. DBWIN.EXE allows you to control the output of specific varieties of messages. It also includes a feature that makes it possible for you to force memory-allocation errors, as an aid in testing the robustness of your application.

doshea wrote on 2025-03-16, 03:31:

I wonder if the system is going to sleep for some reason? Are you able to disable the APM BIOS? I think this was something you could do on old machines, but I suspect you probably can't these days.

There's no way to disable those advanced features (e.g. APM and such), though APM doesn't appear to work with 9x at all, as I have to manually press the power button to turn off the system once "It's now safe to turn off the computer" appears.

It feels like some kind of very high priority interrupt that the system must process even at the expense of blocking* Windows during the period.

* I can still move my mouse pointer when it happens, but everything else stopped responding until the "routine" finished.

doshea wrote on 2025-03-16, 03:31:

Yes, you should be able to debug over the serial port. I don't know if it would provide any useful information, but perhaps it's worth a try. I've never tried it myself, but I think that you should be able to either get Windows to just output debug messages as plain text, or allow you to attach a debugger which would use some debugging protocol (but as for whether the debugger would be more useful to you, I don't know). I think that you need to install the Windows SDK for your version of Windows, and then maybe it'll provide a batch file that switches to a debug kernel. You may or may not need to install the debug kernel - see below - but note I imagine it might blow away any patches you've installed.

MSDN mentions this from the Windows 3.1 SDK:

2.1.9 System Debugging Log Application (DBWIN.EXE)

System Debugging Log Application allows you to display messages produced by the debugging version of Windows, even if you are not running a debugger and if you do not have a debugging terminal. It even makes it possible for you to see some errors when it is running with the retail version of Windows. DBWIN.EXE allows you to control the output of specific varieties of messages. It also includes a feature that makes it possible for you to force memory-allocation errors, as an aid in testing the robustness of your application.

I think at best this could be used to debug Win3.x (386-enhanced mode) startup process. I'm very new to this so I need to look for some more documentation.

Just I don't know if there's any tool that can be used to debug while Win9x is running, as Win9x may not be as tolerant...

LSS10999 wrote on 2025-03-16, 13:00:

* I can still move my mouse pointer when it happens, but everything else stopped responding until the "routine" finished.

Oh I see, that certainly doesn't sound like it's asleep. I seem to recall you can get beeping when the Windows message queue is full, which can occur if it freezes and you keep moving the mouse around, in which case it might beep every time the mouse cursor moves. Perhaps that's what you're encountering?

I think at best this could be used to debug Win3.x (386-enhanced mode) startup process. I'm very new to this so I need to look for some more documentation.

Just I don't know if there's any tool that can be used to debug while Win9x is running, as Win9x may not be as tolerant...

DBWIN is something you run inside Windows, and I think you should be able to leave it running, do stuff, and then come back and see what messages have appeared. See e.g. the last screen shot at https://diarywind.com/blog/e/install-debug-bu … d-of-win31.html - I don't know what the menus are since it seems to be in Japanese, but you can see some messages in English, and from the bottom right corner of the screen you can see that the desktop shows it's running a 3.1 debug kernel.

For startup issues you may in fact not be able to use DBWIN - you might need to set up the debug output to go to a serial port for that. Or maybe you can set it to go to a file - that DBWIN screen shot above seems to show an .INI file with an option for output to a file.

I'm pretty sure 98 will have something similar - the ability to have the kernel output some text messages indicating problems is surely not something that they would have removed after 3.x, as it's way too useful to Microsoft's developers.

If you can't figure out how to install the tools on whatever version of Windows or can't get them to work, please do let me know - if nobody more knowledgeable about them shows up, I'd be happy to give them a go, as I've always been curious about this stuff.

doshea wrote on 2025-03-17, 06:35:

Oh I see, that certainly doesn't sound like it's asleep. I seem to recall you can get beeping when the Windows message queue is full, which can occur if it freezes and you keep moving the mouse around, in which case it might beep every time the mouse cursor moves. Perhaps that's what you're encountering?

When it happens:
- OS stuffs stop progressing, but mouse can be moved freely.
- After 30 seconds, a single beep can be heard.
- Everything starts moving again 10 seconds after the beep.

Opening "MS-DOS Prompt" is guaranteed to trigger this. However, the opened DOS box works without issues after that "routine".

I just did a bit further testing:
- Running a 16-bit Windows program on Win98 doesn't trigger the issue. Actually, this system can run Win3.1 in Standard Mode without any issue, and the system never enters such routine in that case.
- Running COMMAND from inside the DOS box doesn't trigger the issue.
- Opening another MS-DOS Prompt while there are already opened ones will 100% trigger it.
- Running a DOS game inside MS-DOS Prompt does not trigger the issue, even if the game "requires MS-DOS".

So the question is what was happening under the hood when opening a "MS-DOS Prompt" on Win98. Perhaps it's some kind of BIOS/INT call misbehaving...

Additionally, when I was installing .NET Framework 1.1 SP1 update, after rebooting the system, this routine happened tens of times in a row, without any DOS box appearing. I think it was the .NET assembly optimization process and that somehow could trigger the issue whenever it runs...

Should point out the issue is specific to this machine. On another 865G-based system of mine, this issue does not occur and everything looks good there.

LSS10999 wrote on 2025-03-17, 11:51:

When it happens: - OS stuffs stop progressing, but mouse can be moved freely. - After 30 seconds, a single beep can be heard. - […]
Show full quote

When it happens:
- OS stuffs stop progressing, but mouse can be moved freely.
- After 30 seconds, a single beep can be heard.
- Everything starts moving again 10 seconds after the beep.

That certainly doesn't line up with any of the kinds of "normal" bad behaviour I'm used to seeing!

I can only hope that if you do some debugging you might see some complaint from Windows, or perhaps just an indication of what it was doing at the time.

I was wondering if Sysinternals' Process Monitor worked on Windows 98, but I don't think it'd be useful here - I think it would just show API calls made by processes, whereas what you probably need is some lower-level information about what Windows is doing that triggers the issue. I imagine Process Monitor might just show for example that explorer.exe started command.com, and perhaps it might say it took 40 seconds, but you already know that.

Feels like an overheat condition.
Try running... I forget the name, but "cool n quiet" was its descendent.
The problem with dos on new machines is it can't shuffle around to different cores and it likes to run flat out even doing nothing. So it could develop a single hot core and some sort of on die temperature gradient sensor could be freaking out.

myne wrote on 2025-03-19, 12:22:

Feels like an overheat condition.
Try running... I forget the name, but "cool n quiet" was its descendent.
The problem with dos on new machines is it can't shuffle around to different cores and it likes to run flat out even doing nothing. So it could develop a single hot core and some sort of on die temperature gradient sensor could be freaking out.

I don't think the CPU (or the bootstrap core) is overheating. The CPU is being adequately cooled, and the temperature readings from other OSes as well as in BIOS is not that high. Usually at around 30-40s.

That's one average reading.
What's that one core thrashing away at 5ghz at?
If it's 100c and 7 others are 25 that's 375/8=46. At that level of difference it's likely some core protection smarts kicks in.
Again, dos runs 100% all the time. Grab any old pc, sit it in the bios and the fans will eventually start winding up.

I'm pretty sure there's a small tsr that runs nops in dos.
It's worth a try

myne wrote on 2025-03-19, 12:22:

Try running... I forget the name, but "cool n quiet" was its descendent.

Waterfall?

I can kind of see it being a temperature thing. I wonder if the BIOS settings might enable limiting the maximum CPU frequency? I sometimes do that from Linux when I want to keep the temperature down; not sure if BIOSes allow that kind of thing.

myne wrote on 2025-03-19, 13:36:

What's that one core thrashing away at 5ghz at?

Again, I don't think this is the case. I'm not overclocking the CPU so no, there won't ever be anything running at 5GHz there.

I'm using a 22-core E5-2699v4 on that system, and I don't think old OSes like Win9x would ever kick the turbo clocks. By default it should be running at around 2.4GHz.

And its HyperThreading has been disabled, because Windows XP can't handle more than 32 logical processors. I'm running a wide range of OSes on that system and everything is good except this odd behavior.

Regardless, I think I should give CPU-Z Vintage Edition a try to see if it can work on Win9x and whether it still supports reading newer CPUs, though it was a special edition focused on better detection of much older CPUs...

https://archive.org/details/dosidle

Can't hurt to try, can it?

LSS10999 wrote on 2025-03-21, 12:20:

Regardless, I think I should give CPU-Z Vintage Edition a try to see if it can work on Win9x and whether it still supports reading newer CPUs, though it was a special edition focused on better detection of much older CPUs...

Just want to update on this... it doesn't work. Running CPU-Z Vintage Edition will lead to a crash with a BSOD due to something wrong with the VXD extracted by it.

Though the system can recover just fine with such BSODs at the moment. A long time ago, on older PCs as well as when Win98 was my main OS, such BSOD-laden crashes generally mean I have to do a hard reset.

Hi, maybe related to high CPU load? Always happens to me in VMs.
For DOS, I do use DOSidle. MS-DOS 6.x has power.exe, also, which can be repurposed. Dr DOS/Novell DOS 7 has idle-detection.
For Windows 3.x 386 Enhanced Mode, I do use WQGHLT by Weiqi Gao.
For Windows 9x, I do use AmnHLT.

myne wrote on 2025-03-22, 08:57:

https://archive.org/details/dosidle

Can't hurt to try, can it?

I don't think the issue is related to CPU load at all.

Just tried DOSIDLE and it doesn't make any difference. I'm using the v2.51 version. It does load without issues just it says the CPU being Unknown Intel.

Hm. I haven't used modern PC hardware for ages anymore (moved to Mac), so I'm not sure what to make of it.

Maybe there's a relationship with SMM or V86/VME of some kind?
The heart of Windows 98 is the VMM, Virtual Machine Monitor.
Windows 98 is like a V86 manager with a GUI, thus.

I wonder, is EMM386 being loaded in both cases?
It might make a difference for the better or worse.

Modern CPUs might have trouble with supporting A20 Gate etc.
If a V86 memory manager is loaded, the situation might be better, even.
Because with a V86 memory manager (EMM386, QEMM, 386Max etc), the state of real A20 Gate nolonger matters.
The memory manager is simulating it to applications (it itself needs full mem access after all).
Windows 98SE as a VMM should simulate it all the time, thus.

Jo22 wrote on 2025-03-22, 14:09:

Hm. I haven't used modern PC hardware for ages anymore (moved to Mac), so I'm not sure what to make of it. […]
Show full quote

Hm. I haven't used modern PC hardware for ages anymore (moved to Mac), so I'm not sure what to make of it.

Maybe there's a relationship with SMM or V86/VME of some kind?
The heart of Windows 98 is the VMM, Virtual Machine Monitor.
Windows 98 is like a V86 manager with a GUI, thus.

I wonder, is EMM386 being loaded in both cases?
It might make a difference for the better or worse.

Modern CPUs might have trouble with supporting A20 Gate etc.
If a V86 memory manager is loaded, the situation might be better, even.
Because with a V86 memory manager (EMM386, QEMM, 386Max etc), the state of real A20 Gate nolonger matters.
The memory manager is simulating it to applications (it itself needs full mem access after all).
Windows 98SE as a VMM should simulate it all the time, thus.

My BIOS does have some kind of A20 toggle, though I don't know if it really works, as the option was originally in a hidden Advanced menu that I managed to unlock without breaking the BIOS. The BIOS was quite delicate that many modifications such as replacing microcodes and such would render it non-bootable (stuck at particular POST codes).

I'm not sure how to load EMM386 correctly with a Win98 config, though I did see some localized Win98 versions (such as Japanese) have entries in CONFIG.SYS to load EMM386, without arguments but in some cases that worked.

In the past I never succeeded in making MS EMM386 and Win3.1/9x work together so I simply leave it out. Maybe I should give it a try just I don't know if it would properly cooperate with about 1.4GB of RAM. That's the amount of the RAM the system has, below 4GB boundary.

LSS10999 wrote on 2025-03-23, 04:32:

I'm not sure how to load EMM386 correctly with a Win98 config, though I did see some localized Win98 versions (such as Japanese) have entries in CONFIG.SYS to load EMM386, without arguments but in some cases that worked.

In the past I never succeeded in making MS EMM386 and Win3.1/9x work together so I simply leave it out. Maybe I should give it a try just I don't know if it would properly cooperate with about 1.4GB of RAM. That's the amount of the RAM the system has, below 4GB boundary.

Hi, it was just an idea. It came to mimd because of AMD Ryzen, which had issues with Enhanced V86 (VME).
Then I also remembered that modern CPUs nolonger have an A20 Gate.
And since the issue appears when switching between DOS sessions, I thought it could be related.

That being said, the A20 Gate issue wasn't as big of a deal as it may seem.
MS-DOS 5 and 6 have no issues with A20 being permanently open or closed.

It's rather old DOS programs from the 80s that had used source code meant to run on CP/M, originally.
These programs, when ported to DOS, had used the 1MB rollover to access routines that are at the beginning of the address range. In simple words.

But once EMM386 or any other V86 memory manager is loaded, the real A20 Gate is left open (or closed, like a circuit?; dunno) and allows addressing Extended Memory past beyond 1MB.
At this point, the A20 Gate is being simulated to DOS and DOS applications.
Which even works on modern computers that have no physical A20 Gate anymore.

That's why I've mentioned it. But again, it's just an idea.
The problem could also be related to SMM (System Managment Mode) and stand-by functionality or power savings in general. I'm not sure to be honest.

Edit: Btw, I have a CD of Japanese Windows 98SE! ^^
I'm using it in a VM, to run Japanese emulators and games that don't like foreigners/foreign systems.
It's also great for reading Japanese documents and web sites that pre-date Unicode.
Works much better than just installing far-east fonts on modern Windows (XP and up).
The EMM386 was also installed in MS-DOS/V 6.2 by default.
To make all those language drivers of DOS/V fit into memory, I think.

Btw, you can also try QEMM 9 or a similar recent version, which has Windows 95 support (=Windows 9x support).
QEMM 7.5 and up supports VME, the Enhanced V86. Hence the "Pentium supported" sticker on some boxes.
So if your processor still has VME support, everything V86 related might be smoother.

MS-DOS 6.22 and Windows 3.x and WfW aren’t VME aware yet.
EMM386 isn'nt either, I think.

But loading EMM386 in DOS before Windows might have an efffect to DOS boxes on Windows.
EMM386 might still be suspended in background and become active when Windows 9x built-in EMM functionality isn't.

It's just an idea, though. The internals of Windows 9x are very complicated.
Each component is linked to another one, like a criss cross pattern.

Just tested. Windows 98 can start fine with EMM386 loaded without any parameter, though the issue persists.

Thinking it might be related to SMM I tried disabling Legacy USB Support from BIOS but no difference, either.

SMM hasn't been ruled out yet, just that it's not caused by legacy USB's routine.

EDIT: I wonder if there is any documentation about what INT API Windows 9x's VDM would call when starting one... Probably one of those INT APIs used by Windows is responsible.

Looked at RBIL but couldn't find out which exactly would be Win9x's VDM (compared to WinNT's NTVDM).

An update on this. It seems some discussions on the VBESVGA issue tracker shed some light about the possible cause.

In fact, I'm using an nVidia card (Quadro K6000) on that system, and from the discussions, it seems nVidia's VBIOS would touch CRTC registers in a way that would cause issues with VDD's emulations.

If I use VBESVGA's VDDVBE.386 instead of Win98SE's stock VDD, Win98SE would stuck and beep at the same place as Win 3.1x 386 Enhanced Mode, except Win98SE could handle the error a bit better. Instead of hanging like Win3.1x, Win98SE would show a "Windows protection error" about VDD after the second beep allowing me to reboot the system (or shut it down).

Tried fiddling with the newly introduced "BounceOnModeset" parameter (using only VBESVGA driver, with Win98SE's stock VDD), but for now it doesn't make any difference. Maybe it needs VDDVBE.386/VBEVMDIB.3GR to actually work.

EDIT: Just test the newly released SoftGPU v0.8.2025.53 preview driver, which added baremetal VESA support. It works, and this strange behavior does not occur there. However, the performance in overall is extremely sluggish for some reasons, comparing to VBEMP9x on the same system, as well as comparing to another system with SoftGPU and an AMD video card.

EDIT2: I've updated the OP as the latest VBESVGA v0.8.2 has solved the issue on that system for WFW 3.11 386 Enhanced Mode.