Re: 如何稳当地通过Windbg找到错误源头
WinDbg
如何稳当地通过Windbg找到错误源头
goandgo
2015-05-11, 22:31 下午
先说一下背景，我使用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时就断下，但是还是找不到原因所在，
请问题各位，如何精确定位到导致异常的地方呢？
Re: 如何稳当地通过Windbg找到错误源头
goandgo
2015-05-13, 12:30 下午
不要沉下去呀，各位发表看法吧
Re: 如何稳当地通过Windbg找到错误源头
格蠹老雷
2015-05-13, 19:10 下午
在关闭前sxe e06d7363
断下来后，至少把k的结果贴上来吧，不然神仙是猜不出啊
Re: 如何稳当地通过Windbg找到错误源头
goandgo
2015-05-13, 21:31 下午
我描述的有点不太清楚，我再说的清楚一些。其实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处。
Re: 如何稳当地通过Windbg找到错误源头
goandgo
2015-05-13, 21:33 下午
d:\win7sp1_gdr\sql\xml\msxml6
这个东西始终看不出来啥意思，在网上查了一下也没有找到结果，看起来是个路径，但代表哪个路径呢？
Re: 如何稳当地通过Windbg找到错误源头
格蠹老雷
2015-05-14, 13:29 下午
关闭项目时通知VS的NuGet扩展，后者解析XML时出问题了，如果你不用NuGet，那么把它禁止掉
TOOLS > Extension and Updates
如果要用，升级下
Re: 如何稳当地通过Windbg找到错误源头
goandgo
2015-05-14, 21:53 下午
张老师，我的NuGet是禁用状态的呀，
另外，你是怎么想到这个东西的呢，能分享下你的思维历程吗，还有那个路径也没找到是什么东西
Re: 如何稳当地通过Windbg找到错误源头
goandgo
2015-05-14, 21:58 下午
<BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="/Themes/default/images/icon-quote.gif"> <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那个东西给禁用了以后就正常了。
张老师把思路说一下吧，你的解决思路才是金子，结果只是银子。拭目以待呀
Re: 如何稳当地通过Windbg找到错误源头
Bombs
2015-05-15, 14:27 下午
只是异常没人处理后弹出个错误对话框而已，跟挂死两码事。
那个路径是源代码路径（负责编写这个模块的人机器上的路径，而不是你自己机器的路径）
Re: 如何稳当地通过Windbg找到错误源头
格蠹老雷
2015-05-15, 22:03 下午
呵呵，此亦无他，主要是看下面这三行：
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的文件名
Re: 如何稳当地通过Windbg找到错误源头
goandgo
2015-05-18, 06:01 上午
在Load的时候我没有看到那个路径，我再试试看看，另外那个win7sp1那个路径不知道有用没有用
Re: 如何稳当地通过Windbg找到错误源头
sPhinX
2015-06-18, 06:08 上午
之前已经有人说了“
那个路径是源代码路径（负责编写这个模块的人机器上的路径，而不是你自己机器的路径）
”，所以除非你有Windows 7 sp1的源代码，否则是没用的。