"Error 2000: Stack Overflow" running DOS application on Windows XP

Started by brookebree, June 19, 2010, 11:04:44 PM

Previous topic - Next topic

brookebree

I"ve used Microsoft masm v6.11 assembler, link v5.60 linker, mapsym v4.0 symbol file generator, and symdeb v4.0 debugger for years on my XP Professional, Service pack-3 computer to write and maintain several 16-bit assembly programs in the XP DOS command line
environment.  Recently, a problem started when I install various new windows applications (Itunes, Java updates, Roxio Disk software, etc.) I start getting the error 'Error 2000: Stack overflow' when I run the mapsym.exe program to create the .sym file I use with symdeb to debug my assembly applications.

So my masm, link, mapsym and symdeb are the exact same versions I've run for years, nothing has been changed,  I've been able to run maysym for years also with no problem (Win 95, 98, XP), but my current problem is basically that after I install just about any new windows XP application, mapsym will stop working and report this same error, but I uninstall the application and mapsym will start working again and doesn't display the error.  I've tried running mapsym on a couple other XP computers and found out it gets the same stack error on them so it seems to only work on my XP computer (maybe the only one in the world???), and only if I don't install any new windows software (or most windows software, I am able to load some applications with no Ill effects like fileZilla, Bugzilla, Skype, Digital Picture Professional).

Codeview is not an option for debug since I run processes that spawn child processes several layers deep which codeview has issues with, I actually used to use codeview years ago for but this and other reasons I switched to symdeb for my debug use as it it much more robust for my app's that use multiple code/data segments & calls to 'c' code.  I could use the 'debug' program that comes with the XP OS but can't see public'd code and memory location labels so that is not an option.  I've read on the internet about this error being displayed for other DOS programs and I understand it has something to do with the stack in my mapsym program being too small. I also read about an old microsoft program called modexe.exe which will allow me to get around this stack error , but can't find the modexe.exe program anywhere on the net.

Anyway, I've seen this several reports of OTHER DOS programs displaying this exact same error on the internet, but have not run across ONE case where the problem was solved.

I'm clean out of ideas here, so... if someone can help me resolve this, I will officially declare you MASTER OF THE 16-BIT UNIVERSE, and probably many others out there that hare having this exact same problem.

Thanks in Advance...

clive

Perhaps your environment variables exceed 32KB (or is otherwise very large). Try typing SET at the command prompt to see how much stuff is set.

Most applications slap some huge directories into PATH, you might be able to prune that down.

The app for the stack is EXEMOD, couple of versions came with Microsoft C 5.0 and 5.1 that I can find at hand.

A quick google pull this up. http://www.naic.edu/~phil/hardware/vertex/sharemegsvertex/ocu/pcr/mscv51/bin/
It could be a random act of randomness. Those happen a lot as well.

dedndave

you might try using EXEMOD.EXE to change the stack size of MAPSYM.EXE   :bg
i would say doubling it should help
another thing that may help - use shorter symbol names   :P
(although, it's more likely the number of symbols - not how large they are)

oh - and welcome to the forum   :U

sinsi

Try adding the line "stacks=9,256" to the file \windows\system32\config.nt
Or see if anything is amiss in config.nt or autoexec.nt
Light travels faster than sound, that's why some people seem bright until you hear them.

brookebree

Clive, you are indeed the master of my 16-bit universe!,  my environment variables were only about 1.5K in size and I had already tried up-ing 'stacks='  setting in config.nt with no change, so went to llink you advised  http://www.naic.edu/~phil/hardware/vertex/sharemegsvertex/ocu/pcr/mscv51/bin/  and downloaded the exemod.exe program.
Ran 'exemod mapsym.exe /stack 0c00' at command line and it modified my mapsym.exe.  Installed Java update and Itunes, (program installs causing problems before),  and the modified mapsym now works like a charm!  thanks for the help!  I'll spread the word....


dedndave

QuoteClive, you are indeed the master of my 16-bit universe!

lol - i am sure he'll be happy to here that

i was poking around on that site and found this - notice the slight difference in the url

http://www.naic.edu/~phil/hardware/vertex/sharemegsvertex/ocu/pcr/masmv51/bin/

clive

Those crazy people and the internets. Not that I recommend placing such material up there, but if you need a couple of files they usually exist out there.

I expanded the search from my netbook, to the server, and found about a dozen varients of EXEMOD in the 86-88 time frame with Microsoft C, PASCAL, FORTRAN, MASM in the 4.x to 5.x era.

I remember Lattice C have some problems with large environments, and the last one I encountered was with WATCOM executables.
It could be a random act of randomness. Those happen a lot as well.

dedndave

what i found interesting was that they have nearly the entire MASM v 5.1 package, including CV stuff, but no SYMDEB.EXE !
i used SYMDEB for a long time, and still do from time-to-time (probably because i know it inside out - lol)
back in the day, i even disassembled SYMDEB and made a few mods to it   :P
in fact, i used SYMDEB to disassemble it - lol

FORTRANS

Hi Dave,

   CodeView replaced SYMDBG in MASM 5.0.  MicroSoft's
"improvement of the day".  It was no longer a part of the
MASM package.

Regards,

Steve

dedndave

that's odd - my MASM 5.1 disk set has SYMDEB (maybe it got added)
CV was an alternative - one that i never liked, though
but, i am pretty sure they still included SYMDEB
hang on - that site had the packing list file - let me have a look...

well, i'll be - lol
no SYMDEB
i wonder which version of MASM i got that from - must be one of the 4's
maybe i stole it from the old MS C compiler   :P

clive

SYMDEB was in a couple of packages, the one immediately at hand came from the Windows 2.0 SDK, which as Dave indicated was probably shipped with the Developer Version of Microsoft C 4.0

Directory of i:\DEVTOOLS\WINSDK.200\DISK1\BINAPPS

01/29/88  01:00a                43,593 SYMDEB.EXE
               1 File(s)         43,593 bytes
It could be a random act of randomness. Those happen a lot as well.

FORTRANS

Hi,

   This is from the MASM version 3.00.

Regards.

Steve N.


12/07/1984  01:39p              27,136 SYMDEB.EXE

dedndave

the one i used was around 38 Kb i think
i must have gotten it from MASM 4.0   :P