Dependency Walker是一款专业的DLL神器。一款功能强大的实用程序Dependency Walker。该模块导出的所有函数，以及其他模块实际调用的函数；另一个视图显示了所需文件的最小集合，以及每个文件的详细信息，包括文件的完整路径，基地址，版本号，机器类型，调试信息等；在此发行版中，添加了应用程序分析，这是一种用于观察正在运行的应用程序的技术，该技术使Dependency Walker能够检测到任何类型的损坏。因此，程序的探查器可以检测到模块“无法初始化”，这通常会导致应用程序无法正确初始化；该程序立即扫描所有隐式，延迟加载和转发的依赖项，并在扫描所有模块后显示结果。动态或显式依赖项，如果不实际运行应用程序并对其进行观察，就无法实际检测到动态依赖项，这正是Dependency Walker的应用程序分析所要做的。功能强大且实用，需要它的用户可以下载体验。
使用说明：
Dependency Walker递归扫描特定应用程序所需的所有相关模块。在此扫描期间，它将执行以下任务：
项目符号检测到丢失的文件。这些是依赖于另一个模块的文件。此问题的症状是在指定的路径中出现“找不到动态链接库BAR.DLL ...”错误。
项目符号检测到无效文件。此文件不符合Win32或Win64和损坏的文件。此问题的症状是“应用程序或DLL BAR.EXE无效的Windows映像”错误。
项目符号检测到导入/导出不匹配。验证所有模块实际上都是从相关模块中导出的。所有未解决的导入功能均标记有错误。此问题的症状是“进程入口点BAR不能位于动态链接库BAR.DLL中”错误。
项目符号检测循环依赖项错误。这是非常罕见的错误，但是可能会发生转发功能。
项目符号检测到与CPU类型不匹配的模块。使用CPU时会发生这种情况。
等通过验证模块校验和以检查是否已修改任何模块来检测不一致的校验和。
项目符号通过突出显示在其首选基地址失败的所有模块来检测模块冲突。
Bullet通过跟踪对模块入口点的调用并查找错误来检测模块初始化失败。
因此，依赖项Walker可以执行应用程序的运行时配置文件来检测动态加载的模块和模块初始化失败。从上面检查相同的错误也适用于动态加载的模块。
确保Windows模块有四个版本。它们都是两部分的版本号（＃。＃）。他们包括：
映像版本通过使用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中打开的模块必须是旨在在系统上运行的可执行文件（通常以.EXE结尾）。如果未启用，则不会启用“开始分析”菜单选项和工具栏按钮。当您选择配置应用程序时，您的应用程序应开始运行。在您的应用程序运行时，Dependency Walker希望收集信息并登录到日志视图，并更新其他视图。
用户的工作是“应用”应用程序，以确保找到所有动态依赖项。通常，仅在需要时才加载动态依赖项。例如，如果应用程序实际打印，则它可能仅加载与打印相关的模块。 Dependency Walker不想检测与打印相关的模块。如果应用程序中发生错误，则只能加载其他模块。这样的场景可能很难产生。因此，不能保证将找到所有动态依赖项。
Dependency Walker的应用程序分析器跟踪每个已加载的模块。这允许将动态加载的模块插入模块。依赖项树视图作为子级。
解析器通过在正在分析的远程进程中挂接特定的函数调用来工作。在Windows 95，Windows 98和Windows Me上，您只能安装非系统模块。结果，该模块会动态加载另一个模块，分析仪无法区分谁是动态加载模块。无父母的模块喜欢添加到模块依赖树视图的根。依赖关系树视图是因为这些模块由OS加载并且没有父模块。尽管Dependency Walker可能无法检测动态依赖项的父项，但它确实可以。
分析仪的最后一个好处是，它可以纠正在初始隐式模块扫描期间可能无法正确确定的任何模块的路径。在Dependency Walker中首次打开模块时，它将递归扫描所有导入和导出的模块以构建初始模块层次结构。这些表中仅存储文件名，因此依赖项遍历器使用规则。在分析过程中，Dependency Walker会在加载每个模块时检查实际路径，并将其与树中的模块进行比较。从属Walker希望加载它，然后它将更新模块。
Dependency Walker不仅仅是故障排除工具。它还提供了有关特定应用程序的模块布局的大量有价值的信息，以及有关每个模块的详细信息。 Dependency Walker提供以下信息：
列出特定应用程序所需的完整模块依赖关系树。
项目符号每个模块发出的所有功能的列表。这些列表包括按名称导出的功能，按序列号导出的功能以及实际转发的功能
到其他模块。命名的C ++函数可以以其本机修饰的格式显示，或者可以扩展为人类可读的函数原型，包括返回类型和参数类型。
项目符号其他模块在每个模块中实际调用的功能列表。这些列表可以帮助开发人员了解为什么将特定模块链接到应用程序，从而提供有关如何从非依赖性中删除不需要的模块的信息。
载和运行所需的最小文件集的项目符号模块列表。将文件复制到另一台计算机或创建安装脚本时，此列表很有用。
项目符号为找到的每个单独模块提供以下信息...
模块文件的完整路径。
目符号模块文件的日期和时间。
项目符号模块实际构建的日期和时间。
项目符号模块文件大小。
项目符号模块文件属性。
验证构建项目符号模块时的模块校验和。
项目符号实际模块校验和。
子弹PU类型
项目符号子系统类型
项目符号与模块关联的调试符号的类型。
的子弹模块的首选基本装载地址。
项目符号模块的实际基本加载地址。
虚拟项目符号模块的虚拟大小。
项目符号模块相对于其他模块的加载顺序。
项目符号在模块的版本资源中找到的文件版本。
项目符号在模块的版本资源中找到的产品版本。
项目符号在模块文件头中找到的图像版本。
项目符号用于创建模块文件的左版本。
项目符号操作系统版本。
项目符号子系统版本。
项目符号如果在处理文件时发生任何错误，则可能会出现错误消息
常见问题：
问：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中的RE REGSVR32.EXE而不是您的DLL。然后选择开始分析（F7）。在“性能分析”对话框中，在“程序参数”字段中输入DLL的完整路径。对于“起始目录”，您可能希望输入包含DLL的目录。选中您要使用的选项，然后按OK。这将运行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 @ 8day8，它引用该参数使用的字节数。如果使用C ++装饰，该函数将被导出为？ Foo @@ YGHHH @ Z，它可以直接解码回该函数的原始原型：int Foo（int，int）。 Dependency Walker使用Undecorate C ++ Functions命令支持C ++取消修饰。
问：为什么在外部调用我的函数，然后再声明它们？
答：许多编译器默认情况下“修饰”函数名称。如果使用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 / ++没有此限制。有关更多信息，请参见使用应用程序分析检测动态依赖关系。
问：为什么某些模块在单个父模块下出现多次？
答：依赖项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模块。有Dependency Walker的32位和64位版本。所有版本都可以同时打开32位和64位模块。但是，对于32位模块使用32位Dependency Walker，对于64位模块使用64位Dependency Walker具有很大的优势。当在64位版本的Windows上运行时，尤其如此，它允许执行32位和64位程序。 64位Windows上的32位子系统（称为“ WOW64”）具有其自己的专用注册表，“ AppPaths”，“ KnownDlls”，系统文件夹和清单处理。只有Dependency Walker的32位版本可以访问此32位模块，它是32位模块。同样，只有Dependency Walker的64位版本才可以完全访问64位环境，因此应始终用于处理64位模块。
问：MFC42.DLL试图加载MFC42LOC.DLL，但找不到它。
[或者] COMCTL32.DLL试图加载CMCTLENU.DLL，但是找不到它。这是为什么？
答：MFC42LOC.DLL和CMCTLENU.DLL都是特定于语言的资源DLL，无法在您的系统上访问。在运行时，该模块将加载操作系统当前语言的语言DLL。模块名称中的“ ENU”通常以美式英语结尾，西班牙为“ ESP”，日本为“ JPN”等。“ LOC”结尾表示“本地化”。安装MFC时，它将正确的语言复制到MFC42LOC.DLL。那么为什么缺少模块？通过在主DLL本身中存储默认语言。无法加载特定于语言的资源DLL，然后默认情况下模块将使用本地资源本身。在大多数情况下，这些默认资源与ENU版本的资源DLL中的默认资源相同。因此，无需知道DLL的ENU版本，因此无法在运行时找到它。这很正常。
安装说明：
1.用户只需单击此网站上提供的下载地址即可将应用程序下载到磁盘
2，打开数据包，解压数据文件，获取可以直接使用的程序文件
3.双击主程序将其打开并进入主界面
应用介绍：
Dependency Walker对于解决与加载和执行模块有关的系统错误也非常有用。 Dependency Walker检测到许多常见的应用程序问题，例如缺少模块，无效模块，导入/导出不匹配，循环依赖项错误，模块机器类型不匹配以及模块初始化失败。
Dependency Walker可以在Windows 95、98，Me，NT，2000，XP，2003，Vista，7和8上运行。它可以处理任何32位或64位Windows模块，包括专为Windows CE设计的模块。它可以作为图形应用程序或控制台应用程序运行。依赖性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”和“应用程序路径”注册表项。您可以从图形界面或命令行保存和加载搜索路径。
能够将模块会话保存到文本报告文件中，以便在任何文本查看器中轻松查看。
能够将模块会话另存为逗号分隔值（CSV）文件，以便轻松导入其他应用程序。
能够将整个模块会话的快照保存到图像文件，以后可以由Dependency Walker在任何计算机上加载。
模块分析以检测动态依赖性，子进程，线程活动和异常。您还可以分析其对子进程的依赖性。
能够控制哪些文件扩展名，Dependency Walker会将“查看依赖项”菜单项添加到资源管理器中的文件上下文菜单中。
添加了热键以帮助将导入与导出匹配，并使用树形视图中的模块在列表视图中添加了模块。还添加了热键，以在树视图中查找模块的上一个，下一个或原始实例。
在“模块列表视图”中添加了一些新列。它们包括链接时间戳，链接校验和，实际校验和，符号，实际基数，虚拟大小和加载顺序。
添加了操作系统信息对话框。此信息也保存到文本和Dependency Walker图像（DWI）文件中。
现在，所有列表视图都可以按图标排序，这使得对相似类型的项目进行分组变得容易。
现在，您只需在当前排序的列中键入几个字符即可搜索所有列表视图的文本。
在模块列表视图和日志视图中添加了颜色编码，以帮助突出显示问题。
一个模块可以通过几种方式依赖于另一个模块：
隐式依赖项（因此称为加载时依赖项，有时也错误地称为静态依赖项）：模块A在编译/链接时与模块B中的LIB文件隐式链接，并且模块的源代码实际上在模块B中调用一个或多个函数。模块B是模块A和wil的加载时间相关性
如果模块A在运行时实际上对模块B进行了调用，则不会加载到内存中。模块B希望在模块A的导入表中列出。
延迟加载的依赖性：编译/链接时，模块A被延迟加载以链接模块B中的LIB文件，并且模块的源代码实际上将一个或多个函数调用到模块中。模块B是动态依赖项，只有在模块A实际加载时才会在运行时调用模块B。模块B将在模块A的延迟加载导入表中列出。
正向相关性：模块A用于在编译/链接时链接模块B中的LIB文件，并且该模块的源代码实际上将一个或多个函数调用到模块B中。一个称为模块B中的实际函数是一个转发函数调用模块C。模块B和模块C是模块A的两个依赖项，但是模块A的输入表中仅列出了模块B。
显式依赖性（因此称为动态或运行时依赖性）：模块A在编译/链接时未连接至模块B。在运行时，模块通过LoadLibrary函数类型A动态加载模块B。模块B成为模块A的运行时依赖项，但未在模块A的任何表中列出。 OCX控件，COM对象和Visual Basic应用程序常见这种类型的依赖关系。
类型当另一应用程序挂接以处理特定事件（例如鼠标事件）时，将发生这种类型的依赖关系：系统挂钩依赖关系（因此称为名称注入依赖关系）。当主要生产过程为事件时，操作系统可以将模块注入过程中以处理事件。注入过程中的模块是否确实依赖于任何其他模块，但它确实位于DASS过程的地址空间中。
Dependency Walker完全支持上述技术加载的所有模块。仅依靠Walker打开模块即可轻松测试机柜1、2和3。情况4和5需要运行时分析以及Dependency Walker 2.0中的新功能。有关分析的更多信息，请参见使用应用程序分析检测动态依赖项。
