• Please review our updated Terms and Rules here

A PC Stable under Win9x but not WinNT!

F

fargo

Experienced Member
Joined
Dec 6, 2019
Messages
82
I have a Pentium 3 600MHz computer with 512MB PC100 RAM. The computer can flawlessly run DOS and Windows 9x/ME, but not Windows NT/2K nor modern Linux distros! It randomly restarts on or shortly after loading the Windows NT/2K GUI.

I tested the memory and found no errors. I even changed the dimms, but got the same result: sudden restarts under WinNT/2K and modern Linux. I played with BIOS settings, such as disabling/enabling caches and other features, but that didn't help.

It seems that the problem has something to do with the video because the restarts happen in GUI only not in text mode. The computer has an embedded AGP video card (Trident 9525). It has 4 PCI slots, but I don't have a PCI video card to test with.

Any idea what could be the problem here? Could it be related to PSU or capacitors? Also, what it's the difference between Win9x and WinNT GUIs?
 
You might have a (slightly) bad CPU.

I've had weird stuff happen like that before, such as a 6x86 PR200+ CPU that worked perfectly fine with DOS and Windows, but when I booted NetBSD and tried to compile something using gcc, it would reliably die with an "illegal instruction" error. Swapped the CPU for a K6-2 200Mhz, leaving everything else the same, and the errors disappeared.

My theory is that DOS and Win9x have a lot of 16-bit real mode code and their 32-bit protected mode is somewhat simplistic, whereas an OS like NT or *BSD is much more complex and exercises a larger portion of the CPU's protected mode functionality.
 
Of course, DOS is pretty much all 16-bit code; Windows 9x does have some 32-bit drivers, but NT is all 32-bit code--the same for Linux. And yes, it could be your video card as well.

I've had similar issues with 64 bit code--one mobo would run just fine with AMD64 Linux and a different one would bomb using the same memory and CPU. Either ran fine in 32-bit mode. Never did figure that one out.
 
Thank you guys. I found a CPU on eBay that can fit in my PC, which is a Dolch computer using slot 1 and property heatsink. I'll try installing Win2K once that arrives and see.
 
Probably best to try a Linux boot cd/dvd distro first to see if that cashes and burns. It'll save you a bit of time seeing if it works with a full 32-bit OS.
 
I'm pretty skeptical the CPU is the problem here. My first vote would probably be to try disabling the built-in Trident video(*) and going with a PCI card, but I wouldn't rule out some kind of age-related instability; Pentium III-vintage machines are pretty prime-time for iffy capacitors.

(* Driver support for those Trident cards was generally atrocious and they usually only showed up in "consumer" PCs that ran Win9x variants so it wouldn't surprise me much if the NT/2000 drivers are garbage, and if you're trying "modern" Linux there could well be some bit-rot or general badness in those drivers as well.)
 
@Caluser2000: the computer failed booting an old version of Puppy linux distro. It also failed the latest version, but could boot the version before the latest one! The only issue with the working version was that screen resolution couldn’t be adjusted; fixed at 640x480.

@Eudimorphodon: Dolch manufactured “industrial” computers back in the day. It used industrial motherboards to build luggable machines. The computer I have came with WinNT 4.0 installed. It failed to boot and I thought it was a software issue. So, I wiped the HD and tried to install Win2k. The setup program of Win2k failed to complete as it was unable to continue to the GUI part after formatting the HD. I’ll try to source a PCI video card for testing.
 
kdr said:
You might have a (slightly) bad CPU.

I've had weird stuff happen like that before, such as a 6x86 PR200+ CPU that worked perfectly fine with DOS and Windows, but when I booted NetBSD and tried to compile something using gcc, it would reliably die with an "illegal instruction" error. Swapped the CPU for a K6-2 200Mhz, leaving everything else the same, and the errors disappeared.
Click to expand...
You did not have a bad CPU. The Cyrix 6x86 simply lacked some of the P5 opcodes, that's it. It was rather gcc not being aware of the CPU's limitations - thought there was most likely a compiler option for this.
 
Timo W. said:
You did not have a bad CPU. The Cyrix 6x86 simply lacked some of the P5 opcodes, that's it. It was rather gcc not being aware of the CPU's limitations - thought there was most likely a compiler option for this.
Click to expand...

That's what I thought at first, but this was NetBSD 1.4.2 from circa 2001, and the release binaries for 1.4 series are compiled for i386 without hardware floating point........ the "illegal instruction" exception was bogus and left CS:EIP pointing at a completely benign instruction. And this was a CPU that was happily doing DOS gaming and booting into Win95 with absolutely zero issues.

I'd certainly check everything else in a system before suspecting the CPU, but... sometimes it really *is* the CPU that's gone bad!
 
For the OP's computer, I'd verify that the PSU was good, and then maybe recap the motherboard. Old tired power supplies and capacitors can cause a myriad of phantom issues that makes random bits of hardware not work entirely correctly.

If a system can run DOS and Windows 9x, but not NT, it usually means an underlying hardware issue. DOS and Windows 9x are far more forgiving of hardware problems than Windows NT and Linux are. I've had systems with marginal power supplies and bad capacitors that ran the former two OSes fine, but would crater with anything more advanced.

kdr said:
That's what I thought at first, but this was NetBSD 1.4.2 from circa 2001, and the release binaries for 1.4 series are compiled for i386 without hardware floating point........ the "illegal instruction" exception was bogus and left CS:EIP pointing at a completely benign instruction. And this was a CPU that was happily doing DOS gaming and booting into Win95 with absolutely zero issues.

I'd certainly check everything else in a system before suspecting the CPU, but... sometimes it really *is* the CPU that's gone bad!
Click to expand...

If we're still talking about the Cyrix, then I would blame them rather than your specific CPU. Cyrix made a lot of poor design decisions when designing the 6x86 core. While it was supposed to be a Pentium class processor, in reality it was somewhere between a 486 and Pentium in terms of instruction sets and features, with the FPU being more or less a straight copy from their Cx486. Almost immediately when it was released, people were reporting bugs with the CPU that were consistent across basically all parts that Cyrix was releasing, which had to be worked around in software. There were quite a few Cyrix specific software patches released for software and Windows 9x to fix quirks that caused system crashes or general instability. The 5x86 was a lot worse, it was based on the early 6x86 and had a lot more trouble in design. As a result, promised features of the processor were cut and disabled due to causing the CPU to be unstable. Some people over at Vogons have done a lot of work using special utilities to re-enable certain features of the 5x86 to increase performance and identify which mask revisions are stable with which features enabled.

It wasn't until some of their final MII parts did a lot of the bugs were worked out of the design, but by that time, Cyrix had been taken over by NSC and run into the ground.

Any Cyrix CPU today is known to not work well with anything past Windows 9x. Windows 2000 and XP are a stretch, especially with later service packs. I have a NSC Geode GX1, which is essentially a Cyrix MediaGX, itself based on the 5x86. Even with all of the refinement over the years, it still has the same problems as its parent processors and isn't really 100% compatible with the Pentium.
 
For the OP: I've had another thought. Your problem could be related to ACPI. Win95 doesn't support ACPI and Win98 only has partial ACPI support, so they might be "immune". If your BIOS has bugs in the ACPI tables, it could cause all sorts of trouble with the more modern OSes that support all of the ACPI features.

Is there a BIOS update available for your machine?


GiGaBiTe said:
DOS and Windows 9x are far more forgiving of hardware problems than Windows NT and Linux are. I've had systems with marginal power supplies and bad capacitors that ran the former two OSes fine, but would crater with anything more advanced.
Click to expand...

Yep, DOS especially is very tolerant of problems! It hardly pushes a post-486 system anywhere near its limits.


GiGaBiTe said:
Any Cyrix CPU today is known to not work well with anything past Windows 9x. Windows 2000 and XP are a stretch, especially with later service packs. I have a NSC Geode GX1, which is essentially a Cyrix MediaGX, itself based on the 5x86. Even with all of the refinement over the years, it still has the same problems as its parent processors and isn't really 100% compatible with the Pentium.
Click to expand...

Good to know, thanks. I suppose it's possible that I was hitting a CPU bug instead of a previously-good CPU going bad. The binaries had been compiled for i386 and weren't using any of the new instructions introduced in the 486/Pentium/PPro architectures, but 80386 protected mode is famously complex and I can see how a relatively obscure operating system could be hitting bugs in a "clone" CPU's microcode.
 
fargo said:
@Eudimorphodon: Dolch manufactured “industrial” computers back in the day. It used industrial motherboards to build luggable machines. The computer I have came with WinNT 4.0 installed. It failed to boot and I thought it was a software issue. So, I wiped the HD and tried to install Win2k. The setup program of Win2k failed to complete as it was unable to continue to the GUI part after formatting the HD. I’ll try to source a PCI video card for testing.
Click to expand...

I’m reasonably familiar with Dolch, I had one for a while, a 200mhz Pentium model. I guess it wouldn’t occur to me to make any assumptions about what OS would be implied by its “Dolch-ness” because an industrial machine can run almost anything. The one I had was set up as a network analysis box and it bootstrapped its proprietary software off of plain old DOS.

The Dolch I had used a bog-standard AT form-factor motherboard with a lousy (well, “limited”) C&T-chipset PCI card allowing it to directly drive the LCD. If I google that Trident chip in yours most of the hits mention Toshiba laptops, so I assume that chip also having LCD direct drive is why they chose to integrate it. It’s a bad sign if the original software was still on the thing but malfunctioning the same way as your replacement attempts; to my mind that bolsters the case for hardware failure of some kind, although the fact you apparently can get a Linux to work at 640x480 still leaves open the possibility of driver issues. Have you tried booting a Linux that goes to text mode, not the GUI, and looking at what gets logged when you manually “startx”?
 
kdr said:
Yep, DOS especially is very tolerant of problems! It hardly pushes a post-486 system anywhere near its limits.
Click to expand...

It's more that DOS doesn't have any concept of memory protection or multitasking. A whole lot can be wrong with the system as long as the DOS structures and memory area aren't bothered and the system will keep on trucking. Once you start using DPMI/VCPI, things can change though.


kdr said:
Good to know, thanks. I suppose it's possible that I was hitting a CPU bug instead of a previously-good CPU going bad. The binaries had been compiled for i386 and weren't using any of the new instructions introduced in the 486/Pentium/PPro architectures, but 80386 protected mode is famously complex and I can see how a relatively obscure operating system could be hitting bugs in a "clone" CPU's microcode.
Click to expand...

I did a bit of reading on this to refresh my memory. So, not only does the binary need to be compiled for i386/i486, so do the dependencies. If you have dependencies and a kernel compiled for i586/i686 that the binary you're using references, the Cyrix can choke up on these and crash. I guess the best way to work around that would be to statically link dependencies and incorporate them in the binary to avoid using external deps that may be compiled for newer architectures.
 
GiGaBiTe said:
So, not only does the binary need to be compiled for i386/i486, so do the dependencies. If you have dependencies and a kernel compiled for i586/i686 that the binary you're using references, the Cyrix can choke up on these and crash.
Click to expand...

It was an ancient version of NetBSD, 1.4.2, and the entire system (kernel and userland) had been compiled using -mcpu=i386 to generate pure 80386 code, so there weren't any i586/i686 instructions to trip up the Cyrix. Regardless of whether it was caused by a Cyrix microcode bug or a Cyrix CPU that had gone bad, the end result was that I had a machine which worked perfectly fine for DOS and Windows but which failed when running something more exotic. It wasn't just a run of the mill "CPU doesn't support that instruction". Swapping the CPU while leaving everything else the same fixed the issue.
 
You must log in or register to reply here.
Back
Top