分类 调试 下的文章

错误模型试图回答的基本问题是:如何将“错误”传达给程序员和系统用户?
在回答这个问题时,最大的挑战之一就是定义错误的实际含义。大多数语言将Bug和可恢复的错误归为同一类,并使用相同的工具来处理它们。例如空引用或越界数组访问的处理方式与网络连接问题或解析错误相同。乍一看,这种一致性似乎不错,但它有根深蒂固的问题。尤其是,它具有误导性,并且经常导致不可靠的代码。
我们的总体解决方案是提供一个双管齐下的错误模型。一方面,由于编程错误,产生了fail-fast 异常,我们称之为快速终止。另一方面,您已经静态地检查了可恢复错误的异常。两者在编程模型和背后的机制上都非常不同。快速终止在一瞬间毫无歉意地破坏了整个过程,拒绝运行任何用户代码。)当然,异常有助于恢复,但是有深层类型的系统支持来帮助检查和验证。

这趟旅程漫长而曲折。为了讲述这个故事,我把这篇文章分成六个主要方面:

  • 基础知识
  • Bug是不可恢复的错误!
  • 可靠性、容错性和隔离性
  • Bug:终止、断言和契约
  • 可恢复错误:类型定向异常
  • 回顾与结论

事后看来,某些结果似乎显而易见。尤其是考虑到现代系统语言如Go和Rust。但有些结果让我们吃惊。我会尽我所能直截了当地去追索,但我会一路上给你充分的回馈。我们尝试了很多没用的东西,我想这比尘埃落定时的结局更有趣。

今天在调试分析一个dmp文件,要分析clr的栈,于是,输入命令".loadby sos clrjit",结果出现如下错误提示:

0:000> .loadby sos clrjit
The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos) failed, Win32 error 0n193
    "%1 不是有效的 Win32 应用程序。"
Please check your debugger configuration and/or network access.
很是吃惊。从来没有遇到过,仔细看提示,是加载sos扩展库失败,原因是"不是有效的win32应用程序",难道是sos.ll被破坏了,还是下载不全,最后都排除了。

实在是没办法了,感到很沮丧。最后无意看到Windbg标题栏显示的是64位版本的

而我要用的是32位版本,于是,我关掉64位,开启32位windbg,加载dmp,分析,输入输入命令".loadby sos clrjit",没有错误提示了,相应的扩展命令也能正常使用。

看来就是因为使用64位版本windbg导致的。以后要注意了

 

本描述了“RSDS”或“DS”类型的pdb(程序数据库)文件的格式,这些文件是由Miscrosoft的link.exe从版本7及更高版本发出的。

什么是PDB文件?

如果选择了/DEBUG选项或/DEBUG:FULL选项,则最新的Microsoft链接器将在链接时创建程序数据库(pdb)文件。pdb文件包含有关创建可执行文件的信息,还包含最新CodeView格式的符号信息。可执行文件包含本地计算机上pdb文件的路径和文件名,以及标识码,以便可以找到正确的pdb文件。pdb文件本身的格式和最新的CodeView格式都没有文档记录。据我所知,格式已经改变了两次,而且很可能会再次改变。Microsoft提供API来分析和报告其Debug Information Access(DIA)SDK中pdb文件的内容。

可执行文件中的PDB文件信息

链接器将在链接时生成的pdb文件的文件名及其在本地计算机上的路径放在可执行文件的“CODEVIEW”调试目录中。如果缺少这个,很可能是因为生成了一个dbg文件。例如,如果在链接后运行REBASE程序,则可能会发生这种情况。在这种情况下,pdb文件的路径和文件名将包含在dbg文件中。然后,dbg文件的文件名将出现在可执行文件的“MISC”调试目录中。