windows 为什么这个 pyd 文件在某些计算机上无法导入？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/751339/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why does this pyd file not import on some computers?
提问by Salim Fadhley
My python project has a C++ component which is compiled and distributed as a .pyd file inside a Python egg. I've noticed that it seems to be incompatible with only some of our our brand new 64 bit Windows servers. We have 4 (allegedly) identically provisioned machines - each of them runs Windows 2003 server 64 bit edition, but 2 of these machines do not allow me to call functions in the egg.
我的 python 项目有一个 C++ 组件，它在 Python 蛋中作为 .pyd 文件编译和分发。我注意到它似乎只与我们全新的 64 位 Windows 服务器中的一些不兼容。我们有 4 台（据称）配置相同的机器——每台机器都运行 Windows 2003 server 64 位版本，但其中 2 台机器不允许我调用鸡蛋中的函数。
After some experimentation I was able to find a recipe for producing a reproducible error. The problem seems to occur when Python tries to import the pyd file.
经过一些实验，我找到了产生可重现错误的方法。问题似乎发生在 Python 尝试导入 pyd 文件时。
I copied the pyd to a temp folder and ran Python.exe from that location, incidentally we are still using the 32bit edition of Python 2.4.4 since none of our libraries have been ported to 64 bit architecture yet. Next I try to import my module (called pyccalyon). The first time I try this I get an error message:
我将 pyd 复制到临时文件夹并从该位置运行 Python.exe，顺便说一句，我们仍在使用 Python 2.4.4 的 32 位版本，因为我们的库尚未移植到 64 位架构。接下来我尝试导入我的模块（称为 pyccalyon）。第一次尝试此操作时，我收到一条错误消息：
"ImportError: DLL load failed: The specified module could not be found"
Next time I try this the python interpreter crashes out: no stacktrace at all!
下次我尝试这个时，python 解释器崩溃了：根本没有堆栈跟踪！
Naturally you are suspecting my PYD - the odd thing about this is that it's already in use on thousands of PCs and 10s of other servers, many of which are identical spec'd 64 bit machines. The project is continuously tested both in development and after release, so if this thing were so tinder-box unstable we'd have known about it a very long time ago. This component is considered to be stable code so it's surprising that it's breaking so spectacularly.
自然你会怀疑我的 PYD - 奇怪的是它已经在数千台 PC 和 10 台其他服务器上使用，其中许多是相同规格的 64 位机器。该项目在开发过程中和发布后都经过持续测试，所以如果这个东西如此不稳定，我们很久以前就知道了。这个组件被认为是稳定的代码，所以它的破坏如此惊人令人惊讶。
Any suggestions to what I can do to debug this troublesome library? Crazy ideas welcome at this point because we've exhausted all the sensible ones.
对我可以做些什么来调试这个麻烦的库有什么建议吗？在这一点上欢迎疯狂的想法，因为我们已经用尽了所有明智的想法。
Thanks!
谢谢！
Update 0: Okay using Process monitor I was able to compare one 64bit server that fails with another that works just fine. I found that the breakage seems to occur due to a missing DLL, SysWOW64/mscoreee.dll - any idea what this component is and where I can get it? I can refer this back to our IT provisioning people who can install stuff.
更新 0：好的，使用进程监视器，我能够将一个失败的 64 位服务器与另一个运行良好的服务器进行比较。我发现损坏似乎是由于缺少 DLL SysWOW64/mscoreee.dll 造成的 - 知道这个组件是什么以及我可以从哪里得到它吗？我可以将这个反馈给我们的 IT 供应人员，他们可以安装东西。
采纳答案by babbageclunk
You could try something like Process Monitor, to watch what DLLs it tries to load. I'd assume that one of the other DLLs it relies on can't be found.
您可以尝试使用Process Monitor 之类的方法，以查看它尝试加载的 DLL。我假设无法找到它所依赖的其他 DLL 之一。
Edit: It looks like you've already managed to get some useful info out of it, but I'll clarify how you could reduce the deluge of information that procmon produces.
编辑：看起来您已经设法从中获取了一些有用的信息，但我将阐明如何减少 procmon 产生的大量信息。
Use the filter function to specify the command line (in this case, require that the command line contains python). This will show you messages only from the process you're interested in. Then you can filter out all success results, so you can see which DLL it's looking for.
使用过滤器函数指定命令行（在这种情况下，要求命令行包含python）。这将仅向您显示来自您感兴趣的进程的消息。然后您可以过滤掉所有成功结果，这样您就可以看到它正在寻找哪个 DLL。
Obviously there are lots of other things you can filter on, but this is how I've got results in the past. It's a really handy tool for working out what's going on in situations like this.
显然还有很多其他的东西你可以过滤，但这就是我过去得到结果的方式。这是一个非常方便的工具，用于计算在这种情况下发生的情况。
(Tools like depends or DependencyWalker are also good for finding out what DLLs a library relies on - they give the static information while procmon will show you the dynamic view. Both of them can be useful.)
（诸如depends 或DependencyWalker 之类的工具也有助于找出库所依赖的DLL - 它们提供静态信息，而procmon 将向您显示动态视图。它们都很有用。）
回答by vartec
Have you tried checking which DLLs that PYD links? You can do that for example with either with Dependency Walkeror VS's depends.exe.
您是否尝试过检查 PYD 链接哪些 DLL？例如，您可以使用Dependency Walker或 VS 的 depends.exe来做到这一点。
回答by Powerlord
According to Microsoft's Knowledgebase, mscoree.dll is part of the .NET Framework. To be exact, it's the Microsoft .NET Runtime Execution Engine.
根据Microsoft 的知识库，mscoree.dll 是 .NET Framework 的一部分。准确地说，它是 Microsoft .NET 运行时执行引擎。
The way to get it would be to (re)install the .NET Framework.
获得它的方法是（重新）安装 .NET Framework。
回答by sth
Maybe you're missing the C++ runtime/standard-library DLLs on the machines where it doesn't work, and the module is trying to use them?
也许您在无法运行的机器上缺少 C++ 运行时/标准库 DLL，而模块正试图使用它们？
回答by lama12345
Just had the same problem and depends.exe showed me that foo.pydwas build with python25.libinstead of python27.lib. So it couldn't find python25.dll.
刚刚遇到了同样的问题，depends.exe 向我展示了它foo.pyd是用python25.lib而不是python27.lib. 所以找不到python25.dll。
