ASP.NET 2.0應用程序以IIS 5隔離模式在Win 2003上運行，但未以（默認）IIS 6模式運行

Question

該應用程序使用DL​​LImport來調用舊版非托管dll。 為了這個問題，我們將此dll稱為Unmanaged.dll。 Unmanaged.dll依賴於其他5個舊dll。 所有舊版dll都放在我的ASP.NET應用程序的WebApp / bin /目錄中。

當IIS在5.0隔離模式下運行時，該應用程序可以正常工作-對舊版dll的調用將得到處理，而不會出現錯誤。

當IIS在默認的6.0模式下運行時，該應用程序能夠啟動Unmanaged.dll（InitMe（）），但在以后對其進行調用（ProcessString（））時死亡。

我在這里拔頭發。 我已經將非托管dll移到了各個位置，嘗試了各種安全設置，並竭盡全力地尋找解決方案。 救命！

樣例代碼：

[DllImport("Unmanaged.dll", EntryPoint="initME", CharSet=System.Runtime.InteropServices.CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)]
    internal static extern int InitME();
//Calls to InitMe work fine - Unmanaged.dll initiates and writes some entries in a dedicated log file
[DllImport("Unmanaged.dll", EntryPoint="processString", CharSet=System.Runtime.InteropServices.CharSet.Ansi, CallingConvention=CallingConvention.Cdecl)]
    internal static extern int ProcessString(string inStream, int inLen, StringBuilder outStream, ref int outLen, int maxLen);
//Calls to ProcessString cause the app to crash, without leaving much of a trace that I can find so far

更新：

返回堆棧，取自小型轉儲。 似乎是堆棧溢出，但是我想知道是否有人可以幫助我。 加載了sos.dll的WinDbg中的“ kb”結果：

1beb51fc 7c947cfb 7c82202c 00000002 1beb524c ntdll!KiFastSystemCallRet  
1beb5200 7c82202c 00000002 1beb524c 00000001 ntdll!NtWaitForMultipleObjects+0xc  
WARNING: Stack unwind information not available. Following frames may be wrong.  
1beb52a8 7c822fbe 00000002 1beb52ec 00000000 kernel32!WaitForMultipleObjectsEx+0xd2  
1beb52c4 7a2e1468 00000002 1beb52ec 00000000 kernel32!WaitForMultipleObjects+0x18  
1beb5308 7a2d00c4 7a0c3077 1bc4ffd8 1bc4ffd8 mscorwks!CreateHistoryReader+0x19e9d  
1beb531c 7a0c312f 7a0c3077 1bc4ffd8 888d9fd9 mscorwks!CreateHistoryReader+0x8af9  
1beb5350 7a106b2d 1b2733a0 00000001 1b2733a0 mscorwks!GetCompileInfo+0x345ed  
1beb5378 7a105b91 1b272ff8 1b2733a0 00000001 mscorwks!GetAddrOfContractShutoffFlag+0x93a8  
1beb53e0 7a105d46 1beb5388 1b272ff8 1beb5520 mscorwks!GetAddrOfContractShutoffFlag+0x840c  
1beb5404 79fe29c5 00000001 00000000 00000000 mscorwks!GetAddrOfContractShutoffFlag+0x85c1  
1beb5420 7c948752 1beb5504 1beef9b8 1beb5520 mscorwks!NGenCreateNGenWorker+0x4d52  
1beb5444 7c948723 1beb5504 1beef9b8 1beb5520 ntdll!ExecuteHandler2+0x26  
1beb54ec 7c94855e 1beb1000 1beb5520 1beb5504 ntdll!ExecuteHandler+0x24  
1beb54ec 1c9f2264 1beb1000 1beb5520 1beb5504 ntdll!KiUserExceptionDispatcher+0xe  
1beb57f4 1c92992d 1beb6e28 1db84d70 1db90e28 Unmanaged1!UMgetMaxSmth+0x1200ad  
1beb5860 1c929cfe 00000000 1db84d70 1beb6e28 Unmanaged1!UMgetMaxSmth+0x57776  
1beb58c0 1c930b04 00000000 1db84d70 1beb6e28 Unmanaged1!UMgetMaxSmth+0x57b47  
1beb5924 1c99d088 00000000 1db84d70 1beb6e28 Unmanaged1!UMgetMaxSmth+0x5e94d  
1beb5990 1c99c955 00000000 1beb6e28 1beb6590 Unmanaged1!UMgetMaxSmth+0xcaed1  
1beb5a44 1c99e9ae 00000000 40977000 1db90e28 Unmanaged1!UMgetMaxSmth+0xca79e  

Answer 1

解決方案：創建一個新線程以在其中運行導入的dll，並為其堆棧分配更多的內存。

Answer 2

給出什么錯誤？ 如果應用程序確實崩潰了，則可能必須進入Windows事件日志以獲取錯誤的堆棧跟蹤。

Answer 3

我已經運行了procmon，debugdiag，並嘗試使用Microsoft調試工具。 每次應用程序崩潰時，Watson博士都會創建一對文件-.dmp和.tmp（我曾嘗試對其進行調試，但未成功）。

這是事件日志中的錯誤：

事件類型：錯誤
事件源：.NET Runtime 2.0錯誤報告
事件類別：無
場次編碼：1000
日期：2008年9月30日
時間：16：13：38
用戶：不適用
計算機：APPLICATIONTEST010
描述：
錯誤的應用程序w3wp.exe，版本6.0.3790.3959，戳45d6968e，錯誤的模塊Unmanaged1.dll，版本0.0.0.0，戳48b6bfb8，調試嗎？ 0，故障地址0x00122264。

Answer 4

我認為這里要尋找的潛在問題是您的DLL可能會在調用InitME和ProcessString之間由運行時卸載-因此，如果ProcessString依賴於首先被調用的InitME，它可能會“繁榮”。

解決方案是使用良好的舊LoadLibrary和FreeLibrary強制運行時，以在調用這兩個函數之間保持庫加載。 不需要GetProcAddress（據我所知）。