WatiN 在 x64 系统上找不到任何浏览器
我在运行 .NET 应用程序的 x64 系统上看到一些奇怪的问题。
我们的应用程序使用 WatiN 在基于浏览器的 Web 应用程序上执行自动化操作。
在上述 x64(Windows 7 Enterprise)桌面上,WatiN 无法找到打开的浏览器。
在内部,我相信 WatiN 被编程为使用 Win32 API 枚举所有打开的窗口,并查看是否有符合给定条件的窗口。
我的问题是:如果我的进程作为 x86 加载(我在 taskmgr 中看到 *32 旁边),则调用一些标有 DllImport( ... ) 的方法可能会加载 x64 版本? (例如EnumWindows是在User32.dll中定义的),那么它加载的是哪个版本? C:\Windows\System32 或 C:\Windows\SysWOW64 中的一个
我们的应用程序是在 x86 配置中编译的,但是一些引用的程序集是在“任何CPU”。
这会导致正确加载正确版本 (x86/x64) 引用 DLL/程序集时出现任何问题吗?
编辑:添加了已加载模块的内存转储: http://www.pasteall.org/27134/text
请注意,某些模块实际上是从 Windows\SysWOW64 加载的,而其他模块(例如 SHDocVW.dll)是从 C:\Windows\System32 加载的,
这是否表明该系统上的 32/64 之间可能存在冲突?
我已经调试了 WatiN 的代码,直到调用某些本机方法来枚举窗口返回 null(尽管某些 IE 窗口可用)。
我该如何进一步调试这个奇怪的问题?
作为对故障机器进行诊断测试的一部分(并非所有机器上都会发生这种情况),我制作了一个简单的诊断应用程序,它引用了一个调用 EnumWindows 的库。
像这样的东西:
DebugApp -> DebugLib
其中每一个都在 x86 和任何 CPU 中编译,并对 4 种不同的组合进行了测试。
- 我在我的桌面(32 位)上运行了这个,这导致了 4 个相同的 输出。
- 在 Windows Server 2008 R2(64 位)上,它创建了 3 个相同的输出, 1 次运行崩溃(如预期 - 64 位 EXE 和 32 位 Lib)。
- 在发生故障的机器上,这创建了 4 个相同的文件,例如 我的,怎么会这样呢?它应该导致应用程序崩溃!
诊断后有什么想法吗?
I am seeing some weird issues on a x64 system running our .NET app.
Our app uses WatiN to perform automated actions on browser based web apps.
On the said x64 (Windows 7 Enterprise) desktop, WatiN fails to find open browsers.
Internally i believe, WatiN is programmed to enumerate all open windows using the Win32 API, and see if any match the given criteria.
My question is: If my process is loaded as a x86 (I see *32 next to in in taskmgr), calling some method that is marked with DllImport( ... ) May potentially load the x64 version? (EnumWindows is defined in User32.dll for example), which version of it is loaded then? The one in C:\Windows\System32 or the one in C:\Windows\SysWOW64
Our application is compiled in x86 configuration, however some of the referenced assemblies are compiled in "Any CPU".
Can that cause any issues of properly loading the correct versions (x86/x64) references DLLs/assemblies?
EDIT: Added a memory dump of loaded modules: http://www.pasteall.org/27134/text
Note that some modules are actually loaded from Windows\SysWOW64 and others like SHDocVW.dll are from C:\Windows\System32
Can this point out to a possible collision between 32/64 on that system?
I have debugged WatiN's code up to the point where a call to some native method to enumerate windows returns null (although some IE windows were available).
How can i further debug this strange issue?
As part of diagnostic testing on the failing machine (this doesn't occur on all machines), i have made a simple diagnostic application that references a lib that calls EnumWindows.
Something like this:
DebugApp -> DebugLib
Each of these was compiled in x86 and Any CPU, and the 4 different combinations were tested.
- I ran this on my desktop (32 bit) which caused in 4 identical
outputs. - On a Windows Server 2008 R2 (64 bit) it created 3 identical outputs,
and 1 run crashed (As Expected - 64Bit EXE with a 32bit Lib). - On the machine that is failing, this created 4 identical files, like
mine, how this can be? it should've resulted in an app crash!!
Any ideas after this diagnostic?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论