怎样定位哪个DLL的哪行代码出错?解决方法
怎样定位哪个DLL的哪行代码出错?
程序调用我的三个DLL, DLL都是VC写的, 运行一些时候会出现非法访问错误. 出现时间不确定.
最后这次的错误是:
"0x02862dcc指令引用的0x0210601f内存. 该内存不能为read "
这三个DLL我都生成了mapfile, 函数最大地址就是10009458,根本没到0x02XXXXXX这么大的地址.
有什么办法知道哪个DLL出错的, 错在哪行吗?
------解决方案--------------------
不怎么清楚1
帮顶下!
------解决方案--------------------
把你调用dll的程序编译成exe文件,然后用dll的debug调试,用dll启动exe程序,一个一个的调,这样肯定能发现问题。要不就多些记录文件。
------解决方案--------------------
可能是越界的问题
------解决方案--------------------
是不是与调用顺序有关
------解决方案--------------------
bug几乎很少会在开发机上出现,但是测试机上才是真实的生产环境之一,建议你找合适的位置做一定的日志输出,然后在测试机上跑吧,至少能定位到出现问题的流程入口
------解决方案--------------------
当然到不了0x02XXXXXX,mapefile只有代码节的东东,关键是还没有重定向.按道理这里就是你dll里面出了问题.可是为什么是0x02xxxxx呢?????那是因为dll被重定向了,当然地址会发生变化.
可以用DebugBreak??
这里还是推荐使用od,不过由于错误出现时间不确定,还是比较麻烦.
也可以使用日志文件配合处理
------解决方案--------------------
我想只有在关键的地方写日志的方式来检查了.哎,环境不对,真是麻烦.
------解决方案--------------------
cczlp跑这来了啊。
将日志输出到文件,然后再分析Log文件吧。
------解决方案--------------------
在VC的调试环境中,在Debug的Module菜单里面有各个Module的Address,那样你就知道是那个Module的问题了,不过如果地址是在系统的Module里的话,就不太好分析了,那可能是你少调用了什么,或者什么没有初始化等问题了。
------解决方案--------------------
将所有dll与exe输出到一个目录中。
将所有dll与exe组成一个solution
debug版运行
------解决方案--------------------
调试呀,用WinDebug
------解决方案--------------------
设置运行机器的默认调试器为DrWatson,运行
C:\> drwtsn32 -i
程序出异常时,DrWatson会对异常进程生成dump文件user.dmp和drwtsn32.log,存放在
C:\Documents and Settings\All Users\Documents\DrWatson中,把user.dmp拷回开发机
运行WinDebug,设置Symbol file path,
SRV*C:\Program Files\WinDbg\symbol*http://msdl.microsoft.com/download/symbols
加入你的程序的Debug路径,用 '; '分隔,例如:
E:\MyPrograms\Test\Debug;SRV*C:\Program Files\WinDbg\symbol*http://msdl.microsoft.com/download/symbols
用Open Crash Dump打开user.dmp文件,WinDebug进入调试模式,一般当前就停在出错指令位置,你也可以在下面的命令框中用~#s切换到出错线程,然后打开函数调用栈View-> CallStack,其中列出了该线程当前的函数调用情况,从下向上是调用嵌套顺序,最上一个就是出错的地方
找到最后一个你写的函数,双击它,将会自动打开你的源代码文件,并定位到出错行的下一行。
注意:要保证代码与错误程序是相同版本
程序调用我的三个DLL, DLL都是VC写的, 运行一些时候会出现非法访问错误. 出现时间不确定.
最后这次的错误是:
"0x02862dcc指令引用的0x0210601f内存. 该内存不能为read "
这三个DLL我都生成了mapfile, 函数最大地址就是10009458,根本没到0x02XXXXXX这么大的地址.
有什么办法知道哪个DLL出错的, 错在哪行吗?
------解决方案--------------------
不怎么清楚1
帮顶下!
------解决方案--------------------
把你调用dll的程序编译成exe文件,然后用dll的debug调试,用dll启动exe程序,一个一个的调,这样肯定能发现问题。要不就多些记录文件。
------解决方案--------------------
可能是越界的问题
------解决方案--------------------
是不是与调用顺序有关
------解决方案--------------------
bug几乎很少会在开发机上出现,但是测试机上才是真实的生产环境之一,建议你找合适的位置做一定的日志输出,然后在测试机上跑吧,至少能定位到出现问题的流程入口
------解决方案--------------------
当然到不了0x02XXXXXX,mapefile只有代码节的东东,关键是还没有重定向.按道理这里就是你dll里面出了问题.可是为什么是0x02xxxxx呢?????那是因为dll被重定向了,当然地址会发生变化.
可以用DebugBreak??
这里还是推荐使用od,不过由于错误出现时间不确定,还是比较麻烦.
也可以使用日志文件配合处理
------解决方案--------------------
我想只有在关键的地方写日志的方式来检查了.哎,环境不对,真是麻烦.
------解决方案--------------------
cczlp跑这来了啊。
将日志输出到文件,然后再分析Log文件吧。
------解决方案--------------------
在VC的调试环境中,在Debug的Module菜单里面有各个Module的Address,那样你就知道是那个Module的问题了,不过如果地址是在系统的Module里的话,就不太好分析了,那可能是你少调用了什么,或者什么没有初始化等问题了。
------解决方案--------------------
将所有dll与exe输出到一个目录中。
将所有dll与exe组成一个solution
debug版运行
------解决方案--------------------
调试呀,用WinDebug
------解决方案--------------------
设置运行机器的默认调试器为DrWatson,运行
C:\> drwtsn32 -i
程序出异常时,DrWatson会对异常进程生成dump文件user.dmp和drwtsn32.log,存放在
C:\Documents and Settings\All Users\Documents\DrWatson中,把user.dmp拷回开发机
运行WinDebug,设置Symbol file path,
SRV*C:\Program Files\WinDbg\symbol*http://msdl.microsoft.com/download/symbols
加入你的程序的Debug路径,用 '; '分隔,例如:
E:\MyPrograms\Test\Debug;SRV*C:\Program Files\WinDbg\symbol*http://msdl.microsoft.com/download/symbols
用Open Crash Dump打开user.dmp文件,WinDebug进入调试模式,一般当前就停在出错指令位置,你也可以在下面的命令框中用~#s切换到出错线程,然后打开函数调用栈View-> CallStack,其中列出了该线程当前的函数调用情况,从下向上是调用嵌套顺序,最上一个就是出错的地方
找到最后一个你写的函数,双击它,将会自动打开你的源代码文件,并定位到出错行的下一行。
注意:要保证代码与错误程序是相同版本