也不知道谁写的，反正有用，保存一下
Release版程序调试排错技巧- -
在软件产品的测试过程中，以及发布之后，程序可能会由于一般保护错（GPF）而崩溃。即程序中访问了禁止访问的内存。这时，程序一般情况下无法继续运行，只能结束。
通常，我们遇到这个问题时只能大致地从程序运行（上下文）情况来粗略推断错误，但实际上有更好的解决办法......
Release版程序调试技巧
环境及工具：
windows 9x/2000/xp，VC 6.0（SP6）
Win32Dasm 8.93
CrashFinder
在软件产品的测试过程中，以及发布之后，程序可能会由于一般保护错（GPF）而崩溃。即程序中访问了禁止访问的内存。这时，程序一般情况下无法继续运行，只能结束。
在安装了调试器（比如VC）的系统中，会弹出一个错误对话框，显示类似：
“0x12345678”指令引用的”0x000000123”内存。
该内存不能为”written(read)”
终止单击确定，调试单击取消。
没有调试器的系统中一般会出现一个Dr. watson窗口，内容类似。
通常，我们遇到这个问题时只能大致地从程序运行（上下文）情况来粗略推断错误，但实际上有更好的解决办法。
在开发过程中，编译release版本的程序（包括EXE、DLL、OCX等二进制程序）时，要建立相关的mapfile，即映像文件。方法如下（VC）：
（1） 选择release版本；
（2） Project settings => C/C++ => Debug Info，选
“Line Number Only”；
（3） Project settings => link => 选中 “Generate mapfile”；
（4） Project settings => link => Project Option中，输入 ：
/mapinfo:lines
这样，编译后就会生成一个*.map的文本文件，其中包含了release版本程序的相关信息。
当程序出现GPF时，记下指令地址，然后可以在map文件中的Rva+Base 段查找相关的信息。
比如：H1接口程序，出错指令为0x0040d7a0，在map文件中，可发现：
0001:0000c730 ?RefreshDevList@@YGIPAX@Z 0040d730 f FFServer.obj
其中 0040d730是小于0040d7a0的最大地址，则可初步断定是在RefreshDevList函数中出的问题。下一步是定位出错代码在源程序中的行数，mapfile中包含了相关信息。定位方法是先计算偏移量，公式为：
(crash address) － (preferred load address) － 0x1000
其中(preferred load address)在mapfile首部可以找到。然后，在mapfile中的相关源程序代码行信息段中搜索即可。
在没有mapfile，比如编译时未添加相关选项的情况下，可以用反汇编工具，如Win32Dasm将出错的程序反汇编，找到相关指令并分析。
有时，出错指令地址并不在程序的mapfile中，比如：0x77fcc665。
这 一般是在出错程序调用的系统DLL中，比如msvcrt.dll、ntdll.dll等。可以用一个小工具CrashFinder来查找。 0x77fcc665查找的结果是RtlSizeHeap + 000007EA，ntdll.dll。同时，还可以启动调试器（如VC），查看call stack等信息，找到出错指令的上下文。尽量正确能在mapfile中定位。
在《Debugging Applications》一书中有详细的说明。
总之，希望开发者和测试者能注意以下几点：
（1） 发行版（release）的程序，包括DLL、OCX，一定要输出map file；
（2） map file与相关的程序的版本对应关系一定要认真记录，避免混淆；
（3） release版程序出现GPF时不要轻易结束，要详细记录下当时的信息，最简单的方法就是进行一下屏幕拷贝。
（4） 在 NT/2000/XP 下，可以通过查看系统日志来获取程序崩溃信息。