将 .NET COM Interop 程序集与其托管进程断开
当 ActiveXObject 托管在 Windows 桌面/边栏小工具中时,该 ActiveXObject 会被缓存,并且它的 DLL 文件会被锁定(这意味着它无法移动、删除或重命名)。问题是这样的;当该小工具随后关闭时,DLL 仍被 Windows 边栏锁定并且无法删除。这会导致一个严重的问题,即新版本的小工具无法安装在以前版本的小工具之上,在删除它的过程中会失败,并且不会出现任何错误消息。
这对于用户来说不是很友好,因此我正在寻找一种在小工具卸载事件期间以某种方式“切断”与 ActiveX 控件的联系的方法。我希望有人能告诉我这是否可行,如果可行,请给我一些关于如何实现它的想法。
仅供参考,Windows 边栏小工具实际上只是 Internet Explorer 服务器窗口,因此可以安全地假设 IE 表现出相同的行为。
编辑: Unlocker 似乎做了我需要做的事情,那么我怎样才能在.NET中以编程方式实现同样的事情呢?
When an ActiveXObject is hosted in a Windows Desktop/Sidebar Gadget, that ActiveXObject is sort of cached and the DLL file for it is locked (meaning it cannot be moved, deleted or renamed). The problem is this; when the gadget is subsequently closed, the DLL is still locked by Windows Sidebar and it cannot be removed. This causes a significant problem whereby a new version of the gadget cannot be installed over the top of a previous version of the gadget, it fails during the process of deleting it without any error messages.
This isn't very user-friendly, so I'm looking for a way to "sever" ties to the ActiveX control somehow during the gadget's unload event. I'm hoping someone can tell me whether or not this is possible and if it is give me some ideas on how to implement it.
FYI, Windows Sidebar Gadgets are actually just Internet Explorer server windows, so it's probably safe to assume IE exhibits the same behavior.
EDIT: Unlocker seems to do pretty much what I need to do, so how can I achieve the same thing programmatically in .NET?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
好吧,这是一个相当复杂的问题。我以前见过这种行为,我不熟悉 Windows 桌面/侧边栏小工具,因为我不使用它。不过,我已经设法想出了三种可能的攻击方法
1。 来自 TechNet 的句柄
这不是我的主意, 还有另一个 StackOverflow 线程 推荐这个方法。但我对这是否有效持怀疑态度。文件锁(该实用程序处理的内容)和“加载库”锁之间存在差异,我认为这就是您在使用 ActiveX 时遇到的问题。
我稍微修改了该线程的代码,他们使用 Process.Kill() 来释放锁,我认为最好使用handle.exe 来释放锁。
...
2。 Win32 风格
互联网上没有太多关于此的信息,并且似乎需要一些未记录的 api 调用才能顺利实现此目的。
我这些 C++ 示例可能会有所帮助。
不幸的是我无法让它无缝工作。我已经使用 MS Word 中加载的 ActiveX 测试了此方法。然后我尝试解锁ActiveX,它不是很稳定,经常导致word崩溃。我想我没有正确破译上述程序所需的 C++ 战争创伤。
连同 CreateRemoteThread in C# 的示例一起,我确实将这段代码放在一起。
...
3。只需使用 Unlocker
这是我最好的建议。来自 technet 的句柄无法处理加载的 dll/ocx 锁(根据我的测试)。 Win32 是混乱且无文档的。
Unlocker 提供命令行访问,因此您可以按照与handle.exe 完全相同的方式调用它。只是搞怪一个/?在unlocker.exe之后在命令提示符下查看开关。
还有便携式版本的 Unlocker 可用,以便您可以将其捆绑到您的部署中,而无需强制最终用户安装该应用程序。
如果其他方法都失败,您可以联系 Unlocker 的作者,从他的自述文件中查看此内容。
...
4。使用 Process Hacker 共享库
我刚刚发现了这个出色的工具:Process Hacker 这是用 100% C# 代码编写(尽管它在底层确实通过 P/Invoke 使用了许多 WinAPI 函数)。
最好的一点是:它是开源的(LGPL),并提供了两个开发人员可以在其解决方案中引用的库:ProcessHacker.Common ProcessHacker.Native。
我下载了源代码,只是警告一句,这是一个相当大的解决方案,因此可能需要一些时间才能弄清楚到底什么/如何使用它。
它使用我在选项 2 中谈到的未记录的 API 函数 (ntdll.dl),并且可以执行 Unlocker 可以执行的所有操作,甚至更多。
Okay this is a rather complex problem. I have seen this behavior before, I'm not familiar with the Windows Desktop/Sidebar Gadget as I don't use it. However I've managed to come up with three possible methods of attack
1. Handle from TechNet
This wasn't my idea, there is another StackOverflow thread that recommends this method. However I'm skeptical as to whether or not this will work. There is a difference between a file lock (what this utility handles) and a "loaded library" lock which is what I assume is the problem you are having with ActiveX.
I modified the code from that thread slightly, there they use Process.Kill() to release the lock, I would think it's better to use handle.exe to release the lock.
...
2. Win32 Style
There isn't a lot of info on the internets about this, and it would seem there are some undocumented api calls that are needed to pull this off smoothly.
I these c++ examples might help.
Unfortunately I couldn't get this to work seamlessly. I have tested this method using an ActiveX loaded in MS Word. I then tried to unlock the ActiveX, it's not very stable and often caused word to crash. I guess I don't have the required c++ war wounds to decipher the above programs correctly.
Along with this example of CreateRemoteThread in C# I did put this code together.
...
3. Just use Unlocker
This is my best recommendation. Handle from technet can't handle loaded dll/ocx locks (under my tests). Win32 is messy and undocumented.
Unlocker provides command line access so you can call it in exactly the same way as handle.exe. Just wack a /? after unlocker.exe in a command prompt to see the switches.
There is also a portable version of Unlocker available so you can bundle it into your deployment without forcing the end users to install the app.
If all else fails you could contact the author of Unlocker, check out this from his readme.
...
4. Use Process Hacker Shared Libraries
I just discovered this brilliant tool: Process Hacker which is written in 100% C# code (although it does use a lot of WinAPI functions via P/Invoke under the hood).
The best thing about this:it's open source (LGPL'd) and provides two libraries that developers can reference in their solutions: ProcessHacker.Common ProcessHacker.Native.
I downloaded the source and just a word of warning it's a pretty big solution so may take a bit of time to figure out exactly what/how to use it.
It uses the undocumented API functions (ntdll.dl) I spoke about in option 2 and can do everything Unlocker can and a whole lot more.
不确定这是否适用于 ActiveX 对象,但它确实适用于 .NET 程序集。我将它用于单元测试,其中 DLL 必须顺利覆盖。使用的机制是卷影复制。
从应用程序外部关闭句柄似乎并不是一个非常安全的选择。
这不是解决方案,也许是一个想法或方向......
Not sure if this works for ActiveX objects but it definitively does for .NET assemblies. I use it for UnitTesting where the DLLs have to be overwritten smoothly. The mechanism used is shadow copying.
Closing handles from outside an application seems not really a very safe option.
It is not the solution maybe an idea or direction...