some old version of systernals autoruns 8.73 or del reg key might do the trick

Does this information help? https://www.raymond.cc/blog/manually-reset-or … without-chkdsk/
I'm not sure if it applies to NT4. Also, they are resorting to a boot CD to edit their system partition because their hex editor isn't capable... I would suggest using Roadkil's sector editor to bypass that problem.

Another thought is that you could try replacing CHKFAT32.EXE with another Win32 console program that simply does nothing. (Or gives you the option to run CHKFAT32 or not)

I deleted chkfat32.exe and NT4's blue screen still runs CHKFAT32 when booting. That's really curious.

I then compared all registry entries for "fat32" for the case of a) fresh install of sysinternals FAT32 for NT, b) configuration in which NT keeps checking my HDD at boot and finding "orphaned" clusters. There was no difference in these registry entries. Thus I must conclude that the flag setting to check my FAT32 partitions at boot is elsewhere. Unfortunately, I don't know where.

For this reason, I have uninstalled winternals FAT32 for NT4 and and now using FASTFAT32 to read my fat32 partitions from within NT4. I'll see if a similar issue emerges. So far so good.

feipoa wrote on 2021-08-25, 10:37:

I deleted chkfat32.exe and NT4's blue screen still runs CHKFAT32 when booting. That's really curious.

Did you check out the info on the link that bakemono commented ?

bakemono wrote on 2021-08-09, 15:22:

Does this information help? https://www.raymond.cc/blog/manually-reset-or … thout-chkdsk/2/

weedeewee wrote on 2021-08-25, 11:22:

feipoa wrote on 2021-08-25, 10:37:

I deleted chkfat32.exe and NT4's blue screen still runs CHKFAT32 when booting. That's really curious.

Did you check out the info on the link that bakemono commented ?

bakemono wrote on 2021-08-09, 15:22:

Does this information help? https://www.raymond.cc/blog/manually-reset-or … thout-chkdsk/2/

I read it briefly but decided it was not the most desirable type of solution and there is no certainty it would apply to winternals FAT32 for NT.

Assuming the winternals dirty flag is at the same location as the Windows dirty flag for FAT32, I would need to, according to that link, track down the dirty bit (for FAT32 only) at offset 41 (5 down, 2 across) to see if the value is 01, then change it to 00. As I didn't want to go through that step each time I have a hard reset or other application hang up, I decided it best to try fastfat32 first then revisit the HEX edit approach as a last resort.

feipoa wrote on 2021-08-25, 23:24:

I read it briefly but decided it was not the most desirable type of solution and there is no certainty it would apply to winternals FAT32 for NT.

Assuming the winternals dirty flag is at the same location as the Windows dirty flag for FAT32, I would need to, according to that link, track down the dirty bit (for FAT32 only) at offset 41 (5 down, 2 across) to see if the value is 01, then change it to 00. As I didn't want to go through that step each time I have a hard reset or other application hang up, I decided it best to try fastfat32 first then revisit the HEX edit approach as a last resort.

You might have looked a bit too briefly at it, since it has a section called

Clear the Dirty Bit for a FAT32 Volume […]
Show full quote

Clear the Dirty Bit for a FAT32 Volume

Finding and clearing the dirty bit for a FAT32 file system is far easier than NTFS because it’s located right at the start of the volume and is always at the same offset location. Here’s how to clear it.
Read More: https://www.raymond.cc/blog/manually-reset-or … thout-chkdsk/2/
...

fyi, it's on the second page to which I had sneakily linked.
and somehow the link sneaked into this quote?!

Did you read my second paragraph? I read page 2 before I posted my reply above. This is how I knew offset 41 was the one to look for. However, I do not wish to clear this HEX value each time I have an error. I decided that it was easier to try fastfat32 first, then revisit HEX editing if both programs exhibit the same symptoms.

feipoa wrote on 2021-08-25, 23:50:

Did you read my second paragraph? I read page 2 before I posted my reply above. This is how I knew offset 41 was the one to look for. However, I do not wish to clear this HEX value each time I have an error. I decided that it was easier to try fastfat32 first, then revisit HEX editing if both programs exhibit the same symptoms.

Ha! no I didn't, I just glimpsed at it :-p
I'm off to bed. Goodnight 😀