.NET 应用程序上的 Dependency Walker：FlsAlloc
我尝试在dependency walker中分析几个.NET可执行文件，总是得到这样的结果：
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") 从地址0x79006079处的“MSCOREE.DLL”调用并返回0xFFBADD11。
我尝试制作一个新的 Windows 窗体项目 VS2005，但除了构建它之外什么也没做。依赖步行者仍然给出同样的错误。这是否意味着不再可能分析 .Net 应用程序，或者我错过了什么？
I have tried to profile several .NET executables in dependency walker and always get something like this:
GetProcAddress(0x7C800000 [KERNEL32.DLL], "FlsAlloc") called from "MSCOREE.DLL" at address 0x79006079 and returned 0xFFBADD11.
I tried making a new windows forms project VS2005 and did nothing but build it. Dependency walker still gives that same error. Does this mean that it is no longer possible to profile .Net applications, or am I missing something?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
依赖遍历器只能分析非托管程序。
Dependency walker can only profile unmanaged programs.
有同样的问题，但常见问题解答是这样说的：
Will Dependency Walker work with COM, Visual Basic, or .NET module?
是的。 Dependency Walker 将与任何 32 位或 64 位 Windows 模块一起使用，无论使用什么语言来开发它。然而，许多语言都有自己的方式来指定模块之间的依赖关系。例如，COM 模块可能在注册表中嵌入了类型库和注册信息，而 .NET 模块可能使用 .NET 程序集。这些技术都是作为核心 Windows API 之上的层实现的。最后，这些层仍然需要调用 LoadLibrary 和 GetProcAddress 等核心 Windows 函数来完成实际工作。正是在这个核心级别，Dependency Walker 才了解正在发生的事情。因此，虽然 Dependency Walker 可能无法理解应用程序的所有语言特定复杂性，但它仍然能够跟踪核心 Windows API 级别的所有模块活动。
Having the same problem, but the FAQ says this:
Will Dependency Walker work with COM, Visual Basic, or .NET modules?
Yes. Dependency Walker will work with any 32-bit or 64-bit Windows module, regardless of what language was used to develop it. However, many languages have their own way to specify dependency relationships between modules. For example, COM modules may have embedded type libraries and registration information in the registry, and .NET modules may use .NET assemblies. These techniques are all implemented as layers above the core Windows API. In the end, these layers still need to call down to the core Windows functions like LoadLibrary and GetProcAddress to do the actual work. It is at this core level that Dependency Walker understands what is going on. So, while Dependency Walker may not understand all the language specific complexities of your application, it will still be able to track all module activity at a core Windows API level.