Yeah there is a system.ini directive something like emmexclude= but I dont recall the exact syntax

I think in the [386Enh] section of SYSTEM.INI

1EMMExclude=D000-DFFF

OP has a 286, so [386enh] section won't be parsed.

I wonder if you'd have any luck using one of the utilities that predates MS-DOS 5.0 built-in UMB support, so that it would be invisible to Windows. "LOADHI" came to mind and looks like that was part of QEMM, so I don't know if it will play nice with 286 UMBs as opposed to 386 ones.

jakethompson1 wrote on Yesterday, 20:25:

OP has a 286

D'oh! Missed that part.

But in Standard Mode, Windows shouldn't be using EMS. However, while I'd had 8086 and 80186 systems, I never really had an 80286 and so skipped the whole LIM4.0 board type stuff. I basically knew it existed and that's it.

This isn't EMS. But what happens is that UMB_DRVR or USE!UMBS implement a tiny part of XMS, specifically allocate/free an upper memory block. When DOS boots and sees DOS=UMB in config.sys, it will keep invoking that XMS API after every driver is loaded to see if any UMBs are available. If so, it takes all of them for later use with devicehigh/loadhigh and manages subsequent individual allocations itself. I believe the UMBs also end up exposed through the normal DOS memory allocation functions (not just explicit devicehigh/loadhigh) and perhaps Windows is calling those to grab all memory in its boot process and that includes the UMB memory.

Therefore it appears that Windows is actively trying to allocate memory in the UMB region rather than simply ignoring it.

Yes, it does that. Windows applications do, too.
There's an utility that prevents them from using the memory below 1 MB (fix1mb.zip). Can be found here.

But in Standard Mode, Windows shouldn't be using EMS. However, while I'd had 8086 and 80186 systems, I never really had an 80286 and so skipped the whole LIM4.0 board type stuff. I basically knew it existed and that's it.

Hi, Windows 3.1 in Standard Mode doesn't touch EMS, I think.
Whatever memory managers are active remain in control.
Unlike Windows 3.0, Windows 3.1 is more tolerant to VCPI, DPMI and so on.
Only 3.1 Standard Mode kernal works in a DESQView/X session, for example. And DESQView in turn makes heavy use of EMS (DESQView assumes QEMM to be available).

About EMS and Windows.. I do have a rather unpopular opinion here, perhaps, but I think Windows 2.x is better suited for real EMS hardware.

That's because Windows 2.x simply wants a memory manager that supports LIM 4.0 or EEMS (-on EMS 3.2 or later hardware-),
while Windows 3.0 kernal can't do much with a normal 64 KB page frame (small page EMS).

It rather wants a big 256 KB page frame (large page EMS) to swap in/out applications.
That one is provided by EMM386, if MemMaker was run (EMS enabled; with the setting to optimize memory for Windows).

If Windows 3.0 finds a normal page frame (286 chipsets, Lo-Tech EMS, AST RAMPage etc), it will hesitate to use EMS.
The details can be seen in the about dialog of Program Manager.

PS: To my knowledge, applications that make heavy use of EMS on Windows 2.x are Page Maker 3 and WinWord, for example.
When I tested my 2 MB EMS card, WinWord almost ate all EMS after loading a sample document with pictures!

So I think going for a 4 MB model or expanding a 286 that has chipset EMS isn't insane, really.
The Lo-Tech driver supports that amount (almost, a few KB less) and PicoMem and some experimental EMS card have 4 MB support.
GeoWork Ensemble makes good use of EMS, too, of course.
Here's a video I saw once: https://www.youtube.com/watch?v=4EzCCTPdAM4

Jo22 wrote on Yesterday, 22:17:

There's an utility that prevents them from using the memory below 1 MB (fix1mb.zip). Can be found here.

Thanks for the hint!
Will give it a try next week, hoping that is working on a 286 (most utilities are not, requiring at least a 386).

Regarding EMS:
I've checked and Windows 3.1 is not corrupting the memory area D000:0000 - D000:FFFF when this one is reserved as an EMS pageframe
(I've used a software LIMulator for testing);
Having 4MB on the motherboard I keep the EMS as an option for the boot multimenu, but it is just for programs requiring EMS.
This is not the main purpose of my UMB RAM card, which is intended to create real UMBs for DOS Drivers (lacking the 286 of virtual mode, i'm stucked to real mode).

My target is to keep the possibility to start Windows (in standard mode, having a 286), without memory corruption; the above mentioned utility looks promising.