搜索论坛 帖子排序:  Oldest to newest Newest to oldest

2015-05-11, 22:31 下午 goandgo 注册: 2015-04-07 发 贴: 24 如何稳当地通过Windbg找到错误源头 附件: VS2013挂死.png 先说一下背景，我使用VS2013的时候，关闭解决方案时会出错，注意是关闭解决方案，不是关闭整个程序。 出错的情况就是直接弹出个小窗口，问我是调试程序还是关闭。典型的挂死，图片在附件中。 再说一下我调试时的情况，我是找了一回又一回，发一下我的调试情况： 当从VS2013关闭解决方案时，出异常，中断到调试器，信息如下： (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) (1878.1a9c): C++ EH exception - code e06d7363 (first chance) ModLoad: 704c0000 70617000 C:\Windows\System32\msxml6.dll (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.268c): CLR exception - code e0434352 (first chance) (1878.268c): CLR exception - code e0434352 (first chance) (1878.1d18): CLR exception - code e0434352 (first chance) (1878.1a9c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=02fc7338 ebx=1d11f010 ecx=00000000 edx=00000000 esi=02fb9ea0 edi=0017d5e4 eip=09b622b7 esp=0017d5a4 ebp=0017d5c0 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 09b622b7 8b01 mov eax,dword ptr [ecx] ds:0023:00000000=???????? 只知道出异常后走向挂死，最后访问的地址出问题了，但是我考虑着在第一次异常的时候应该就已经出问题了，所以我想办法在第一次异常时拦截下来，通过设置sxe e0000001，在第一次得到e00000001时就断下，但是还是找不到原因所在， 请问题各位，如何精确定位到导致异常的地方呢？ IP 地址: 已记录   报告

2015-05-13, 12:30 下午 goandgo 注册: 2015-04-07 发 贴: 24 Re: 如何稳当地通过Windbg找到错误源头 不要沉下去呀，各位发表看法吧 IP 地址: 已记录   报告

2015-05-13, 19:10 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 如何稳当地通过Windbg找到错误源头 在关闭前sxe e06d7363  断下来后，至少把k的结果贴上来吧，不然神仙是猜不出啊 IP 地址: 已记录   报告

2015-05-13, 21:31 下午 goandgo 注册: 2015-04-07 发 贴: 24 Re: 如何稳当地通过Windbg找到错误源头 我描述的有点不太清楚，我再说的清楚一些。其实code e06d7363这个异常是经常发生的并且VS内部会处理的，之所以在上面贴了出来，有点偶然，我再次调试时发现不出现这个异常了。而有个异常一直存在，就是： ModLoad: 704c0000 70617000 C:\Windows\System32\msxml6.dll (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.1a9c): Unknown exception - code e0000001 (first chance) (1878.1a9c): Unknown exception - code e0000001 (first chance) 这个e0000001异常每次在关闭解决方案时都会出现。我现在把K后的结果列举一下： 0:000> k ChildEBP RetAddr 001de7f4 71f12375 KERNELBASE!RaiseException+0x58 001de814 71f3b277 msxml6!Exception::raiseException+0x5f [d:\win7sp1_gdr\sql\xml\msxml6\core\lang\exception.cxx @ 178] 001de834 71ea6c4d msxml6!Document::load+0x6a [d:\win7sp1_gdr\sql\xml\msxml6\xml\om\document.cxx @ 747] 001de8a4 64439e7a msxml6!DOMDocumentWrapper::load+0x1ff [d:\win7sp1_gdr\sql\xml\msxml6\xml\om\xmldom.cxx @ 1111] 001de8f8 64433ef3 vslog!CPackagesConfigFile::Open+0x73 001de958 64432ed7 vslog!CVSLogPackage::LogProjectNuGetPackageInformation+0x53 001dec3c 648acb1e vslog!CVSLogPackage::OnBeforeCloseSolution+0x186c 001dec90 648acb78 msenv!CSolution::NotifySolutionEventsSinks >+0x5d 001decc0 648ab524 msenv!CSolution::NotifyOnBeforeCloseSolution+0x32 001def80 646ebbb3 msenv!CSolution::Close+0x47d 001df0a0 6471b6d2 msenv!HrShellExec+0x23f 001df13c 647783af msenv!CVSCommandTarget::ExecCmd+0x9bb 大概是这么个情况。 另外，我怀疑是Document.Load方法出了问题导致的异常，才导致接下来程序走向挂死，最后执行的代码就不在任何模块里面，访问了00000000处。 IP 地址: 已记录   报告

2015-05-13, 21:33 下午 goandgo 注册: 2015-04-07 发 贴: 24 Re: 如何稳当地通过Windbg找到错误源头 d:\win7sp1_gdr\sql\xml\msxml6 这个东西始终看不出来啥意思，在网上查了一下也没有找到结果，看起来是个路径，但代表哪个路径呢？ IP 地址: 已记录   报告

2015-05-14, 13:29 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 如何稳当地通过Windbg找到错误源头 关闭项目时通知VS的NuGet扩展，后者解析XML时出问题了，如果你不用NuGet，那么把它禁止掉 TOOLS > Extension and Updates 如果要用，升级下 IP 地址: 已记录   报告

2015-05-14, 21:53 下午 goandgo 注册: 2015-04-07 发 贴: 24 Re: 如何稳当地通过Windbg找到错误源头 张老师，我的NuGet是禁用状态的呀， 另外，你是怎么想到这个东西的呢，能分享下你的思维历程吗，还有那个路径也没找到是什么东西 IP 地址: 已记录   报告

2015-05-14, 21:58 下午 goandgo 注册: 2015-04-07 发 贴: 24 Re: 如何稳当地通过Windbg找到错误源头 <BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="/Themes/default/images/icon-quote.gif">&nbsp;<strong>Raymond wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4">关闭项目时通知VS的NuGet扩展，后者解析XML时出问题了，如果你不用NuGet，那么把它禁止掉<div>TOOLS > Extension and Updates</div><div><br></div><div>如果要用，升级下</div></td></tr></table></td></tr></table></BLOCKQUOTE> 不过，张老师分析的果然有道理，我把.net reflector那个东西给禁用了以后就正常了。 张老师把思路说一下吧，你的解决思路才是金子，结果只是银子。拭目以待呀 IP 地址: 已记录   报告

2015-05-15, 14:27 下午 Bombs 注册: 2014-01-16 发 贴: 15 Re: 如何稳当地通过Windbg找到错误源头 只是异常没人处理后弹出个错误对话框而已，跟挂死两码事。 那个路径是源代码路径（负责编写这个模块的人机器上的路径，而不是你自己机器的路径） IP 地址: 已记录   报告

2015-05-15, 22:03 下午 格蠹老雷 注册: 2005-12-19 发 贴: 1,303 Re: 如何稳当地通过Windbg找到错误源头 呵呵，此亦无他，主要是看下面这三行： 001de8f8 64433ef3 vslog!CPackagesConfigFile::Open+0x73  001de958 64432ed7 vslog!CVSLogPackage::LogProjectNuGetPackageInformation+0x53  001dec3c 648acb1e vslog!CVSLogPackage::OnBeforeCloseSolution+0x186c  关闭前调用事件处理方法，后者调用LogProjectNuGetPackageInformation，即调用扩展包的信息，这里的NuGet让我以为是要禁止NuGet扩展，其实不然，NuGet已经是VS的一部分，很多扩展都是支持NuGet的，有点像Linux下的apt get，呵呵，所以使用NuGet标准加载你说的那个扩展时出问题了，分析load的参数应该可以找到xml的文件名 IP 地址: 已记录   报告

2015-05-18, 06:01 上午 goandgo 注册: 2015-04-07 发 贴: 24 Re: 如何稳当地通过Windbg找到错误源头 在Load的时候我没有看到那个路径，我再试试看看，另外那个win7sp1那个路径不知道有用没有用 IP 地址: 已记录   报告

2015-06-18, 06:08 上午 sPhinX 注册: 2008-06-28 发 贴: 50 Re: 如何稳当地通过Windbg找到错误源头 之前已经有人说了“那个路径是源代码路径（负责编写这个模块的人机器上的路径，而不是你自己机器的路径）”，所以除非你有Windows 7 sp1的源代码，否则是没用的。 IP 地址: 已记录   报告

高端调试 » 软件调试 » WinDbg » Re: 如何稳当地通过Windbg找到错误源头

请选择 论坛首页 |- 论坛搜索 |- 热门主题 |- 未回复的主题 用户选项 |- 登录 |- 注册 |- 找回密码 软件调试 |- Windows内核调试 |- C/C++本地代码调试 |- .Net程序调试 |- 脚本程序调试 |- Java程序调试 |- Linux内核调试 |- 《程序员》杂志调试专栏 |- WinDbg |- GDB |- 远程调试 |- 调试ACPI和BIOS |- 特殊的调试任务 |- 转储分析 |- GDK7 内核探秘 |- Windows内核 |- Linux内核 系统架构 |- CPU架构 |- PCI/PCI Express架构 程序人生 |- 软件物语 |- 社区活动 |- 名人逸事 联盟论坛 |- 欢迎使用CnForums 没有银弹 |- BUG也精彩 |- 豆腐工程 |- 软件圈里十大怪 Windows Vista |- 用调试利剑剖析VISTA内幕 |- 老专家如何破解新问题 |- 我的电脑谁说了算？ |- 资源 Office开发 |- Visio 驱动程序开发 |- Windows驱动开发 |- Linux驱动开发 |- Windows CE驱动开发 用户态开发 |- Windows本地代码（native）高级开发 |- Web应用开发 |- WinFX和.Net |- Office开发 本站建设 |- 高端调试团队 |- 版面布局 |- 活动建议 |- 网站维护 64位计算 |- 64-bit Windows |- 64-bit CPU 图书 |- 《软件调试》的示例程序 |- 《软件调试》的工具 |- 《软件调试》书友 |- 《软件调试》答疑 |- 《软件调试》勘误和意见 |- 《格蠹汇编》 |- 《软件调试》第二版卷1 |- 《软件调试》第二版卷2 云计算 |- IaaS |- 云存储 |- 大数据 |- PaaS和SaaS GPU |- CUDA |- OpenCL |- HSA |- 游戏开发与调试