Does this thread help?
32 Bit Disk Access drivers on a 2 GB Windows 3.1 Hard disk.

Windows 3.1x isn’t completely on board with 32 bit file access on storage devices > 512 MB. You need to update some the 32bit file access subsystem.

I would use this driver when using 32 bit file access with storage devices larger than 512MB on Win 3.1x:
https://www.vogonsdrivers.com/getfile.php?fileid=2070

Edit: Also some of the older promise bios and drivers are not compatible with larger storage devices.
Are you using this promise bios? https://www.vogonsdrivers.com/getfile.php?fileid=1817
And these promise drivers? https://www.vogonsdrivers.com/getfile.php?fileid=2012

Yes. My card has the BIOS with LBA support, and I am using those promise drivers.

WFW 3.11 is happy with the configuration so long as I have an entry for the Primary Slave in the mobo BIOS.

OK Thanks for clarifying that. Let’s think this through….

When the promise bios kicks in, it should overwrite the bios drive table with the values stored on the card or autodetected at boot time. It sounds like Windows 3.11 is not seeing that entry or not able to interpret the entry that the promise bios puts in place. I think the second case is more likely.

Do you have the LBA patch for Windows 3.1 installed? Maybe the promise lba bios is entering something that Windows 3.11 can’t handle.

Appreciate your time, douglar.

At this time, the only things I have done for WfW 3.11 + 32-bit file access are:

Remove from [386Enh] section of system.ini -
device=*wdctrl
device=*int13

Add to [386Enh] section of system.ini -
device=C:\EIDE4030\PTICTRL.386
device=C:\EIDE4030\PTI13.386
32BitDiskAccess=ON

The blue screen I get states: "The Program tried to access your hard disk in a way that is incompatible with the Windows 32-bit disk-access feature (WDCTRL). This may cause your system to become unstable."

And boy, does it ever cause my system to become unstable (freeze).

At first, I was confused that it referenced WDCTRL as I had removed it from system.ini. However if you load PTICTRL.386 in a hex editor, you'll see that it contains that exact error message.

And again - all is fine with DOS and Windows AND 32-bit disk access so long as I have an entry for Primary Slave in the mobo's BIOS... which is weird... as I feel like Promise should be taking full control of disks and their geometry. Set Primary slave to NONE in the mobo BIOS, and the second hard drive still shows up in DOS and in WfW without 32-bit disk access.

Have you read through this? https://www.os2museum.com/wp/how-to-please-wdctrl/

I'd really consider installing the Win3.1 LBA driver if you are using LBA capable BIOS.

https://www.vogonsdrivers.com/getfile.php?fileid=2070

Are you suggesting that that Promise driver is just buggy?

AFAIK, I have to use the Promise driver in order to see drive 2 and drive 3 in addition to drive 0 and drive 1.

I suppose I could try the generic Microhouse driver and see what happens. I suppose it is possible that the Promise 3.33 drivers found online aren't the latest version available, either.

tbh, I don't really see my Windows for Workgroups 3.11 32-bit Disk Access as the problem. I was hoping to figure out the "Missing Operating System" issue at boot (assuming there is a way to do that).

CkRtech wrote on 2025-05-27, 00:44:

Are you suggesting that that Promise driver is just buggy? […]
Show full quote

Are you suggesting that that Promise driver is just buggy?

AFAIK, I have to use the Promise driver in order to see drive 2 and drive 3 in addition to drive 0 and drive 1.

I suppose I could try the generic Microhouse driver and see what happens. I suppose it is possible that the Promise 3.33 drivers found online aren't the latest version available, either.

tbh, I don't really see my Windows for Workgroups 3.11 32-bit Disk Access as the problem. I was hoping to figure out the "Missing Operating System" issue at boot (assuming there is a way to do that).

The "Missing Operating System" sounds like the computer is trying to boot from the wrong drive. I can't imagine any drive geometry screw up could cause that issue, but maybe I lack imagination here. Why would it try to boot from the wrong drive? Maybe there's some intermittent failure going on with the primary drive? Edit: OK, while the MBR would still be in the same spot, maybe the DOS partition wouldn't be visible if things were switching between LBA and CHS.

I wasn't saying that the Promise driver is buggy. I was saying that it might be trying to set up the drive in the drive table as LBA when the drive is not set up in the drive table by the motherboard BIOS and that's freaking out parts of the Windows 3.1's protected mode file system components because they don't understand LBA. I thought the MicroHouse drivers replace more than just the driver for the hard drive controller. I could be wrong.

Well… I decided to press F2 to enter the Promise Cache Setup Utility each time I boot just to see if anything changes.

GUESS which one leads to Starting MS-DOS and which one leads to Missing Operating System…

EDIT: I set both drives to NORMAL (CHS) in the mobo BIOS, and this seems to have solved the problem. Promise Cache Setup lists them by their proper LBA values each boot. System boots every time. Windows 32-bit disk access works. I suppose I could try to run some tests or copy some files for corruption tests or something.

OK, that sounds like a reasonable solution. Sounds like the drives were partitioned using CHS geometry and when the card populated the missing entries DOS drive table, sometimes it used LBA info, and that was going to cause problems.

Checking your storage allocation tables is a great idea. Chkdsk would probably be a good first line of testing.

Both drives were partitioned and formatted under MS-DOS 6.22 with LBA in both the mobo BIOS and the Promise BIOS.

However now... they are both NORMAL in the mobo BIOS and LBA in the Promise BIOS.

Ultimately, only the Promise BIOS (should) matter. In fact, the Promise manual states:

For new disk drives, simply select Type 1 for the corresponding drive. Your EIDE4030Plus BIOS will auto-recognize your IDE disk drive. For existing conventional IDE drives, use the same drive type settings used on your previous controller.

By "new" at the time, I assume they mean drives with geometry that can be autodetected.

Sadly, selecting "Type 1" in my mobo BIOS will freeze before the Promise BIOS does its thing.

Using NORMAL in the mobo BIOS appears to allow the Promise BIOS to be successful at detecting the drives every single time, and the Promise BIOS reports them with their LBA geometry.

If Promise states "yeah just set new drives to Type 1," then I assume that means they will handle all Int13h/hard drive stuff, and incorrect drive geometry in the mobo BIOS won't matter.

ok, thanks for explaining that.

The promise bios should overwrite the interrupt vector table INT 41h / 46h for drives 1&2 to present its own drive info, overwriting what the motherboard bios presents. not exactly sure how drives 3&4 work, but I remember they worked differently. Seems like the promise bios was having intermittent problems when the motherboard bios was set to lba. sometimes. Anyone with more knowledge about these things care to take a guess as to why this happens?