1. W95-11D.ZIP Driver
2. EMM386.TXT File Contents

EMM386.TXT Driver File Contents (W95-11D.ZIP)

			     AXCEL216's MAX Speeed
		 MS-DOS 6.xx/7.xx/8.00 + Windows 3.1x/95/98/ME
		EMM386.EXE + MEMORY MANAGEMENT TECHNICAL DETAILS




NOTES:	- Only the EMM386.EXE 16-bit MS-DOS mode memory management part of
	Windows 95/98/ME is dicussed here.
	- For memory management guide + optimization tips *READ* MEMORY.TXT
	(included).
	- For abbreviations + terms explanations see GLOSSARY.TXT (included).
	- For DOS memory types, architecture + mapping technical details see
	REGIONS.TXT (included).
	- For Microsoft EMM386.EXE + HIMEM.SYS undocumented parameters see
	related topics in SECRETS.TXT (included).

CREDITS: Most of this information is found at MicroSoft Knowledge Base (MSKB):
	 http://support.microsoft.com/


EMM386.TXT Contents:


PC/AT MEMORY TYPES
EMM386.EXE v4.49 + v4.95 MEMORY MANAGERS
______________________________________________________________________________



			     PC/AT MEMORY TYPES



There are 5 different types (kinds) of memory (RAM) that can be installed in
your X86 compatible IBM PC/AT computer clone by using a Microsoft Operating
System (MS OS):
- Conventional Memory Area (CMA) = a 1024 KB (1 MB) region, also IMPROPERLY
called "low" memory, consisting of:
	- Low Memory Area (LMA) = a 640 KB region.
	- Upper Memory Area (UMA) = a 384 KB region, also IMPROPERLY called
"high" memory. Must be mapped by a dedicated UMA manager.
- Extended Memory Area (XMS) = a region of size which matches the amount of
total system RAM minus the CMA. Must be mapped by a dedicated XMS manager.
Abides by the XMS 3.0 standard.
- Expanded Memory Area (EMS) = a 32-64 MB region within XMS. Must be mapped by
a dedicated EMS manager. Abides by the LIM 4.0 standard.
- High Memory Area (HMA) = a 64 KB region within XMS located right above CMA.
Must be mapped by a dedicated XMS manager.
See REGIONS.TXT (included) for more PC memory details.


Conventional Memory

Conventional memory is the first 640K of memory in your machine. MS-DOS has a
limit of 1024K of addressable memory (conventional memory plus the UMA), and
all MS-DOS applications must run within this memory space. MS Windows shares
this limitation for running MS-DOS applications, but breaks the 640K
limitation for running native Windows applications.
Windows 3.1x/9x/ME can create multiple DOS Virtual Machines (VMs).
Windows 3.1x/9x/ME also allow MS-DOS applications to break the 640K barrier if
they are written to use the Microsoft DOS Protected Mode Interface (DPMI)
specification. DPMI allows MS-DOS applications to run in protected mode under
Windows, using up to 16 MegaBytes (MB) of extended memory (XMS) directly.
Such DOS programs must be specifically written for DPMI to take advantage of
this feature.


384K Upper Memory Area (UMA)

Between the top of conventional memory at 640K and the start of extended
memory at 1024K lies the 384K UMA. This area doesn't contain physical memory.
Mapped into the 384K UMA are the system BIOS (Basic Input/Output System) ROM
chips and the display adapter memory. When you install other accessory cards,
such as network adapters, video or disk controllers, they may also occupy
space within the 384K UMA. The 384K UMA is always located in the same area of
the IBM compatible computer's address space: from 640K to 1024K (A000-FFFF
hex). There are no exceptions to this rule.
This means that a standard IBM compatible machine with 640K of conventional
memory installed really has 1 MB of address space. The system memory occupies
the first 640K, and the 384K UMA occupies the area from 640K to 1M (1024K).
This does not mean that the machine has 1M of memory. A machine with 1M of
physical memory has an address space of 1408K. This consists of the 640K of
conventional memory, the 384K UMA, and the 384K of extended memory starting at
1024K.


Extended Memory (XMS)

Extended memory is the simplest type of add-on memory to understand.
It is also the type of memory used by Windows 3.1x/9x/ME. Extended memory is a
seamless continuation of the original 1M address space on 80286/80386 and
newer computers.
Extended memory always starts exactly at 1024K, where the 384K UMA ends. There
are no exceptions to this rule.
It is not possible for an 8086 or 8088 machine to have extended memory. This
is a hardware limitation of these old processors, which can handle only 1024K
of total address space (640K of system memory plus the 384K UMA). This is one
reason why MS Windows cannot run on 8086/8088-based machines, as it requires
a minimum of 1024K (1M) of extended memory for MS Windows 3.xx, 4096K (4M) for
Windows 95, and 16384K (16M) for Windows 98 and ME.
The 80286 processor can address 16 MegaBytes (MB) of total memory, the 80386
and 80486 processors can address up to 4 GigaBytes (GB), and the Pentium (Pro)
class (80586) and newer (80686 = Pentium II/III/IV) processors can address up
to 4 TeraBytes (TB) of physical memory.

FYI: PC manufacturers used to refer to extended memory as expansion memory,
which is not to be confused with expanded memory.

MS Windows and all applications running under Windows access extended memory
through the Extended Memory Specification (XMS). Rather than accessing the
extended memory directly, access is made through an XMS driver.
The driver supplied by Microsoft for this purpose is called HIMEM.SYS.
Older MS-DOS applications that check available extended memory through
interrupt 15 (Int15h) service 88H will not see any extended memory with an
XMS driver loaded. Such applications must be rewritten to use the XMS,
instead of interrupt 15, to access XMS properly.


Expanded Memory Standard (EMS)

Windows 3.1x, 95, 98, ME, NT, 2000, XP and 2003 do not use expanded memory,
but are able to provide it to MS-DOS applications. It is important to
understand the concept of expanded memory if you still run MS-DOS
programs/games that use it.


LIM 4.0 Expanded Memory Standard

Lotus/Intel/Microsoft (LIM) Expanded Memory Specification (EMS) 4.0 supports
up to 64 16K memory pages, which are enough to bank 1M of memory at once.
The page frame itself does not need to be mapped into 4 contiguous 16K pages.
In fact, you need no page frame at all. All EMS versions follow the basic
operating principle of bank switching.


LIMulators

On 80386 (and newer) machines, it is possible to use a 386 expanded memory
manager (such as EMM386, QEMM386, RM386, 386MAX etc) to emulate expanded
memory. These LIMulators use the XMS rather than interrupt 15h memory to
emulate expanded memory and are much more efficient.


Expanded Memory Difficulties

LIM 3.2/4.0 expanded memory requires a page frame to work, and the page frame
is located within the 384K UMA of your machine. Unfortunately, your EMM is not
the only competitor for that memory space. Add-on boards like: network cards,
SCSI, ESDI, RAID and (E)IDE disk controllers, SVGA video adapters, can all
contend for this address space. Several potential difficulties can arise due
to this contention:
1. LACK OF SPACE. The major problem is simply finding at least 64K of
contiguous free space in which to locate the LIM 3.2 page frame. LIM 4.0 does
not require a 64K page frame but is almost useless without it, as very few
applications have been written to take advantage of the LIM 4.0 specification.
Frequently, the address areas of various adapter cards need to be shuffled to
open a contiguous 64K page frame.
2. MAPPING CONFLICTS. Most 386 EMMs (such as EMM386.EXE) use a search
algorithm to find unused memory addresses between C000 and DFFF located in the
384K UMA to use as page frames. Some adapters do not reserve their address
space until you access the card, so the memory manager can inadvertently map
EMS pages on top of an address the card will request.
This is often true of Token Ring network adapters and can cause hanging and/or
intermittent operation.

In case of problems, the first thing to do is disable expanded memory. This
procedure will determine whether a page conflict is causing your difficulty.
If the problem goes away without expanded memory, the memory manager must be
told to exclude the address the adapter is occupying from consideration as a
page location. Consult your memory manager's manual for info on how to exclude
an address range. The adapter may also have to be moved. This is done in
different ways with different memory managers.



		EMM386.EXE v4.49 + v4.95 MEMORY MANAGERS



Microsoft EMM386.EXE recent releases:
- EMM386.EXE version 4.45 ships with MS-DOS 6.00 - 6.21: obsolete, replaced by
version 4.49, also available from Microsoft FTP [218 KB, free]:
ftp://ftp.microsoft.com/softlib/mslfiles/EMM622.EXE
More info:
http://support.microsoft.com/?id=122415
- EMM386.EXE version 4.49 ships with MS-DOS 6.22.
- EMM386.EXE version 4.95 ships with MS-DOS 7.00/7.10/8.00 as part of MS
Windows 95/98/ME: this is the current release.


I. Using the /S Switch with DEVICEHIGH/LOADHIGH


You can use the DEVICEHIGH/LOADHIGH switches /S and /L together to control
where programs are loaded in upper memory blocks (UMBs) and how much space
they allocate. Both switches affect the way programs interpret UMBs.
If you load a program with the /L switch, the program only recognizes the
memory regions you specify in the /L parameters. If you load a program with
the /S switch, the program only recognizes the regions you specify and the
amount of memory you specify. These switches are useful if you are optimizing
conventional memory because you can restrict the way a program uses a
particular memory region.
For example, the SMARTDrive utility has the ability to load itself into UMBs:
it is first loaded and initialized in conventional memory and then is
relocated to the largest available UMB it finds. By default SMARTDrive
attempts to load as much of itself as it can into UMBs; other programs will
not be able to use free UMBs because SMARTDrive has used too much space.
Since SMARTDrive does not have to reside in one memory area, you can use your
UMBs more efficiently by forcing SMARTDrive to use only a certain amount of
UMB space. You can accomplish this by using the /L and /S switches together.
The following command line (from AUTOEXEC.BAT) tells SMARTDrive that only
region 0 (located in conventional memory) and 3 (located in upper memory) are
free:
LOADHIGH /L:0;3,42416 /S drive:\path\SMARTDRV.EXE
SMARTDrive is first loaded and initialized in conventional memory (region 0)
and then relocates itself to region 3. Since the /L switch specifies a
minimum size of 42416 Bytes and the /S switch changes this minimum to the
absolute value free in region 3, SMARTDrive only recognizes region 0 and 3 as
free and only recognizes 42416 Bytes available in region 3. Therefore,
SMARTDrive loads 42416 Bytes of itself into region 3 and the rest in region 0.
This loading process results in more free memory in region 3 because
SMARTDrive is not able to relocate all of itself in that region. The next
program you load with the LOADHIGH command has enough space to load completely
into upper memory, and your available conventional memory is increased.


II. Regions Scanned by the EMM386.EXE HIGHSCAN Switch


HIGHSCAN switch included in EMM386.EXE versions 4.49/4.95 allows EMM386.EXE
to map expanded memory pages or Upper Memory Blocks (UMBs) over portions of
the Upper Memory Area (UMA) used by system Read Only Memory (ROM).
MS-DOS 6.xx users ONLY (MEMMAKER):
Choosing "Yes" in response to the MemMaker prompt "Scan the upper memory area
aggressively?" causes MemMaker to add HIGHSCAN to the EMM386.EXE DEVICE line.
If you use HIGHSCAN on the DEVICE=drive:\path\EMM386.EXE line in CONFIG.SYS,
EMM386.EXE examines system ROM area starting at memory location F000:0000 (in
hex).
If EMM386.EXE determines that ROM is duplicated between F000h-F7FFh and
F800h-FFFFh, EMM386.EXE uses the F000h-F7FFh region for expanded memory page
mapping or UMB memory. This adds up to 32K to the UMA.
On some systems EMM386.EXE uses the ROM area used by other devices, which may
result in incorrect operation. The symptoms of this condition vary. For
example, the system may stop responding (hang) or appear to operate normally
until you use a floppy disk drive. Because of these potential problems,
HIGHSCAN is not used by default. In this case, try to use the EMM386.EXE RAM
switch instead, to map the available UMA.


III. Changes in EMM386.EXE versions 4.49 and 4.95


Versions 4.49/4.95 of the Microsoft Expanded Memory Manager (EMM386.EXE),
provided with MS-DOS versions 6.22 and 7.xx/8.00 (Windows 9x/ME), have these
new features:
- Advanced Upper Memory Scanning
- Expanded and Extended Memory Sharing
- Ability to Provide Upper Memory Regions for Microsoft Windows
- Ability to Load with NOEMS When No Page Frame Is Available
- NOVCPI Switch for Smaller Load Size
- Automatic IBM Token Ring Adapter Detection (added NOTR switch)
- Quiet Loading
- Ability to Provide ROM Shadowing,
all discussed in detail below.


Advanced Upper Memory Scanning

EMM386.EXE can now scan the F000h-F7FFh region when the system Read Only
Memory (ROM) is duplicated between F000h-F7FFh and F800h-FFFFh. Also,
EMM386.EXE will include the ROM BASIC area on IBM PS/2 systems.
To enable advanced upper memory scanning, add the HIGHSCAN switch to the
EMM386.EXE line in CONFIG.SYS:
DEVICE=drive:\path\EMM386.EXE HIGHSCAN
On some machines with older BIOSes, specifying HIGHSCAN on the EMM386.EXE
line could hang the system. Replace HIGHSCAN with the less aggressive RAM
switch, which does a similar job in identifying usable Upper Memory Blocks
(UMBs).


Expanded and Extended Memory Sharing

EMM386.EXE versions 4.49/4.95 can dynamically create, allocate and make
available different memory types (expanded and/or extended) as your system
requirements change:
DEVICE=drive:\path\EMM386.EXE RAM AUTO


Ability to Provide Upper Memory Regions for Windows

EMM386.EXE 4.49/4.95 include the WIN=xxxx-yyyy switch that defines upper
memory regions available for use by Windows. These regions are similar to the
X=xxxx-yyyy regions; memory is not mapped to those areas. But unlike X=
regions, Windows 3.1x/9x can map their own memory into these upper memory
regions and make more conventional memory available to MS-DOS based
applications running with Windows (example):
DEVICE=drive:\path\EMM386.EXE WIN=D7FF-DFFF


Ability to Load with No Page Frame

EMM386.EXE older than 4.45 do not load if expanded memory support is enabled
and there is not enough contiguous available address space for an expanded
memeory page frame. To support MEMMAKER.EXE, EMM386.EXE 4.49 + 4.95 display
a warning message and continue to load when this situation occurs:
DEVICE=drive:\path\EMM386.EXE FRAME=NONE


NOVCPI Switch for Smaller Load Size

Previous versions of EMM386.EXE disable both expanded memory and Virtual
Control Program Interface (VCPI) support when the NOEMS switch is used.
EMM386.EXE 4.49/4.95 leave VCPI support enabled by default when the NOEMS
option is used, relying on the expanded and extended memory sharing
enhancement to supply VCPI memory. VCPI support can be disabled with the new
NOVCPI switch.
Using NOEMS and NOVCPI together results in a reduction in the amount of
extended memory used by EMM386.EXE:
DEVICE=drive:\path\EMM386.EXE NOEMS NOVCPI


Token Ring Adapter Detection

EMM386.EXE automatically detects the memory location of IBM Token Ring
adapter cards and prevents the mapping of expanded or upper memory over the
adapter. The Token Ring adapter detection can be disabled by using the
undocumented NOTR switch:
DEVICE=drive:\path\EMM386.EXE NOTR


Quiet Loading

By default, EMM386.EXE 4.49/4.95 displays messages only if it encounters an
error condition. Adding the /VERBOSE (abbreviated to /V) switch to the EMM386
line in CONFIG.SYS forces EMM386.EXE to display status and error messages
while loading:
DEVICE=drive:\path\EMM386.EXE /V
To display status messages without adding the /V switch, press and hold down
the ALT key while EMM386.EXE is loading.


Ability to Provide ROM Shadowing

EMM386.EXE 4.49/4.95 include the ROM=xxxx-yyyy switch that defines regions of
Read Only Memory (ROM) for EMM386.EXE to "shadow." EMM386.EXE copies the
contents of the ROM to extended memory (RAM) and maps the ROM addresses to
this memory. Specifying this switch can speed up your system if it does not
already use shadow RAM. Most newer 80486 and all Pentium class and above
systems use ROM shadowing:
DEVICE=drive:\path\EMM386.EXE ROM=D7FF-DFFF


IV. Troubleshooting MS-DOS and EMM386.EXE 4.49/4.95


If you encounter unexpected behavior (for example the system or a program
hangs) when using EMM386.EXE 4.49/4.95, use these troubleshooting steps:

1. Turn your machine off, and then turn it back on (cold boot) to fully
reinitialize the system.

2. Start MS-DOS 6.xx interactively by pressing F8 as soon as the message
"Starting MS-DOS..." appears. Windows 9x [MS-DOS 7.xx] users need to press
Shift + F8 simultaneously for a similar step-by-step boot confirmation
operation.
This allows to select which CONFIG.SYS and/or AUTOEXEC.BAT commands to
execute, by pressing Y (for Yes) or N (for No).

3. When prompted to load EMM386.EXE, choose N. If the problem persists without
loading EMM386.EXE, something other than EMM386.EXE is causing the problem.

4. If the problem disappears when EMM386.EXE is not loaded, edit CONFIG.SYS as
follows using an ASCII text editor (such as EDIT.COM, the default MS-DOS
Editor) and change the CONFIG.SYS EMM386.EXE line to read:
DEVICE=drive:\path\EMM386.EXE X=A000-F7FF NOHI NOEMS NOVCPI NOMOVEXBDA NOTR
If the problem is specific to the use of the CTRL+ALT+DEL key combination
(warm boot) and EMM386.EXE, add the ALTBOOT parameter to the above line.
WARNING:
Avoid the EMM386.EXE ALTBOOT switch IF using a SCSI/(U)DMA/(E)IDE add-in
controller! The ROM addresses used by these adapters may CONFLICT with the
memory address used by the "ALTernative BOOT" routine, causing LOCKUPS!

5. Cold boot the machine after making the above changes. If the problem
persists, the system may have faulty RAM chips or may require a special
machine switch for HIMEM.SYS. In addition, any BIOS/CMOS settings (such as
shadow RAM) may need to be disabled, or the system ROM BIOS may need to be
upgraded for compatibility with MS-DOS/MS Windows. Consult your system vendor
for information on CMOS settings and availability of BIOS upgrades.

6. If the problem disappears after loading EMM386.EXE as specified above,
EMM386.EXE itself is not the source of the problem. Instead, the problem may
be related to some service(s) that EMM386.EXE provides.

7. If the above procedure does not correct the problem, remove each EMM386.EXE
command line option one by one and cold boot the machine each time.
If the problem reappears, see further below to find a resolution.

FYI: Troubleshooting system errors/lockups when using EMM386.EXE [PD0470T.TXT,
21 KB, free]:
ftp://ftp.microsoft.com/softlib/mslfiles/PD0470.EXE


X=A000-F7FF

If excluding the entire Upper Memory Area (UMA) resolves a system problem,
EMM386.EXE may be scanning too aggressively and setting up Upper Memory
Blocks (UMBs) on top of some adapter ROM or RAM. Use any available hardware
documentation (including documentation on the add-on hardware devices such as
video, network, and disk controller cards) to identify any ROM or RAM present
in the UMA for that device, and exclude all pertinent regions (example):
DEVICE=drive:\path\EMM386.EXE X=D800-DFFF
The MicroSoft Diagnostic utility (MSD.EXE) may also be useful in identifying
various mapped memory regions. Run:
MSD
from any DOS prompt, and then press M to display the memory screen.
FYI: See MSD95.TXT (part of W95-11D.EXE) or MSD62.TXT (part of W31-11D.ZIP)
for MSD usage details.


NOHI

EMM386.EXE has the ability to load a portion of itself into UMBs (Upper Memory
Blocks). If the NOHI option corrects the problem with EMM386.EXE, EMM386.EXE
may be loading into an occupied UMB. Excluding the appropriate ranges in the
UMA may correct this problem (see the "X=A000-F7FF" section above). If all
such regions are excluded, EMM386.EXE cannot be loaded high on the system, and
NOHI must be used:
DEVICE=drive:\path\EMM386.EXE NOHI
Contact your system manufacturer/vendor for additional information on
compatibility with EMM386.EXE.


NOEMS

If the NOEMS parameter corrects the problem with EMM386.EXE, EMM386.EXE may
be inadvertently conflicting with some hardware ROM or RAM address in the UMA
when attempting to establish an expanded memory (EMS) page frame. If EMS is
required to run MS-DOS-based applications, use the parameter FRAME=xxxx or Mx
(where xxxx and respectively x is the defined hex address) to explicitly
specify the placement of the EMS page frame in a nonconflicting region
(using the E000-F000 64K region to allocate the page frame in this example):
DEVICE=drive:\path\EMM386.EXE FRAME=E000
or (example using the same region for the page frame):
DEVICE=drive:\path\EMM386.EXE M9
If no applications/games require expanded memory (EMS), simply continue to use
the NOEMS parameter:
DEVICE=drive:\path\EMM386.EXE NOEMS


NOVCPI

The NOVCPI switch disables Virtual Control Program Interface (VCPI) support
and can be used only in conjunction with the NOEMS parameter. If using NOVCPI
corrects the problem, the application may not be fully compatible with the
EMM386.EXE VCPI allocation scheme. Either continue using NOVCPI, or do not
load EMM386.EXE when using the application:
DEVICE=drive:\path\EMM386.EXE NOVCPI


NOMOVEXBDA

Some (older) machines use the last KiloByte of conventional memory for an
Extended BIOS Data Area (EBDA). By default EMM386.EXE remaps this memory area
into the UMA (Upper Memory  Area) instead of conventional memory. If this
causes unexpected system behavior, the NOMOVEXBDA parameter MUST be used:
DEVICE=drive:\path\EMM386.EXE NOMOVEXBDA


NOTR

The EMM386.EXE detection code searches for the presence of a Token Ring
network adapter. This detection code may cause some computers to hang. The
NOTR switch can be used to disable this search in such cases:
DEVICE=drive:\path\EMM386.EXE NOTR

For more details on EMM386.EXE command line syntax:
- MS-DOS 6.xx users: run:
HELP EMM386.EXE
from any DOS prompt.
- Windows 9x/ME users: use Notepad to read the "EMM386.EXE" topic in
MSDOSDRV.TXT, a text file located in your Windows folder.


V. MS-DOS BUFFERS


A BUFFER is a portion of memory that DOS sets aside for buffering disk I/O
(Input/Output).
DOS stores directories and partial blocks here. DOS must read a full sector
of information from the disk. If the application asks for an amount of
information that is not an exact multiple of the sector size then the whole
sector must be stored somewhere while DOS gives the partial amount asked for
to the application that asked for it. DOS uses the BUFFERS to store
directories because it needs somewhere to store information for its own use.
DOS keeps one BUFFER in the kernel to make sure that it has at least one at
all times. The rest are loaded as "Added Data".
In MS-DOS 4.xx up to 8.00 [a.k.a. MS Windows ME] the size of each BUFFER is
fixed at 528 Bytes.
You actually need only one BUFFER. Any program that claims it needs more is
really only making a recommendation. Of course, your system will probably run
slower if you have only one BUFFER, but no more than one is actually needed
to operate. Consult your OS/software manuals for suggestions on how many
BUFFERS you should allocate.
Disk cache tools (like Microsoft SMARTDRV.EXE) may perform some of the same
services as DOS BUFFERS. If you use a disk cache consult the disk cache
documentation when deciding how many BUFFERS to allocate.
BUFFERS is actually an area of RAM which is available for buffering disk I/O
(In/Out).
They are not used by the count. Having 20 BUFFERS means that you allow 10 KB
(20 x 528 Bytes) of disk buffering.
The BUFFERS line can be specified only in CONFIG.SYS.
If you are using Microsoft SmartDrive 4.xx/5.xx (SMARTDRV.SYS/SMARTDRV.EXE)
to cache your disk(s) reads/writes, and/or Windows/WfWG 3.1x 32-bit Fast Disk
Access (FBDA), you ONLY need 10 BUFFERS, specified by this CONFIG.SYS line:
BUFFERS=10
For Windows 95/98/ME systems [Pentium class and newer CPUs equiped with an
(E)IDE/(U)ATA/RAID/SCSI drive controller] the optimal BUFFERS line would be:
BUFFERS=13
also detailed in this MSKB article:
http://support.microsoft.com/?id=156332
More than that is not needed and won't fit into the High Memory Area (HMA),
forcing any additional BUFFERS to load into conventional RAM, thus decreasing
the amount of conventional RAM available to DOS programs/games.
More info @ MSKB:
http://support.microsoft.com/?id=78434


VI. EMM386 ERROR MESSAGES


If EMM386 displays a message like:
"EMM386 has detected error #12 in XXXXXXXX.EXE"
this indicates that the processor has reported an exception error to EMM386.
An exception error typically occurs when an application gives the CPU an
instruction under invalid or unexpected conditions.
In most cases, these errors are related to a specific program. If you are
receiving an error that does not occur with any particular application, the
error might be caused by a device driver or a TSR (Terminate and Stay
Resident program). To avoid EMM386 errors:

* Identify the program involved. See if the error occurs when the program is
not running. If you suspect a memory resident program/TSR/device driver:
- try bypassing it when your computer starts,
- get an updated (current) version from your program vendor,
- REMark the offending command line by adding:
	- REM or ; (semicolon) in front of it in your CONFIG.SYS,
	- REM or :: (double colon) in front of it in your AUTOEXEC.BAT,
and then reboot.

* Disable EMM386. If a particular application is to blame, disabling EMM386
might allow that application to generate an error message. Disabling EMM386
will also change your memory configuration so the error may no longer occur.

* Change the order in which you load device drivers/TSRs in your CONFIG.SYS
and AUTOEXEC.BAT files. It might help because some errors occur ONLY under
specific memory conditions.

* Error 12 message: a stack is being used incorrectly.
DOS uses a maximum of 16 STACKS for itself, and any number greater than 16 is
a waste of memory anyway. Each stack can have a maximum value of 512 Bytes, in
128 Bytes increments. Example:
STACKS=16,512
Windows itself does not benefit from increased stack size. It is actually the
combination of EMM386.EXE, SMARTDRV.EXE and the Mouse driver combined with any
MS-DOS mode (legacy) TSRs and/or device drivers already installed on the
system that can cause problems.
SMARTDRV.EXE and the Mouse driver hook the timer interrupt. EMM386.EXE and
SMARTDRV.EXE hook the keyboard interrupt. When these hooks are added to a
machine running network software or other TSRs that hook the same interrupts,
the stack space requirements exceed 128 Bytes (default stack size) and a stack
overflow error may occur.
See also this MSKB article:
http://support.microsoft.com/?id=82774
For details on the CONFIG.SYS STACKS command:
- MS-DOS 6.xx users: run:
HELP STACKS
from any DOS prompt.
- Windows 9x/ME users: use Notepad to read the "STACKS/STACKSHIGH" topic in
CONFIG.TXT, a text file located in your Windows folder, or go to:
http://support.microsoft.com/?id=234853
- See this MSKB article:
http://support.microsoft.com/?id=84300
Workarounds:

1. Add/modify your CONFIG.SYS STACKS line to read:
STACKS=12,256
to provide 12 DOS STACKS of 256 Bytes each (minimum for playing safe).
If you believe this is not enough, increase the STACKS number to 16 (maximum
needed):
STACKS=16,256
Reboot when done.
This also avoids another error message generated by a too low STACKS number:
"Stack overflow system halted"

2. Add/modify your CONFIG.SYS STACKS line to read:
STACKS=0,0
to revert back to older MS-DOS 3.xx stack handling, ONLY IF you believe you
don't have ANY MS-DOS/Windows applications/games that require stack switching
to operate.
The STACKS=0,0 line actually speeds up your system, even on faster Pentium
class and newer systems. If you determined that none of your programs need
stack handling, set the STACKS line to 0 in your CONFIG.SYS (see above) to
save (upper) memory space and decrease I/O processing time.
Disabling stack switching works for most MS-DOS programs, but may cause stack
overflow errors for others, especially older ones. Stack overflow errors can
cause completely unpredictable results since interrupts occur at random times.
Therefore if using older MS-DOS programs, it is preferable to leave stack
switching active (see workaround 1 above).

* Error 13 message: an application may be trying to use protected mode without
cooperating with EMM386. You may need to obtain a VCPI compliant (updated)
version of the software from your vendor, or not load EMM386 when using that
particular program/game.


VII. EMM386.EXE ERROR CODES


Code#	Meaning
---------------
0	Divide error
1	Debugger interrupt
2	Nonmaskable interrupt
3	Breakpoint
4	Overflow interrupt
5	Array boundary violation
6	Invalid opcode
7	Coprocessor not available
8	Double fault
9	Coprocessor segment overrun
10	Invalid task state segment
11	Segment not present
12	Stack exception
13	General protection violation
14	Page fault
16	Coprocessor error