Приложение ASP.NET 2.0 работает на Win 2003 в режиме изоляции IIS 5, но не в режиме (по умолчанию) IIS 6 - PullRequest
0 голосов
/ 30 сентября 2008

Приложение использует DLLImport для вызова устаревшей неуправляемой библиотеки DLL. Давайте назовем эту dll Unmanaged.dll ради этого вопроса. Unmanaged.dll имеет зависимости от 5 других устаревших DLL. Все устаревшие библиотеки DLL находятся в каталоге WebApp / bin / моего приложения ASP.NET.

Когда 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

Обновление:

Вернуться со стопкой, взятой из мини-дампа. Кажется, переполнение стека, но я хотел бы знать больше, если кто-то может мне помочь. Результаты "kb" в WinDbg с загруженным sos.dll:

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  

Ответы [ 4 ]

1 голос
/ 16 октября 2008

Решение: Создайте новый поток для запуска импортированной библиотеки DLL, выделите больше памяти для его стека.

0 голосов
/ 22 марта 2010

Я думаю, что потенциальная проблема, которую следует искать здесь, заключается в том, что ваша DLL может быть выгружена во время выполнения между вызовами InitME и ProcessString - поэтому, если ProcessString зависит от вызова InitME в первую очередь, он может перейти в "бум".

Решением этой проблемы было бы использование старых добрых LoadLibrary и FreeLibrary, чтобы заставить среду выполнения поддерживать загрузку библиотеки между вызовами этих двух функций. GetProcAddress не нужен (насколько я могу судить).

0 голосов
/ 30 сентября 2008

Я запустил procmon, debugdiag, пытался работать с инструментами отладки Microsoft. Каждый раз, когда происходит сбой приложения, доктор Ватсон создает пару файлов - .dmp и .tmp (которые я пытался отладить безуспешно).

Вот ошибка из журнала событий:

Тип события: ошибка
Источник события: отчеты об ошибках .NET Runtime 2.0
Категория события: нет
Код события: 1000
Дата: 30.09.2008
Время: 16: 13: 38
Пользователь: не применимо
Компьютер: APPLICATIONTEST010
Описание:
Неисправное приложение w3wp.exe, версия 6.0.3790.3959, штамп 45d6968e, неисправный модуль Unmanaged1.dll, версия 0.0.0.0, штамп 48b6bfb8, отладка? 0, адрес ошибки 0x00122264.

0 голосов
/ 30 сентября 2008

Что за ошибка выдана? если приложение действительно потерпело крах, вам, возможно, придется войти в журнал событий Windows, чтобы получить трассировку стека ошибки.

...