[BUG] Data corruption occurs upon exiting NSSI

[ppgrainbow]

I ran Navrátil Software System Information under one of the latest revisions of PCem by typing NSSI at the MS-DOS prompt. NSSI collects information about the computer that you're running.

However, this is what could be irritating me, when I exit NSSI and return to the MS-DOS prompt, massive data corruption occurs in the NSSI directory and possibly other directories as well - regardless of any drivers (enabled or disabled) that I have installed in the CONFIG.SYS or AUTOEXEC.BAT files! This issue can occur if I run NSSI from Windows 3.1 and exit the utility too.

Here's a screenshot for proof:

Data corruption in the \NSSI directory occurring after exiting NSSI.

data corruption.png (56.23 KiB) Viewed 9169 times

This issue doesn't occur on older emulated models such as the Compaq Deskpro 386 as far as I know. So this might be a emulation bug. If so, please fix the issue.

Thanks!

[leilei]

I've had similar data corruption after running DOS 6.22's undelete on a 360kb floppy image (Cx486dx40 on sis496). It would freeze on the undelete and show a corrupted dir outut after restarting and chekcing the disk. Sadly I couldn't reproduce these steps =(

[ppgrainbow]

I've had similar data corruption after running DOS 6.22's undelete on a 360kb floppy image (Cx486dx40 on sis496). It would freeze on the undelete and show a corrupted dir outut after restarting and chekcing the disk. Sadly I couldn't reproduce these steps =(

I think that I finally solved my problem!

The AMI WinBIOS 486 is an ISA-only based machine. One of the video adapters that I selected is PCI-based and it will NOT work correctly with the WinBIOs 486. So, I had to use the Trident 8900D graphics card and...well, what do you know. No more data corruption!

[Battler]

- ppgrainbow: More like I suspect that graphics card's (Trident TGUI 9440) BIOS is messing things up, it might be a video BIOS bug as well. Or, alternately, something in that card's code is writing out of bounds and causing other parts of the emulator to get trashed. That card is definitely not PCI-only.

[ppgrainbow]

- ppgrainbow: More like I suspect that graphics card's (Trident TGUI 9440) BIOS is messing things up, it might be a video BIOS bug as well. Or, alternately, something in that card's code is writing out of bounds and causing other parts of the emulator to get trashed. That card is definitely not PCI-only.

Thanks for telling me. I'd stick with ISA video cards for the time being.

[Battler]

- ppgrainbow: It's a bug with the specific Trident card. Why not try the Phoenix S3 Trio64 (which incidentally, also had a VLB version) and see if the same corruption happens.

[ppgrainbow]

- ppgrainbow: It's a bug with the specific Trident card. Why not try the Phoenix S3 Trio64 (which incidentally, also had a VLB version) and see if the same corruption happens.

The Phoenix S3 Trio64 works with the AMI WinBIOS 486.

I will ditch the Trident 8900D graphics card for the Phoenix S3 Trio64 to see how it works in the long run.

Update: The VLD-based Phoenix S3 Trio64 works but running CHKDSK from the MS-DOS prompt under Windows 3.1 throws random CHKDSK errors such as:

"16 lost allocation units found in 16 chains.
524,288 bytes disk space would be freed"

"C:\WINDOWS\SYSTEM\WIN32S
Invalid sub-directory entry

147 lost allocation units found in 64 chains.
4,816,896 bytes disk space would be freed"

I believe that this issue also occurs on the Trident TVGA8900D too. Can we investigate what could be causing the random data corruption issues to occur regardless of what graphics card I'm using on the WinBIOS 486? I'm wondering if it has to do with memory mamangers such as EMM386 or QEMM386.

The DR-DOS 6.0 version of CHKDSK eventually disabled the ability to check the drive for errors using CHKDSK when I'm running MS-DOS prompt under Windows 3.x.

[Battler]

- ppgrainbow: I wouldn't be surprised if it was caused by Win32s, as that's known to be an unstable mess.

[ppgrainbow]

- ppgrainbow: I wouldn't be surprised if it was caused by Win32s, as that's known to be an unstable mess.

That's what I could be thinking all along. I'm using the latest version of Win32s, I will either have to:

1. Use the DR-DOS 6.0 version of CHKDSK to prevent disk from being checked inside the MS-DOS prompt under Windows 3.x.
2. Disable Win32s by removing any references to files; if the problem persists even if Win32s is disabled, I'll get back to you.

[leilei]

In my corruption incident, neither Windows nor a PCI video card were involved (ET4000AX is ISA)

[ppgrainbow]

In my corruption incident, neither Windows nor a PCI video card were involved (ET4000AX is ISA)

Earlier today, I tried to disable Win32s, but for some reason, the corruption persisted when I used CHKDSK in a MS-DOS prompt under Windows 3.1. I'm guessing that this might pin down to the use of expanded memory managers present.

[ender]

The VLD-based Phoenix S3 Trio64 works but running CHKDSK from the MS-DOS prompt under Windows 3.1 throws random CHKDSK errors such as:

From what I remember from my Windows 3.1 days, you should never run chkdsk from within Windows, because it would find all sorts of weird things.