我的python项目有一个C ++组件，它被编译并作为一个.pyd文件分发到一个Python的蛋中。 我注意到，它似乎只与我们的一些全新的64位Windows服务器不兼容。 我们有4（据称）相同的供应机器 – 他们每个人都运行Windows 2003服务器64位版本，但其中2台机器不允许我调用函数。
经过一些实验后，我find了一个可重现错误的配方。 当Python尝试导入pyd文件时，问题似乎就会发生。
我将pyd复制到一个临时文件夹，然后从那个位置运行Python.exe，顺便说一句，我们仍然使用Python 2.4.4的32位版本，因为我们的库没有被移植到64位体系结构。 接下来我尝试导入我的模块（称为pyccalyon）。 我第一次尝试这个，我得到一个错误消息：
"ImportError: DLL load failed: The specified module could not be found" 下次我尝试这个python解释器崩溃了：根本没有stacktrace！
当然，你怀疑我的PYD – 奇怪的是，它已经在数以千计的个人电脑和其他服务器，其中许多是相同规格的64位机器使用。 这个项目在开发和发布后都经过了不断的testing，所以如果这个东西是不稳定的，我们早就知道了。 这个组件被认为是稳定的代码，所以令人惊讶的是，它的突破如此壮观。
任何build议，我可以做什么来debugging这个麻烦的图书馆？ 疯狂的想法在这一点上是受欢迎的，因为我们已经用尽了所有的明智的想法。
谢谢！
更新0 ：好的使用进程监视器我能比较一个失败的64位服务器与另一个工作正常。 我发现破损似乎是由于缺lessDLL，SysWOW64 / mscoreee.dll – 任何想法这个组件是什么，我可以得到它？ 我可以把这个提交给我们的IT供应人员谁可以安装的东西。
你可以尝试像Process Monitor这样的东西来观察它试图加载的DLL。 我会假设找不到它依赖的其他DLL之一。
编辑：看起来你已经设法得到一些有用的信息，但我会澄清你如何可以减少procmon产生的信息泛滥。
使用过滤器函数来指定命令行（在这种情况下，要求命令行包含python）。 这将只显示你感兴趣的进程的消息，然后你可以过滤掉所有的成功结果，所以你可以看到它正在寻找哪个DLL。
显然还有很多其他的东西可以过滤，但这是我过去的成果。 这是一个非常方便的工具来处理这种情况下发生的事情。
（像依赖或DependencyWalker这样的工具也可以很好地找出一个库依赖的DLL – 它们给出了静态信息，而procmon会向你显示动态视图，它们都可以是有用的）。
你有没有尝试检查PYD链接哪些DLL？ 例如你可以用Dependency Walker或者VS的depend.exe来完成这个任务。
根据微软的知识库 ，mscoree.dll是.NET框架的一部分。 确切地说，它是Microsoft .NET运行时执行引擎。
获取它的方法是（重新）安装.NET Framework。
也许你错过了机器上的C ++运行时/标准库DLL，它不工作，模块正在尝试使用它们？
只是有同样的问题，并且foo.pyd向我显示， foo.pyd是用foo.pyd而不是foo.pyd构建的。 所以它找不到python25.dll 。