Real DOS returns an error code to the calling program when memory allocation/deallocation functions fail due to a corrupt MCB chain. However, the system will likely be halted if/when the program tries to exit back to DOS with a corrupt MCB chain, where there will be a message like "Unable to load COMMAND.COM, system halted".

DOSBox's internal emulation of DOS has an error exit when the MCB chain is found to be corrupt during a memory function. FYI, an error exit in DOSBox is not a "crash" in the strict sense -- it informs the user that the system has become unstable before an actual crash occurs.

Given the above difference in how memory chain corruption is handled, have you tried your test case(s) in real DOS with UMBs? And remember that in real DOS all programs must be exited back to DOS with no halting of the system for there to be no issue.

Thanks for your reply, @ripsaw8080! I've done some further testing and the plot thickens!

Test 1

Real hardware with MS-DOS 6.22 (see my signature). Running the intro when UMB is available does not crash the machine, but consumes all available UMB (MEM reports zero after running it once). The "ZIP test" works fine. I can start the intro for a second time, and things still appear normal. If I start it a third time, though, I get some random chars printed on the screen when I try to exit it, then one beep, and the machine hangs.

I repeated this several times after rebooting and it's consistent; the system crash happens after exiting the intro exactly for the 3rd time.

Interestingly, I'm getting the same behaviour both with UMB and without it, with only conventional memory.

Test 2

Now this gets interesting! When I use real DOS in DOSBox SVN via an HDD image, I get no crashes whatsoever with UMB either enabled or disabled. Although all UMB memory gets consumed after running the intro, I can run it any number of times and I get no crashes and the "ZIP test" always works. So the MCB chain doesn't get corrupted.

I have attached the repro pack on a minimal HDD image for your convenience. Just start DOS Navigator with DN, then follow the repro steps from my original
post.

This proves there is definitely a difference between running real DOS in DOSBox SVN or on real hardware versus the emulated DOS environment of DOSBox. Of all three, the emulated DOS environment with UMB enabled is the "most crash prone". Interestingly, running real DOS in DOSBox seems to be the most stable; it's actually more stable than real hardware in that particular case! I'm not sure I want it to mimic the hardware behaviour in this case 😀

Anyway, maybe this points to some fundamental issue about memory handling in the emulated environment which will perhaps lead to better emulation and/or stability if it gets rectified (if there's anything to rectify, that is).

ripsaw8080 wrote on 2023-06-20, 15:02:

Given the above difference in how memory chain corruption is handled, have you tried your test case(s) in real DOS with UMBs? And remember that in real DOS all programs must be exited back to DOS with no halting of the system for there to be no issue.

Just wondering if you've had a chance to investigate this further perhaps using the provided HDD image repro pack?

I guess it's not a deal-breaker in the sense that one can simply disable UMB and nothing of major value is lost (as you don't really need to load any drivers in DOSBox anyway), but it's an interesting one for sure.

Plus most (all?) games don't care about UMB at all.