我的一些应用程序出了问题.它是在Windows 2003 Server(x86)中的IIS6下运行的基于wcf的应用程序:
在事件日志中,我从"W3SVC-WP"源(EventID = 2262)得到这样的错误:
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.
Run Code Online (Sandbox Code Playgroud)
我正在尝试弄清楚发生了什么.我已按照此KB中的描述为Orphan Worker Process设置了转储.发生死锁时会创建一个小型转储.
然后我拿这个小型泵试图了解发生了什么.这是我被困住了.
我运行WinDbg x86,打开我的转储然后:
0:037> .loadby sos clr
0:037> .sympath SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols
0:037> !clrstack
The version of SOS does not match the version of CLR you are debugging. Please load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.1
SOS Version: …
Run Code Online (Sandbox Code Playgroud) 我们的WCF服务显示了大量内存使用的实例,因此我们采用了完整的内存转储来识别问题.
Operating System Windows Server 2008 R2Service Pack 1
Number Of Processors 4
Process Image c:\Windows\System32\inetsrv\w3wp.exe
System Up-Time 40 day(s) 09:23:09
Process Up-Time 14 day(s) 11:49:01
.NET 4.0
Processor Type X64
Process Bitness 64-Bit
Run Code Online (Sandbox Code Playgroud)
DebugDiag报告中问题的直升机视图.
进程是垃圾收集,所以根据警告,我不应该信任!heap命令的所有输出.
Gc堆:1.37 GBytes
.NET Cache大小为750Mb,
虚拟内存详细信息:虚拟分配:17.45 Gb加载模块:208.68 Mb线程:25 Mb本机堆:3.06 Gb(我担心这个.)
从上方3.02 Gb
存在于Heap 0x003f0000
单独.我们有很好的流量,这样1.3 gb
Gc堆大小对我来说是正常的.我们还有32 gb
ram和64bit地址空间的机器,因此Cache大小750 mb
是可以接受的.根据Native堆的大小,我觉得这是本机内存泄漏.
DebugDiag警告: 转储文件中加载了18149个动态程序集.
帮助链接:
.NET内存泄漏:XmlSerial化您的内存泄漏
分析 - 我们使用XmlSerialisers但它们被缓存,这样它们只创建一次.
.NET内存泄漏:XslCompiledTransform和泄漏的动态程序集
我们似乎在此博客文章中描述了同样的问题.所有这些18149动态组件都是0尺寸.所以我不能抛弃它们来获取细节.此外,我们不在此应用程序的任何位置使用Xsl转换.所以这些程序集不是由于Xsl转换.
更多统计数据:
相关对象数:
System.Reflection.Emit.InternalModuleBuilder ----- 1.11 MBytes (18149 objects )
System.Reflection.Emit.InternalAssemblyBuilder …
Run Code Online (Sandbox Code Playgroud) 我正在使用Windows调试工具,并在启动WinDbg/cdb或ntsd时收到以下错误消息:
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Run Code Online (Sandbox Code Playgroud)
执行任意命令时,我也会收到错误消息
*** ERROR: Module load completed but symbols could not be loaded for <module>.<ext>
Run Code Online (Sandbox Code Playgroud)
以下似乎是相关的:
*********************************************************************
* Symbols can not be loaded because symbol path is not initialized. *
* * …
Run Code Online (Sandbox Code Playgroud) 使用WinDbg时,应该在哪里放置私有符号文件(pdb?)?
我的情况是:我有一个我想调试的DLL.我有这个DLL的源代码和符号文件.这个DLL由另一个DLL(我没有符号或源代码)调用,而这个DLL又由EXE调用(我也没有符号或源代码).
我的问题是我收到了警告
***警告:无法验证C:\ TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll的校验和
我认为这个警告是我在调用堆栈中获取以下类型的消息的原因:
MYDLL!ACLASS ::机能缺失+ SomeHexAddress
我的文件结构如下所示:
exe:C:\ TheProgram\program.exe
调用dll:C\TheProgram\SomeSubfolder\caller.???
我要调试的DLL:C:\ TheProgram\SomeSubfolder\AnotherSubfolder\MyDll.dll
注意:我将符号文件路径和源文件路径设置为生成调试DLL的位置,在我的工作区中与exe的不同驱动器上..但我确实复制了pdb + map文件并将其放在我想要的dll上调试..
我正在尝试更多地使用windbg,并且我一直遇到符号缓存问题.我不清楚字符串的格式应该是什么.
我有一些要求:
我们在\\ foo\Build1234的分布式构建中的符号存档未组织为符号服务器.如果我理解正确,我需要使用cache关键字.
鉴于这些要求,这看起来像一个格式正确的srvpath:
cache*\\foo\Build1234;srv*c:\dev\symbols*http://msdl.microsoft.com/download/symbols
Run Code Online (Sandbox Code Playgroud)
编辑:
我刚刚开始阅读高级Windows调试,我误解了缓存关键字的工作原理.我认为这是告诉调试器该文件夹只是文件夹而不是符号服务器的一种方式.迈克尔离开他的评论后,我重读了这一部分,看到它确实像迈克尔描述的那样有效.
现在,当你使用时,我很困惑; 或**分隔路径/ URL.当你需要srv*前缀时.在windbg的在线帮助中,他们给出了这个例子:
\\someshare\that\cachestar\ignores;srv*c:\mysymbols*http://msdl.microsoft.com/download/symbols;cache*c:\mysymbols;\\anothershare\that\gets\cached
Run Code Online (Sandbox Code Playgroud)
来自\\ someshare的符号未缓存,Microsoft的符号缓存在c:\ mysymbols中,而c:\ mysymbols用作缓存*指令右侧任何其他路径的缓存.
偶尔使用srv*会让我感到困惑 - 我不明白为什么第一个和最后一个路径都没有以srv*作为前缀.
编辑2:
这慢慢开始对我有意义.srv指令用于符号服务器,而不用于普通符号目录.所以,我相信我原来问题的答案是这样的:
\\foo\Build1234;cache*c:\dev\symbols;srv*http://msdl.microsoft.com/download/symbols
Run Code Online (Sandbox Code Playgroud) 我尝试使用winDBG来调试转储文件.当我运行.loadby sos mscorwks.dll时
它给了我一个错误信息.无法找到模块'mscorwks.dll'
谁看过这个吗?
我们的夜间构建过程已经被打破了很长时间,因此它生成的PDB文件的年龄与相应的图像文件相差几个小时.我已经解决了这个问题.
但是,我想开始使用符号服务器,但不能因为必须使用这些年龄不匹配的pdb文件.我通过在windbg中使用.symopt + 0x40方法解决此问题.这意味着我必须手工组织我的所有pdb文件,经过多年的发布后,这就相加了.
我正在寻找一种方法来修改windbg用于标记pdb年龄的机制,并强制它匹配我的图像文件.实用程序ChkMatch执行类似的操作,但是对于pdb签名.开发人员在页面上声明"ChkMatch能够使可执行文件和PDB文件匹配,如果他们有不同的签名但年龄相同(有关PDB签名和年龄的更多信息,请参阅此文章).如果年龄不同,该工具无法生成文件匹配."
我看了一下hexeditor,甚至找到了与年龄相对应的东西,但它必须在内部拉出一些技巧,因为我无法让它工作.
有任何想法吗?
编辑:我不知道这是否有帮助,但在我的特殊情况下,年龄差异是由于不必要地重新连接dll引起的,这也会重新创建PDB文件.但是,我们的构建过程是存储原始dll(在重新链接之前),以及重新链接之后的pdb.我想过以某种方式手工重建这种情况.意思是,强制重新链接DLL,但在两种情况下都保存了pdb.然后我可以对这两个文件进行二进制比较,看看它们是如何变化的.也许运行某种自动执行此操作的修补软件?通过查看我的控制案例中究竟发生了哪些变化,或许我可以对我公司构建过程中保存的DLL和PDB做同样的事情?
编辑:我想出来!!!! 感谢第一个答案的评论之一,我查看了"未记载的Windows 2000 Secrets:A Programmers Cookbook"一书的pdf链接.作者详细介绍了pdb文件格式.正如我之前所说的那样,我已经将pdb加载到十六进制编辑器中,然后翻出一些看起来我的年龄/签名匹配,但它没有用.好吧,在使用W2k秘密书中的实用程序将pdb"爆炸"到包含的流中之后,我发现它们隐藏了对流3中年龄的另一个引用!!!!!!! 一旦我翻过那个,它在windbg中匹配.这太棒了!!!! 非常感谢....这里的符号服务器我来了!
windbg ×10
.net ×3
debugging ×3
symbols ×2
windows ×2
c# ×1
c++ ×1
crash-dumps ×1
dll ×1
memory ×1
memory-leaks ×1
minidump ×1
pdb-files ×1
sos ×1
visual-c++ ×1