Dependency Walker

　　Dependency Walker是一个免费的实用程序，可以扫描任何32位或64位Windows模块（exe，dll，ocx，sys等），并构建所有相关模块的分层树形图；对于找到的每个模块，它列出了该模块导出的所有函数，以及其他模块实际调用了哪些函数；另一个视图显示所需文件的最小集合，以及每个文件的详细信息，包括文件的完整路径，基本地址，版本号，机器类型，调试信息等；在此版本中增加了应用程序分析，这是一种用于观察正在运行的应用程序的技术，这允许Dependency Walker检测任何类型的损坏；因此，程序的探查器可以检测模块何时无法初始化，这通常会导致应用程序无法正确初始化错误；程序会立即扫描所有隐式，延迟加载和转发的依赖项，扫描完所有模块后，将显示结果，在术语结束时，这些模块称为动态或显式依赖项，如果没有实际运行应用程序并观察它，实际上无法检测动态依赖项，这正是Dependency Walker的应用程序分析所做的。强大又实用，需要的用户可以下载体验

应用介绍

　　Dependency Walker对于解决与加载和执行模块相关的系统错误也非常有用。Dependency Walker检测到许多常见的应用程序问题，例如缺少模块，模块无效，导入/导出不匹配，循环依赖性错误，模块的机器类型不匹配以及模块初始化失败。

　　Dependency Walker可在Windows 95,98，Me，NT，2000，XP，2003，Vista，7和8上运行。它可以处理任何32位或64位Windows模块，包括专为Windows CE设计的模块。它可以作为图形应用程序或控制台应用程序运行。Dependency Walker处理所有类型的模块依赖项，包括隐式，显式（动态/运行时），转发，延迟加载和注入。包括详细的帮助。

　　Dependency Walker完全免费使用。但是，您可能无法从其分发中获利，也不会将其与其他产品捆绑在一起。

　　软件功能

　　检测动态加载的模块，包括有关哪个模块实际调用LoadLibrary以动态加载模块的详细信息。

　　检测动态调用的函数，包括有关哪个模块实际调用GetProcAddress以获取函数地址的详细信息。

　　检测延迟负载依赖性。这是Microsoft Visual C ++ 6.0引入的一种新类型的依赖项。它们适用于Windows 95/98 / Me和Windows NT / 2000 / XP / 2003 / Vista / 7/8 / +。

　　控制台模式，允许在不显示其图形界面的情况下运行Dependency Walker。这对于批处理文件和Dependency Walker功能的无人值守自动化非常有用。

　　命令行选项，用于配置模块搜索顺序，列排序，输出文件，分析和其他设置。

　　能够监视模块入口点（如DllMain）以查找模块初始化失败。

　　C ++函数名称未修饰以提供人类可读的C ++函数原型，包括函数名，返回类型和参数类型。

　　用户可定义的模块搜索路径，支持“KnownDLL”和“App Paths”注册表项。可以从图形界面或命令行中保存和加载搜索路径。

　　能够将模块的会话保存到文本报告文件，以便在任何文本查看器中轻松查看。

　　能够将模块的会话保存为逗号分隔值（CSV）文件，以便轻松导入其他应用程序。

　　能够将整个模块会话的快照保存到图像文件，以后可以在任何计算机上由Dependency Walker加载。

　　模块分析以检测动态依赖项，子进程，线程活动和异常。还可以为子进程分析其依赖项。

　　能够控制哪些文件扩展名Dependency Walker会将“View Dependencies”菜单项添加到资源管理器中的文件上下文菜单中。

　　添加了热键以帮助将导入与导出匹配，并在列表视图中使用树视图中的模块添加模块。还添加了热键以在树视图中查找模块的上一个，下一个或原始实例。

　　在Module List View中添加了一些新列。它们包括链接时间戳，链接校验和，真实校验和，符号，实际基数，虚拟大小和加载顺序。

　　添加了OS信息对话框。此信息也会保存到文本和Dependency Walker Image（DWI）文件中。

　　现在可以按图标对所有列表视图进行排序，这样可以轻松地对相似类型的项目进行分组。

　　现在，您只需在当前排序的列中键入几个字符即可搜索所有列表视图的文本。

　　为模块列表视图和日志视图添加了颜色编码，以帮助突出显示问题。

　　模块可以通过多种方式依赖于另一个模块：

　　隐式相关性（因此被称为负载时依赖或有时错误地通过被称为静态依赖性）：模块A隐含地与在编译/链接时间模块B中的LIB文件链接的，和模块的源代码实际调用一个或多个功能在模块B模块B是模块A的负载时间依赖性和将不管加载到内存中，如果模块A实际上使呼叫在运行时到B的模块。模块B希望列在模块A的导入表中。

　　延迟加载相关性：模块A是延迟加载有用于在编译/链接时模块B中的LIB文件链接的，和模块的源代码实际调用一个或多个函数成模块为模块B是一个动态依赖，并且将仅如果加载模块A实际上使呼叫在运行时到B的模块。模块B将在模块A的延迟加载导入表中列出。

　　正向相关性：模块A与用于在编译/链接时模块B中的LIB文件链接的，和模块的源代码实际调用一个或多个函数成模块B.之一称为在模块B的功能实际上是一个转发函数调用模块C.模块B和C模块是模块A的两个相关性，但只有乙模块将在模块A的输入表中列出。

　　显式依赖性（因此被称为动态或运行时依赖性）：模块A不与在编译/链接时模块乙相连。在运行时，模块通过LoadLibrary函数类型A动态加载模块B。模块B成为模块A的运行时间相关性，但不会以任何模块A的表中列出。这种类型的依赖与OCX控件，COM对象和Visual Basic应用普遍。

　　发生这种类型的依赖性的当另一个应用程序钩在处理一个特定的事件（例如鼠标事件）：系统挂钩依赖（因此称为注射依赖）。什么时候主要生产过程，事件，操作系统可以注入一个模块插入进程来处理事件。并注入过程中的模块是不是真的依赖于任何其他的模块，但确实寓于DASS进程的地址空间。

　　Dependency Walker完全支持所有上述技术加载的模块。壳体1，2，和3中可以很容易地通过在只依赖沃克打开模块进行检测。案例4和5需要运行时分析，在Dependency Walker中2.0的新功能。有关分析的详细信息，请参阅使用应用程序分析来检测动态依赖性部分。

软件特色

　　要使分析工作，您在Dependency Walker中打开的模块必须是一个可执行文件（通常以.EXE结尾），该文件旨在在系统上运行。如果不是，则不会启用“开始概要分析”菜单选项和工具栏按钮。当您选择配置应用程序时，您的应用程序应该开始运行。在您的应用程序运行时，Dependency Walker希望收集信息并登录到日志视图，以及更新其他视图。

　　用户的工作是“运用”应用程序以确保找到所有动态依赖项。通常，动态依赖项仅在需要时加载。例如，如果应用程序实际打印，则可能仅加载与打印相关的模块。 Dependency Walker不希望检测与打印相关的模块。如果应用程序中发生错误，则只能加载其他模块。像这样的场景可能很难产生。因此，无法保证找到所有动态依赖关系。

　　Dependency Walker的应用程序分析器跟踪每个加载的模块。这允许将动态加载的模块插入到模块中。作为子项的依赖树视图。

　　分析器通过挂钩正在分析的远程进程中的特定函数调用来工作。在Windows 95，Windows 98和Windows Me上，只能挂接非系统模块。结果模块动态加载另一个模块，分析器无法分辨模块是谁用于动态加载的模块。无父模块喜欢添加到模块的依赖树视图的根目录。依赖关系树视图由于这些模块由OS加载并且没有父模块。尽管Dependency Walker可能无法检测到动态依赖关系的父级，但它确实如此。

　　分析器的最后一个好处是它可以纠正在初始隐式模块扫描期间可能未正确确定的任何模块的路径。首次在Dependency Walker中打开模块时，它会递归扫描所有导入和导出模块以构建初始模块层次结构。只有文件名存储在这些表中，因此依赖者walker使用规则。在分析期间，Dependency Walker会检查每个模块加载时的实际路径，并将它们与树中的模块进行比较。 Dependent Walker希望它加载，然后它将更新模块。

　　Dependency Walker不仅仅是一个故障排除工具。它还提供了有关特定应用程序的模块布局和每个模块的详细信息的大量有价值的信息。 Dependency Walker提供以下信息：

　　bullet特定应用程序所需的完整模块依赖关系树。

　　bullet每个模块发出的所有函数的列表。这些列表包括按名称导出的函数，按序号导出的函数以及实际转发到其他模块的函数。命名C ++函数可以以其本机修饰格式显示，或者可以扩展为人类可读的函数原型，包括返回类型和参数类型。

　　bullet其他模块在每个模块中实际调用的函数列表。这些列表可以帮助开发人员理解特定模块链接到应用程序的原因，从而提供有关如何从不依赖项中删除不需要的模块的信息。

　　bullet模块加载和运行所需的最小文件集列表。将文件复制到另一台计算机或创建安装脚本时，此列表非常有用。

　　bullet对于找到的每个单独模块，提供以下信息......

　　模块文件的完整路径。

　　bullet模块文件的日期和时间。

　　bullet模块实际构建的日期和时间。

　　bullet模块文件的大小。

　　bullet模块文件的属性。

　　bullet模块构建时的模块校验和。

　　bullet实际的模块校验和。

　　bullet CPU的类型

　　bullet子系统的类型

　　bullet与模块关联的调试符号的类型。

　　bullet模块的首选基本加载地址。

　　bullet模块的实际基本加载地址。

　　bullet模块的虚拟大小。

　　bullet模块相对于其他模块的加载顺序。

　　bullet在模块的版本资源中找到的文件版本。

　　bullet在模块的版本资源中找到的产品版本。

　　bullet在模块的文件头中找到的映像版本。

　　bullet用于创建模块文件的左侧版本。

　　bullet OS的版本。

　　bullet子系统的版本。

　　bullet如果在处理文件时发生任何错误，则可能出现错误消息。

安装说明

　　1、用户只需要点击本网站提供的下载地址即可将应用程序下载到磁盘

　　2、打开数据包，解压数据文件，得到可以直接使用的程序文件

　　3、双击主程序即可将其打开，进入主界面

使用说明

　　Dependency Walker递归扫描特定应用程序所需的所有相关模块。在此扫描期间，它执行以下任务：

　　bullet检测丢失的文件。这些是作为另一个模块的依赖项所必需的文件。此问题的症状是“无法在指定的路径中找到动态链接库BAR.DLL ...”错误。

　　bullet检测无效文件。此文件不符合Win32或Win64以及损坏的文件。此问题的症状是“应用程序或DLL BAR.EXE无效Windows映像”错误。

　　bullet检测导入/导出不匹配。验证是否实际从依赖模块导出所有模块。所有未解决的导入函数都标记有错误。此问题的症状是“过程入口点BAR无法位于动态链接库BAR.DLL中”错误。

　　bullet检测循环依赖性错误。这是一个非常罕见的错误，但转发功能可能会发生。

　　bullet检测不匹配的CPU类型的模块。使用CPU时会发生这种情况。

　　bullet通过验证模块校验和以检查是否已修改任何模块来检测校验和不一致。

　　bullet通过突出显示在其首选基址处失败的所有模块来检测模块冲突。

　　bullet通过跟踪对模块入口点的调用并查找错误来检测模块初始化失败。

　　因此，依赖性Walker可以执行应用程序的运行时配置文件，以检测动态加载的模块和模块初始化失败。从上面检查相同的错误也适用于动态加载的模块。

　　保证有四个版本的Windows模块。它们都是两部分版本号（＃。＃）。它们包括：

　　Image Version通过在DEF文件中使用VERSION语句或使用/ VERSION链接选项来设置此值。它通常表示模块所属的模块或产品的版本，但不能包含任何值，因为由开发人员来设置它。如果开发人员未指定版本，则此值将默认为0.0。在比较两个模块以检查哪个模块较新时，此值可用作最后的手段。

　　操作系统版本此值表示模块设计用于运行的操作系统版本。某些功能可能会根据此值而有所不同。

　　子系统版本此值表示模块设计为在哪个子系统版本上运行。大多数模块使用默认值，但是如果开发人员希望定位非默认子系统版本，则可以使用/ SUBSYSTEM链接选项覆盖默认值。根据此值，某些子系统功能可能会有不同的行为。

　　左侧版本此值表示用于构建模块的左侧版本。该模块经久耐用。例如，在延迟加载依赖性的情况下，模块不应具有任何延迟加载依赖性。

　　除了四个标准版本值之外，开发人员还可以通过在其资源文件中包含VERSION_INFO资源来添加四个可选版本值。此资源结构有两个由四部分组成的数字字段（＃。＃。＃。＃）和两个文本字段。它们包括：

　　文件版本值此字段在VERSION_INFO资源结构中称为“FILE VERSION”字段。此数值通常表示模块本身的版本，但不能包含任何值，因为由开发人员设置它。这是大多数程序在比较两个模块时使用的值，以检查哪个模块更新。

　　产品版本值此字段在VERSION_INFO资源结构中称为“PRODUCT VERSION”字段。此数值通常表示此模块所属的产品版本，但不能包含任何值。例如，“Acme Tools 3.0版”是一组实用程序，包括“Acme Virus Checker 1.5版”。病毒检查程序可执行文件的文件版本可能为1.5.0.0，产品版本可能为3.0.0.0

　　文件版本文本此字段在VERSION_INFO资源结构中称为“FileVersion”字段。此文本字符串通常表示模块本身的版本，但不能包含任何文本字符串。

　　产品版本文本此字段在VERSION_INFO资源结构中称为“ProductVersion”字段。此文本字符串通常表示此模块所属的产品版本，但不能包含任何文本字符串。

　　Dependency Walker显示真正的FILEVERSION和PRODUCT VERSION版本值，而不是文本字符串版本。其他应用程序（如“Windows属性”对话框）显示要查看的非技术用户的文本字符串。例如，如果模块的实际版本是2.0.5.2034，则在Windows属性对话框中只能看到“2.0”。 Dependency Walker而不是Windows属性对话框。

常见问题

　　问：Dependency Walker可以帮我弄清楚为什么我的组件不会注册？

　　[或]为什么REGSVR32.EXE无法注册我的DLL，但Dependency Walker没有显示我的DLL的任何错误？

　　答：许多模块需要在计算机上“注册”才能运行。这包括大多数ActiveX控件，OCX，COM组件，ATL组件，Visual Basic组件以及许多其他组件。这些类型的模块通常使用REGSVR32.EXE或类似的东西注册。在大多数情况下，REGSVR32.EXE加载您的DLL，为DLL的DllRegisterServer函数调用GetProcAddress，然后调用该函数。常见的失败是当您的DLL依赖于另一个丢失或未注册的DLL时。如果您只是在Dependency Walker中打开DLL，您可能会看到问题，也可能看不到问题，具体取决于注册失败的类型。

　　Dependency Walker中的REGSVR32.EXE而不是您的DLL。然后选择开始分析（F7）。在“性能分析”对话框中，在“程序参数”字段中输入DLL的完整路径。对于“Starting directory”，您可能希望输入包含DLL所在的目录。选中您要使用的选项，然后按确定。这将运行REGSVR32.EXE并尝试注册您的DLL。通过实际运行REGSVR32.EXE，您可以看到更多类型的运行时错误。

　　问：我的应用程序在被Dependency Walker分析时比在我自己运行它时运行得更好。这是为什么？

　　答：在Dependency Walker下进行分析时，我遇到了崩溃。在分析应用程序时，Dependency Walker充当调试器。这本身就会使您的程序以不同的方式运行。

　　首先，存在依赖性的开销Walker会降低应用程序的执行速度。如果您的应用程序因某些竞争条件而崩溃，则可能会单独放慢速度。如果是这种情况，那么这是应用程序的设计问题，当它没有崩溃时你就会很幸运。

　　其次，通常当线程阻塞关键部分，事件，信号量，互斥体等时，它们以先进先出（FIFO）为基础解锁。操作系统无法保证这一点，但通常情况就是如此。当您在调试器下时，FIFO队列有时是随机的，因此线程可能以与在调试器下运行时不同的顺序阻塞和恢复。这可能会在竞争条件下缓解。同样，应用程序在没有崩溃的情况下变得幸运。

　　最后，在调试器下运行的应用程序会自动获得系统调试堆。所有内存功能处理略有不同。分配用保护字节填充，以检查您是否在已分配的区域之外写入（缓冲区溢出/欠载）。在不在调试器下的情况下，分配可能在内存中的布局不同。因此，如果您在调试器下编写缓冲区的末尾，则可能会丢弃保护字节，释放内存或仅仅是非常关键的内容。但是，当您在调试器下时，您可能会发现一些重要的事情，并且您的应用程序崩溃了。

　　对于调试堆，您可以将其关闭到Dependency Walker，看看您的应用程序在被分析时是否崩溃。如果它然后，那么您可能会遇到缓冲区溢出，杂散/错误/释放指针等。为此，请启动命令提示符。输入“SET_NO_DEBUG_HEAP = 1”。然后从该命令行启动Dependency Walker。这应该禁用Dependency Walker实例的调试堆。请注意，这仅适用于Windows XP及更高版本。

　　问：如何查看函数的参数和返回类型？

　　答：对于大多数功能，此信息根本不存在于模块中。 Windows的模块文件格式仅提供单个文本字符串来标识每个函数。没有结构化的方法来列出参数的数量，参数类型或返回类型。例如，使用简单装饰编码的int Foo（int，int）函数可能会导出为_Foo @ 8日8指的是参数使用的字节数。如果使用C ++修饰，该函数将被导出为？Foo @@ YGHHH @ Z，它可以直接解码回函数的原始原型：int Foo（int，int）。 Dependency Walker使用Undecorate C ++ Functions命令支持C ++ undecoration。

　　问：为什么我的函数被外部调用然后我声明它们？

　　答：默认情况下，许多编译器“装饰”函数名称。如果使用C ++装饰，Foo（int，int）可能最终导出为_Foo @ 8，甚至是Foo @@ YGHHH @Z。像C ++这样的语言允许函数重载，这是能够声明具有相同名称但具有不同参数的多个函数。因此，每个函数都有一个唯一的签名，因为只导出名称会导致名称冲突。要禁用C ++修饰，可以在C ++源文件中声明函数时使用外部“C”表示法。要防止和处理实际功能，可以将DEF文件添加到C / C ++项目中。

　　问：我的应用程序在分析期间似乎没问题，但是，我在日志视图中看到错误，在其他视图中看到红色或黄色图标。这是正常的吗？

　　答：在分析过程中看到错误或警告是很正常的。一个常见错误是当一个模块尝试动态加载另一个模块时（使用其中一个加载库函数），但找不到该模块。 Dependency Walker记录了这个失败，但是如果应用程序为失败做好了准备，那么这不是问题。另一个常见错误是模块尝试在模块中动态定位函数（使用GetProcAddress）。同样，这不是问题。您可能会在日志视图中看到第一次机会异常。如果应用程序处理异常并且它们不会变成第二次机会异常，那么这不是问题。所有这些情况都是正常的，通常可以忽略不计。但是，如果您正在分析的应用程序崩溃或无法正常运行，那么错误

　　问：哇，我的应用程序取决于所有这些文件？我需要使用我的应用程序重新分发哪些内容？

　　答：首先，某些模块应该永远不会与您的应用程序一起重新分发，例如kernel32.dll，user32.dll和gdi32.dll。要查看允许重新分发的文件，可以在开发计算机上查找名为REDIST.TXT的文件。此文件包含在Microsoft Visual C ++和Visual Basic等开发套件中。因此，你可以看一下在MSDN指数“再分发的文件”和“REDIST.TXT”的详细信息，什么样的文件重新分配，如何将它们重新分配，如何检查的文件版本等。

　　问：“模块共享未挂钩”是什么意思，为什么某些模块的DllMain调用永远不会被记录？

　　答：Dependency Walker在加载模块时挂钩模块，以跟踪对DllMain，LoadLibrary和GetProcAddress等函数的调用。在Windows 95/98 / Me上加载到地址0x80000000（通常是系统模块）之上的任何模块都是在系统范围内共享的，无法挂钩。结果是Dependent Walker无法在这些模块中记录有关函数调用的信息。 Windows NT / 2000 / XP / 2003 / Vista / +没有此限制。有关详细信息，请参阅使用应用程序分析检测动态依赖关系。

　　问：为什么某些模块在单个父模块下出现不止一次？

　　答：Dependency Walker可能会多次显示一个模块，通知您它是一个依赖项，原因不止一个。模块可以显示为隐式链接依赖项，转发依赖项和动态依赖项，所有这些都在单个父模块下。有关更多详细信息，请参阅模块依赖关系树视图。实际上，在运行时，只有一个模块副本驻留在内存中。

　　问：是否有Dependency Walker的命令行版本？

　　答：Dependency Walker可以用作图形应用程序或控制台应用程序。使用控制台模式选项时，Dependency Walker可以处理模块，保存结果，并在没有任何图形界面或用户提示的情况下退出。有关详细信息，请参阅“命令行选项”部分。

　　问：Dependency Walker是否可以使用COM，Visual Basic或.NET模块？

　　答：是的。 Dependency Walker希望使用任何32位或64位Windows模块，无论使用何种语言进行开发。但是，许多语言都有自己的方式来指定模块之间的依赖关系。例如，COM模块可能在注册表中嵌入了库和注册信息，.NET模块可能使用.NET程序集。这些技术都是作为核心Windows API之上的层实现的。 Windows函数如LoadLibrary和GetProcAddress可以完成实际工作。正是在这个核心层面，Dependency Walker才能理解正在发生的事情。因此，虽然Dependency Walker不了解应用程序的所有语言特定复杂性，但它希望能够在Windows API级别跟踪所有模块活动。

　　问：Dependency Walker是否可以使用64位模块？

　　答：是的。 Dependency Walker希望使用任何32位或64位Windows模块。有32位和64位版本的Dependency Walker。所有版本都能够打开32位和64位模块。但是，使用32位Dependency Walker处理32位模块和使用64位Dependency Walker处理64位模块有很大的优势。在64位版本的Windows上运行时尤其如此，它允许执行32位和64位程序。 64位Windows上的32位子系统（称为“WOW64”）具有自己的私有注册表，“AppPaths”，“KnownDlls”，系统文件夹和清单处理。只有32位版本的Dependency Walker才能访问这个32位模块，这是一个32位模块。同样，只有64位版本的Dependency Walker才能完全访问64位环境，因此应始终用于处理64位模块。

　　问：MFC42.DLL正在尝试加载MFC42LOC.DLL，但找不到它。

　　[或] COMCTL32.DLL正在尝试加载CMCTLENU.DLL，但找不到它。这是为什么？

　　答：MFC42LOC.DLL和CMCTLENU.DLL都是特定于语言的资源DLL，无法在您的系统上访问。在运行时，模块加载操作系统的当前语言的语言DLL。该模块的名称中的“ENU”通常最终为美国英语，“ESP”西班牙，“JPN”日本等MFC使用的“LOC”结尾代表“本地化”。安装MFC时，它会将正确的语言复制到MFC42LOC.DLL。那么，为什么缺少模块呢？通过在主DLL本身中存储一种默认语言。语言特定资源DLL无法加载，然后模块默认使用本地资源本身。在大多数情况下，这些默认资源与资源DLL的ENU版本中的默认资源相同。因此，无需了解DLL的ENU版本，因此无法在运行时找到它。这很正常。