No announcement yet.

EMM386 Errors

  • Filter
  • Time
  • Show
Clear All
new posts

  • EMM386 Errors

    I have a data-acquisition system running through the PC parallel port. In an attempt to fix regular system "freezes", we switched the computer from a 386SX-16 to a 486DX2-66. The problems have moved to consistently inconsistent. Tonight I got a DOS error which said "EMM386 error #12 in ap(plication)". I am assuming that the rest of the message was "application". Does anyone know what EMM386 error #12 is? It may point to my resident Poltergeist. Any help will be greatly appreciated.
    Steve Andrues


  • #2
    It would help to know what operating system you are using. EMM386
    is the extended memory manager and it may be that your app is
    "leaking" to memory locations out of bounds.

    I would check your EMM386 and make sure it's the one that is
    supposed to be used with the appropriate O/S you are using.

    Just out idle curosity, why are you using the parallel port
    instead of one of serial ports? Now don't get me wrong, there's
    nothing wrong with using the parallel port if it works.
    Well, (few minutes later), did a Google search and check out:
    Looks you got a stack problem.

    [This message has been edited by Mel Bishop (edited December 10, 2003).]
    There are no atheists in a fox hole or the morning of a math test.
    If my flag offends you, I'll help you pack.


    • #3
      I am currently using DOS 6.22 for the OS. The reason for using the parallel port is easy. A very good friend of mine was watching the normal operation of my shop and announced that it "offended his sensibilities". He returned a week later with a working prototype and all that I had to do was "flesh-in" the rest of the code. At the time the idea was a good one. The data acquisition system was independent of the hardware. Any standard "Herculese" parallel port would work just fine. In the mean time there is BIOS-confifurable parallel ports and my system will not work. But that is another problem ..... I am currently using the EMM386 that comes with Dos6.22.



      • #4
        Oh. Okay.

        Did you click on the link above and check your STACKS statement
        in your CONFIG.SYS?

        There are no atheists in a fox hole or the morning of a math test.
        If my flag offends you, I'll help you pack.


        • #5
          At the risk of revealing my DOS-ignorance; what stacks statement? What should I look for and what do you think would be optimal? The available memory for my tiny program is 15M (out of 16). It would run on the 386SX with 1M of memory.



          • #6
            Bring up CONFIG.SYS in your favorite plain text word processor
            and check for a STACKS=(something) line. If it's there, change
            the parameters to STACKS=16,256. If it's not there, add
            STACKS=16,256. That SHOULD take care of your problem.

            FYI: The stack on a computer is where the operating system
            stores temporary information. Its structure is like the
            magazine on a rifle, last-in, first-out. If and when the stack
            fills up, your program will crash. However, unless you are into
            assembly programing, you won't normally need to use it but
            you do need to be aware of it.

            As an added thought, run MEMMAKER and let it do it's thing.

            [This message has been edited by Mel Bishop (edited December 11, 2003).]
            There are no atheists in a fox hole or the morning of a math test.
            If my flag offends you, I'll help you pack.


            • #7
              The problem continues ....
              After making the Stacks (and everything else in the Config.sys file) the same on our production machine the same as the "test mule" we got an insufficient memory error while trying to compile the code. No problem. 16MB later the production machine and test-mule are the same. Now the compiler reports that it cannot find some of the Linked files. The directories for the compiler are setup the same in both machines. There has been NO CHANGE in the code. Why will the code that was running on Thursday not run on Friday?!? Any ideas?



              • #8
                If you are trying to compile from within the IDE and get an
                "Insufficient memory" error, your source code is probably too
                big to hold both the IDE and and compile routine. To solve
                this, drop to DOS (quit the IDE) and compile it with PBC.EXE.

                If the program can't find its support files, there is something
                in there preventing finding their location. You may have to
                explicitely defind the full path of the support files in the
                source code.

                Not on Friday? Maybe it's taking an early weekend

                [This message has been edited by Mel Bishop (edited December 15, 2003).]
                There are no atheists in a fox hole or the morning of a math test.
                If my flag offends you, I'll help you pack.


                • #9
                  Howmuch expanded memory do you reserve ?? The config line should
                  have something like: device=c:\dos\emm386.exe 4096
                  This means you give the expanded memory manager 4 Mb of RAM to claim and address.
                  Emm686 reserves stack-space addresses in so-called hi-mem, can't remember
                  if there is a way to put it in the base-addressed 640 Kb. The hi-mem gets sometimes
                  fragmented when loaded tsr's or device drivers leave memory that was occupied when
                  then program initialized. Try to use a clean as possible system. Sometimes adding little
                  pause's to certain fast polling procedures to see if you can stabelize the situation.
                  Sometimes the reason is not all obvious !!


                  You gotta run, and don't loop back.
                  You gotta run, and don't loop back.


                  • #10
                    How much memory of various kinds does your memory test utility show?
                    When I run 'MEM' at a command line, here is what I show:

                    752640 bytes total memory
                    752640 bytes available for DOS
                    671840 largest executable program size

                    8781824 bytes total EMS memory
                    8388608 bytes free EMS memory

                    2031616 bytes total XMS memory
                    2031616 bytes available XMS memory
                    0 bytes available contiguous extended memory
                    DOS resident in High Memory Area
                    High Memory Area in use
                    When you post what you see, a couple suggestions may evolve.

                    Mike Luther
                    [email protected]
                    Mike Luther
                    [email protected]


                    • #11
                      MEM command yields the following results:

                      Memory Type Total = Used + Free
                      -------------------- ---------- --------- ----------
                      Conventional 640K 171K 469K
                      Upper 0K 0K 0K
                      Reserved 384K 384K 0K
                      Extended (XMS)* 31,744K 2,576K 29,168K
                      -------------------- ---------- --------- ----------
                      Total Memory 32,768K 3,131K 29,637K

                      Total Under 1MB 640K 171K 469K

                      Total Expanded (EMS) 32,064 (32,833,536 bytes)
                      Free Expanded (EMS)* 29,408 (30,113,792 bytes)

                      * EMM386 is using XMS memory to simulate EMS memory as needed.
                      Free EMS memory may change as free XMS memory changes.

                      Largest executable program size 469K (480,240 bytes)
                      Largest free upper memory block 0K ( 0 bytes)
                      MS-DOS is resident in the high memory.



                      • #12
                        Having only 469K for your biggest program size is really low.
                        One thing you might try:

                        In your CONFIG.SYS file, DEVICEHIGH all your device drivers,
                        i,e, "devicehigh = ANSY.SYS". Be sure to load EMM386 and the
                        other one FIRST.

                        In your AUTOEXEC.BAT, Load High (LH) your other stuff, i.e.,
                        "LH MSCDEX.EXE".

                        This will put most, of not all, of your system file in the upper
                        memory region and free up a hoop-lah of conventional memory.

                        There are no atheists in a fox hole or the morning of a math test.
                        If my flag offends you, I'll help you pack.


                        • #13
                          Or you could just REM out all the unnecessary drivers such as ANSI, MSCDEX (unless CDRom access is absolutely essential), etc, or modify your CONFIG.SYS fiel so that it produces boot-menu offering a choice of "minimalistic" and "load everything"... the 6.2x docs show how to do it using square brackets to name the sections, etc.

                          That said, there were a number of buggy HIMEM and EMM386 versions around (with the same time/date stamp as the "fixed" versions!). Therefore, a good test would be to (at least temporarily) replace the HIMEM and EMM386 files with versions from, for example, a Windows 3.1x installation, etc.

                          Yet another idea could be to use a QEMM memory manager instead -- it should even be able to optimize memory use for you, much like MEMMAKER does.

                          (QEMM tip: avoid Stealth mode if at all possible -- it seems to cause more problems than it fixes!)

                          PowerBASIC Support
                          mailto:[email protected][email protected]</A>
                          mailto:[email protected]