DPMI issue on HAXM

[Stranger7777777]

Just found on one of several HAXM installations that FOXPRO 2.5 (and 2.6 also) for DOS (extended version FOXPROX.EXE) doesn't run. Usual FoxPro 2.5 (FOXPRO.EXE) runs just fine.
Diggin' into it I found that it can't get any of DPMI memory.
Then I found that I can't even load DOSX.EXE.
It shows message
Cannot run this 16-bit protected mode application;

The DOS extender has encountered an error initializing the extended

memory manager.

I've read that HAXM has some troubles with DPMI.
So I've tried to run it with Admin privileges... and it works!

Maybe the problem with DPMI is here?

BTW, on another machine FOXPROX.EXE works smoothly without any admin privileges, e.g. I just run .cmd file from desktop. Both machines have fresh installation of Win 10.0.1944.3570.
I've set testsigning on and imported certificates by recomendations from HAXM.TXT.

I've tried uninstalling haxm and installing it back without any luck.
I've tried CCPU version also. It works normally but way too slow.

Running foxprox.exe with admin privileges sets the default directory to %windir%/system32 instead of a setting in desktop shortcut.

Could I provide some more information that may help?

[leecher1337]

You can try to install debug build and use a debugger like x32dbg to set breakpoint at haxm_alloc function, which does an IOCTL to the haxm driver to allocate memory blocks:

GLOBAL VOID haxm_alloc(
    IN sys_addr Low,
    IN sys_addr Size
)
{
	struct hax_alloc_ram_info alloc_ram = { 0 };
	DWORD bytes;

	alloc_ram.size = Size;
	alloc_ram.va = Low;
	if (!DeviceIoControl(hVM, HAX_VM_IOCTL_ALLOC_RAM, &alloc_ram, sizeof(alloc_ram), NULL, 0, &bytes, NULL))
	{
		//haxmvm_panic("HAXM: Error allocating RAM: size = %d, base = %08X, va = %08X, gle = %d", 
		//	Size, Start_of_M_area, Start_of_M_area + Low, GetLastError());
	}
}

Or you can use DebugView to get output of HAXM on memory allocation requests, maybe it fails for some reason on the target machine. You may need to build a debug-version of the driver for mor detailled debug information.
Maybe there is some memory allocation error for specific users with specific credentials.
Allocating memory in haxm basically calls internal hax_vm_add_ramblock. But why it fails dependent on user privileges is a bit of a mystery to me, should it really be caused by that.

The error you encounter is ER_NOHIMEM. This menans routine SetupHimemDriver from dxboot.asm fails.
You can check if XMS driver is even present:

        mov     ax,4300h
        int     2Fh
        cmp     al,80h
        jnz     sthd80  ; Jump on error

So output on my machine (currect, al = 80h, as you can see):

c:\windows\system32>debug
-a
0EEB:0100 mov ax,4300
0EEB:0103 int 2f
0EEB:0105
-p

AX=4300  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=0EEB  ES=0EEB  SS=0EEB  CS=0EEB  IP=0103   NV UP EI PL NZ NA PO NC
0EEB:0103 CD2F          INT     2F
-p

AX=4380  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=0EEB  ES=0EEB  SS=0EEB  CS=0EEB  IP=0105   NV UP EI PL NZ NA PO NC
0EEB:0105 6E            DB      6E
-

Is it 80h also on your machine with the error?
Of course, if DOSx fails to start, no DPMI memory allocation functions available.

XMS services generally are communicating with the NTVDM via BOP_XMS (0x52), so this is MS_bop_2 which in turn does XMSDispatch. So you can hook this function in NTVDM.EXE and check if some functions go wrong there.

I guess it is a bare metal machine so there is no possiblity for me to have a look at the machine myself.

[Stranger7777777]

I can provide anydesk (or something similar for remote access) for exapmle on the target machine

[leecher1337]

Hm, you can drop me a private e-mail with access data. I may have time to quickly look at it on sunday.
HAXM version checked (debug) build including symbols should be installed.