msvcr71.dll在Windows Server 2008 w / ASP.NET 4上崩溃了IIS 7应用程序池

时间:2012-08-08 08:53:07

标签: asp.net windows-server-2008 32bit-64bit

我正在开发一个需要使用托管代码包装的C库的项目。 C库编译为32位,我发现它需要msvcr71.dll。问题是,无论出于何种原因,这个DLL都没有在SysWOW64目录中提供Windows Server 2008。

我已经从系统上的SQL Management Studio复制了DLL,我可以验证它是否可以在服务器上的独立EXE中运行。没有什么能阻止它工作。

但是......当我将它链接到我的ASP.NET应用程序并确保我的库的DLL和msvcr71.dll都在我的/bin目录中时,我站点的应用程序池从我的下面掉了出来。 werfault.exe启动,吃掉一堆CPU和RAM,然后消失,在事件查看器中留下这个无用的日志。

然后,应用程序池重新启动并等待再次失败。它在集成模式下运行.NET 4。该网站基于MVC 3。

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f
Exception code: 0xc0000374
Fault offset: 0x000ce6c3
Faulting process id: 0x998
Faulting application start time: 0x01cd753eb1fcd760
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 7b54f020-e132-11e1-a34d-404094d3cf82

这到底是怎么回事?我很乐意将DLL链接到我的ASP.NET站点,但我只是在编写代理应用程序的边缘...我想尽可能避免这种黑客攻击。感谢。

旁注所有这些在我的本地计算机上运行得非常好。只有在服务器上,我才能将它链接到IIS中。

更新

这在IIS内部运行时似乎是一个互操作问题,特别是使用字符串方法...我现在正在研究它......

http://blogs.msdn.com/b/asiatech/archive/2009/12/24/net-application-may-crash-on-windows-2008-when-calling-function-from-native-c-dll.aspx

1 个答案:

答案 0 :(得分:1)

讨厌回答我自己的问题,但需要为其他人记录解决方案。我在这里遇到的核心问题实际上并不是msvcr71.dll(最后我认为我最终会针对C运行时版{10}的版本10重新编译相关库的原始C源,因为它包含在默认情况下为Windows Server 2008。

我仍在针对x86运行库。但是真正的问题是在某些内存管理错误(或者你决定使用的功能)导致IIS 7在使用.NET中的字符串进行P / Invokes上的Interop时崩溃。我认为这是一个安全功能...谁知道。

查看上面问题更新中列出的文章,了解有关此内容的部分详细信息:

http://blogs.msdn.com/b/asiatech/archive/2009/12/24/net-application-may-crash-on-windows-2008-when-calling-function-from-native-c-dll.aspx

我正在使用的特定库是用于GIS工具的Shapefiles,如果你很好奇的话。

http://shapelib.maptools.org/

这对我有意义,但我的库是用C而不是C ++编写的。无论如何,这两种语言都不是我的强项,我找不到C编译器中存在的msvcr100.dll方法。这可能是我自己的错,但我真的没有时间学习和重写一些古老的C代码。

我发现我可以不使用.NET方法编组字符串,而是从CoTaskMemFree手动编写,以防止IIS崩溃。

这是我的原始导入:

IntPtr

......这就是我必须改变的地方:

    [DllImport("shapelib.dll", CharSet = CharSet.Ansi)]
public static extern string DBFReadStringAttribute (IntPtr hDBF, int iShape, int iField);

这种变化本身阻止了应用程序崩溃。然后我不得不创建这种黑客来拉出字符串。我知道这必须远离乐观主义者,但这是我现在能做的最好的事情。

这是我最终做的事情......

    [DllImport("shapelib.dll", CharSet = CharSet.Ansi)]
public static extern IntPtr DBFReadStringAttribute (IntPtr hDBF, int iShape, int iField);

附加说明

无论出于何种原因public static string DBFReadStringAttribute(IntPtr hDBF, int iShape, int iField) { IntPtr dataPtr = _DBFReadStringAttribute(hDBF, iShape, iField); string output = Marshal.PtrToStringAnsi(dataPtr, 255); //255 is the supposed max length for DBF databases int idx = output.IndexOf('\0'); string strData; if (idx > 0) strData = output.Substring(0, idx).Trim(); else strData = ""; return strData; } [DllImport("shapelib.dll", CharSet = CharSet.Ansi, EntryPoint = "DBFReadStringAttribute")] private static extern IntPtr _DBFReadStringAttribute (IntPtr hDBF, int iShape, int iField); 没有正确检索字符串(它会被破坏)。我必须设置一个maxlength并自己解析它。