经过这几天的拼命试验，终于发现问题出在哪了！需要在所引用的第一个DLL文件的users关键字下面的第一个位置加一个ShareMem单元，这样问题就解决了。在新建DLL工程后，delphi会在前面加上注解，内容是 { Important note about DLL memory management: ShareMem must be the first unit in your library's USES clause AND your project's (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } 相信这个大家都有印象。这段话只是说明了需要如何如何做，但并没有说不这样会发生什么后果。没有解释原因，而且，以前的项目即使不使用ShareMem单元，也不会出错。所以，大家全都乎视了这个注释。不管怎么样这都是一个惨痛的教训。我相信绝不是我一家软件公司会遇到这事。在这里，我要非常感谢大家的帮助。另外，我肯请版主把此贴转到精华，以使大家不要再走这个弯路。
plainsong(伤心的风) ，没有进行质量管理，但，如果内存操作错误的话，应该会有非法操作的对话框出现才对。我不知是不是还会有其它软件也会有这种bug
chatop(星点) yaos() 可以确定不是人为因素
flp(会说话的哑巴) 退出时没有执行到任务退出操作，所有对象没有被析构，但内存却被释放了，是操作系统搞的。
delphiyesterday(郑康益) 退出之后没有任何不良反映，软件可以再进入，直到下次莫明退出
karl(多功能算术逻辑运算单元)每台机器都出现
ourme(风含笑) 我真的很想知道这不是开发的问题
breezing(上帝死了 众神在堕落) 值得一试
后来改了对Mem操作的地方就好了，不过我也记不太清了。
有人做了手脚
建议测底跟踪一下
去查看查看Windows中的Dr.Watson程序的日志。
如果没有，把Dr.Watson的开关打开。
Windows为了自保护，会杀掉它认为对系统有害的程序。
一般会把问题记在Dr.Watson的日志中。
没有用delphi调试的时候跟踪一下吗？或者设一个断点，应该能跟到问题的所在吧。
这样程序就不会因为一个不太重要的错误而被中止了。
try 。。finally（except）中间出错！
这样容易导致程序的终止啊！
不过问题是很奇怪！！！
但看题目好像加try处理也搞不定啊！！！
i+=1;
一运行，
则整个程序包括开发环境瞬间关闭。换成
i=i+1;则完全没有问题。
如果是系统引发的强制性退出，只能借助系统管理工具去分析。如是程序自身的退出：将每个EXIT前加上SHOWMESSAGE（），将当时的怀疑对象的相关变量甚至系统变量都SHOW出来，往往会发现是变量的值越界引发的问题。
然后showmessage('过程名')，也许可以找到它！
{ Important note about DLL memory management: ShareMem must be the
first unit in your library's USES clause AND your project's (select
Project-View Source) USES clause if your DLL exports any procedures or
functions that pass strings as parameters or function results. This
applies to all strings passed to and from your DLL--even those that
are nested in records and classes. ShareMem is the interface unit to
the BORLNDMM.DLL shared memory manager, which must be deployed along
with your DLL. To avoid using BORLNDMM.DLL, pass string information
using PChar or ShortString parameters. }
相信这个大家都有印象。这段话只是说明了需要如何如何做，但并没有说不这样会发生什么后果。没有解释原因，而且，以前的项目即使不使用ShareMem单元，也不会出错。所以，大家全都乎视了这个注释。不管怎么样这都是一个惨痛的教训。我相信绝不是我一家软件公司会遇到这事。在这里，我要非常感谢大家的帮助。另外，我肯请版主把此贴转到精华，以使大家不要再走这个弯路。