某年，某月，某日。
为某一个大型程序，增加一个大型功能。编译，运行，死机。

跟踪之，居然死在了如下语句：
CString str;
而且还极不稳定，这次调试死在n行，下次调试死在m行。但都是和内存申请有关。（由于程序很大，其中频繁地申请和释放内存，多处使用new和CString）

猜测：一定是内存不够啦，遂在某处调用函数得到当前剩余的物理内存数量并使用MessageBox显示。报告曰：自由物理内存还有100多M。鼠标按下OK键，程序居然不死了。恩？？？

删除MessageBox()函数---死！加上MessageBox()函数---不死！再删除--死，再加上--不死。晕倒！

捏呆呆郁闷不知道多少时间后，灵光闪烁......把多处的new/delete改写为GlobalAlloc()/GlobalFree()，一切OK。

事后原因分析：使用new和CString，频繁申请，释放内存，一定产生零碎内存块。当使用MessageBox的时候，系统接管程序的运行（因为它在等待着你按OK按纽），它这时候开始回收合并这些零碎的内存块。这样程序就没有问题了。而函数GlobalAlloc()/GlobalFree()本身就有回收合并零碎内存的功能。

友情提示：在频繁使用new,CString的场合，建议把某些（大）数据块的申请用GlobalAlloc替换。
友情求援：以上分析，不一定正确。需要new和GlobalAlloc源码分析才能作出正确判断。或那位朋友确切知道原因？

某年，某月，某日。
对N条记录追加到网络服务器上的数据库中，然后数据库就不能打开了。
为调试方便，跟踪着把记录追加到本机数据库中，数据库能打开，一切正常。
于是返回服务器调试。

知道我的痛苦了吧，现在需要调式服务程序了。在程序中插入N处写日志功能，痛苦......
调试过程无意中变换了一下记录入库的顺序，一切正常了。恩？？？更痛苦了......

经过N小时后，终于找到了问题所在的函数，类似如下的处理：
CFile file;
file.Open(“xxx“,CFile::modeCreate | CFile::modeWrite);
file.Write(...);
file.Close();
file.Open(“xxx“,CFile::modeRead);//这里打开失败

刚刚建立并写入数据的文件，关闭后就不能再打开了。查找错误返回值，曰：共享错误。
倒~~~~~ 奏是偶一个人在操作，奏是偶一个程序在操作，居然共享错误？

捏呆呆郁闷30分钟，恍然大明白了......把病毒实时监控程序关闭。一切OK。
数据库文件中，居然产生了病毒的特征码。汗！

某年，某月，某日。
一个long long age正常的程序，突然在某台计算机上运行错误。遂调试之......
经过N小时，逐步缩小范围，并书写调试代码，居然是：刚把一些数据写进一块内存后立刻读出，就是不对。

恍然大明白了......为了证明我的判断，进入DOS：
copy file1 file2
fc /b file1 file2
报N处不相同，并且每次还都不一样。

晕倒~~~~~ 开箱，拔下内存条，换之。遂OK