Hi there,

First thanks for a very informative FAQ! I came across it recently while
trying to solve the infamous
nothing-can-load-high-after-restarting-in-msdos-mode bug. I've been
searching for a fix for this problem for MONTHS. Everyone I asked either
didnt know about the bug or didnt know how to fix it.

The thing that annoyed me about the problem is that it seemed such a
serious bug for nobody to know anything about it, and as you know,
Microsoft themselves dont even acknowledge the problem, and its certainly
not in their knowledge base, as I have skimmed through EVERY article in
there ;)

To find your FAQ which not only acknowledges the problem but suggests fixes
was a god-send. I admit I was skeptical at first, because after trying the
6 different fixes listed, in order of what I thought were most likely, they
didnt seem to work. However (murphys law) the last one I tried - the
smartdrive fix WORKED!.

I'm in an interesting position in that I work in a computer store and I
come into contact with a LOT of machines, and I've been keeping a rough
tally of this problem and found the following:

Around 80% of the machines with OSR2 exhibit this problem, EG the inability
to load programs high after restarting in MS-DOS mode. On most of these
machines the problem was not initially apparent, because most new machines
dont seem to be configured for DOS programs. (EG no EMM386 in config.sys,
no dos mouse drivers etc installed) It's only after I try to do my routine
config-for-dos-programs, that I run into the problem.

Around 10% mysteriously do not suffer from this program. There is
absolutely no reason I can find so far, other than the fact that they are
different machines with different hardware etc....I am still working on
trying to find the reason.

The remaining 10% have an interesting problem somewhere in between - if you
boot straight into Windows, and then IMMEDIATELY exit to MS-DOS mode, the
problem is not apparent, however if you run ANY program in windows first,
before exiting to MS-DOS mode, the problem WILL occur. This is bizare, but
I have seen 4 machines now, where I can continuously reproduce these symptoms.

Some more observations:

Analysing the upper memory area with MSD is very revealing. MSD is not
installed by default on Win95 systems, but is on the CD in the \OTHER\MSD
directory, and can be copied into \WINDOWS\COMMAND. On a machine not
suffering from the problem, or on any machine, before windows boots up (F8
command prompt only) MSD will show a standard upper memory map with U and F
indicating used and free area respectively. When the problem is in
evidence, the entire upper memory area other than the ROM areas, are marked
as "RAM", which normally indicates PHYSICAL ram in that address range
rather than EMM386's simulated ram.

Some comments on the various fixes listed in your FAQ

1) Using a previous version of EMM386.EXE - this didnt work for me, and I
dont think it will ever work, because contrary to the name of the bug
(EMM386 NOEMS bug) from what I've seen, I dont think EMM386 is to blame.

2) Use AUTO instead of NOEMS - much the same as above, since the bug doesnt
seem to be in EMM386 this didnt help.

3) Loading smartdrv in autoexec.bat - this DID work for me (thanks!!) and I
suspect the reason is that its not smartdrv itself thats significant, but
rather that it is a program being loaded before windows which is holding
onto the upper memory area, which prevents windows from doing whatever it
does to make the upper memory unusable. I think there will be other
programs that could also do this - I'll be doing some experimentation to
see what I can find.

4) RAM ON switch - didnt work for me

(BTW you have TWO solution number 4's!! heheh)

4a) delete doublespace.bin file if not being used - this one is
interesting, this is a valid fix for a low base memory problem, (I've used
it myself several times) but it is NOT related to this particular bug, and
it applies to Win95 original version as well. Sometimes, if you have a
doublespace.bin file it will load into memory using about 60K base memory,
and it WILL NOT load high, even if you put it in config.sys with /MOVE. The
result is a maximum free base memory of around 560K which can look similar
to the no-upper-memory bug to the casual observer, but it is NOT the same
problem. The solution, as your FAQ mentions, is to delete dblspace.bin and
drvspace.bin from the root directory, as long as you're not actually using
compression of course :+)

5) Upgrading DirectX - also didnt work. I suspect this one is a red-hering,
and hasnt worked for anyone, but they have mistakenly thought it was the
cure when they changed two things at once.

6) Not really sure whats meant on this one, whether its implied to just run
the dos program in windows, or to edit an icons properties to restart in
ms-dos mode. If the later, this doesnt work either, because it doesnt
actually change anything - Restarting in MSDOS mode just executes an icon
called "ExitToMSDOS.pif" in the windows directory, which is just a shortcut
with its properties set to run command.com, but restart in MS-DOS mode....

I will keep you informed of anything further I can find out about the bug, but
for now I would recommend the smartdrv fix...

Regards, 
Simon
comnorth@igrin.co.nz