vc++ windbg dump 调试 疑问！

Posted 2023-04-26

ntdll.dll!7c95f583()
msvcr71.dll!7c34218a()
> world.exe!std::_Tree<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::_Erase(std::_Tree_nod<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::_Node * _Rootnode=0x33aa99e8) 行896 + 0x9 C++
world.exe!std::_Tree<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::_Erase(std::_Tree_nod<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::_Node * _Rootnode=0x34cc6f10) 行894 C++
world.exe!std::_Tree<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::clear() 行782 C++
world.exe!Object::ClearInRangeSet() 行410 C++
world.exe!Unit::ClearInRangeSet() 行5079 C++
world.exe!Creature::ClearInRangeSet() 行700 C++
world.exe!MapMgr::RemoveObject(Object * obj=0x29c32818, bool free_guid=true) 行549 C++
world.exe!Object::RemoveFromWorld(bool free_guid=true) 行1148 C++
world.exe!Unit::RemoveFromWorld(bool free_guid=true) 行5710 C++
world.exe!MapCell::RemoveObjects() 行156 C++
world.exe!MapMgr::~MapMgr() 行90 C++
world.exe!MapMgr::`vector deleting destructor'() + 0x50 C++
world.exe!MapMgr::Do() 行1601 + 0x21 C++
world.exe!MapMgr::run() 行1477 + 0xb C++
world.exe!thread_proc(void * param=0x2def29c8) 行266 + 0x11 C++
kernel32.dll!7c82608b()

以上是不是代表
调用堆攒： ntdll.dll!7c95f583() 时出错？
错误为：
> world.exe!std::_Tree<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::_Erase(std::_Tree_nod<std::_Tset_traits<Object *,std::less<Object *>,std::allocator<Object *>,0> >::_Node * _Rootnode=0x33aa99e8) 行896 + 0x9 C++

并非：我写的程序错误。

还有这个ntdll.dll 这么不稳定是否可以更换其他版本的。是否对win2003 系统造成其他不良影像

ntdll.dll!7c95f583() 无非就是显示了调用这个DLL时的内存地址, 并不能看出什么问题.
我感觉是在 world.exe!后面一长串上, 估计是std::allocator过多而没有及时clear造成内存泄露, 另外楼上讲得也对, 你可能用了不少trycatch(...), 在catch里捕获了所有异常(没具体指出异常类型)但是没有throw出来,这样一些隐藏的内存问题会不易察觉. 还是建议多检查下自己写的代码. 参考技术A 几乎所有的程序出错最后都是挂在ntdll.dll里面。可能是出现问题之后的检查在这里面来做的。我就知道那些异常处理最后也是到这里来的。

肯定不是人家ntdll的问题了，我知道很多内存错误的错误都是显示这里的错的。还是自己检查一下自己的东西吧 参考技术B 先试一试用Debug Config编一遍，看看运行有没有错。如果没有，有可能是STL的问题；或者编译器里的优化器的问题。如果有错，很大可能是你自己程序的问题。

无需Windbg | 使用VS 2019调试.NET程序的Crash异常

前言

某台服务器上的IIS应用程序池，最近经常会自动关闭。

查看服务器上的事件日志，发现在关闭时，w3p.exe抛出了stackoverflow异常。

幸好，Windows自动帮我们抓取了Crash的dump文件：

一般来说，我们会使用windbg来分析dump文件，但是对于这种异常dump，更简单的方法是使用VS 2019。

分析方法

1.打开dump文件

双击memory.hdump，默认应该可以直接打开VS 2019，也可以使用菜单“文件”->“打开”->“文件”，打开dump文件。

在打开的界面中，左侧是dump文件的基础信息，右侧是常用操作：

2.设置符号路径

在进行调试之前，需要先设置调试文件路径，这样调试时才能正确显示调用的模块方法。

点击“设置符号路径”，在符号文件位置加入应用程序对应的.pdb文件路径：

3.执行调试

点击“使用仅限托管进行调试”，等待一会，可以看到抛出的未处理的异常：

由于是在本机调试，结果发现在堆栈窗口中还是无法看到方法名，提示定位不到dll。

因此，把服务器上的应用程序dll也复制到符号路径下，再次调试，就可以正常显示了。

结论

根据调用堆栈定位到的方法，我们轻松找到了问题原因并解决。

使用VS 2019调试dump，比windbg上手简单许多，你还不赶快试试！

如果你觉得这篇文章对你有所启发，请关注我的个人公众号”My IO“