That's indeed strange. "Packed file is corrupt" is a well-known message, because one reason this message might appear is that the classic "EXEPACK" implementation might fail with that message on perfectly fine files if the high memory area is accessible during the initialization of the file. The MS-DOS kernels starting with MS-DOS 5 (maybe 4?) handle this problem, and temporarily disable the HMA while the EXE file is unpacking. You should never see this message for this reason on a MS-DOS 6.22 system, unless you have some other resident program loaded that interferes with the kernel logic that should reliably prevent this problem.
For troubleshooting, I suggest:
- Disable "DOS=HIGH" in config.sys. This will fully eliminate the "classic reason" why you might see "packed file is corrupt" if all software and hardware components are operating properly.
- If you are using EMM386, test whether the issue disappears without EMM386.
- Run the same version of MSCDEX from a floppy instead of the hard drive, to check whether the SCSI controller makes trouble.
- Copy the MSCDEX.EXE from that system back to an internet connected system and verify that the file has not been damaged during transfer.
- Load a different amount of programs before MSCDEX (e.g. load SMARTDRV before MSCDEX if you didn't do so now, or the other way araound). After troubleshooting, if you are using SmartDrive at all, do load it after MSCDEX, because SmartDrive from DOS 6.x will cache CD data in that case.
You might also want to run MEMTEST+ 4.1 (newer versions are incompatible with 486 systems and crash on boot) to check for general system stability. While the program targets memory, it will usually indicate if anything is wrong on the front-side bus, the L2 cache, the RAM timings or the RAM itself. It's possible that something in the system is marginal and started to misbehave enough to cause some random failures with MSCDEX failing to load just being the first easily observable issue. If you CPU has a fan, check that the fan is working.
