Отладка: процесс w3wp.exe был прерван из-за (работает на одной машине, но не на другом)
Проблема
У меня есть приложение ASP.NET 4.0, сбой с переполнением стека на одном компьютере, но не другое. Он отлично работает в моей среде разработки. Когда я перемещаю сайт на рабочий сервер, он выдает исключение (отображается в журнале событий), и рабочий процесс w3wp.exe умирает и заменяется другим.
Что я пробовал до сих пор
Для справки я использовал диагностический инструмент отладки, чтобы попытаться определить, какой фрагмент кода вызывает переполнение, но я не уверен, как интерпретировать его вывод. Вывод представлен ниже.
Как веб-сайт ASP.NET может вызвать переполнение стека на одном компьютере, но не на другое?
Оценены опытные руководители. Я опубликую полученное решение ниже ответа, который приведет меня к этому.
Отладочный вывод
Приложение: w3wp.exe Framework Версия: v4.0.30319 Описание: Процесс был прерван из-за.
In w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp the assembly instruction at nlssorting!SortGetSortKey+25 in C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll from Microsoft Corporation has caused a Qaru exception (0xC00000FD) when trying to write to memory location 0x01d12fc0 on thread 16
Please follow up with the vendor Microsoft Corporation for C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll
Information:DebugDiag determined that this dump file (w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the IISAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True.
Entry point clr!ThreadpoolMgr::intermediateThreadProc
Create time 2/18/2011 9:07:10 PM
Function Arg 1 Arg 2 Arg 3 Source
nlssorting!SortGetSortKey+25 01115a98 00000001 0651a88c
clr!SortVersioning::SortDllGetSortKey+3b 01115a98 08000001 0651a88c
clr!COMNlsInfo::InternalGetGlobalizedHashCode+f0 01115a98 05e90268 0651a88c
mscorlib_ni+2becff 08000001 0000000f 0651a884
mscorlib_ni+255c10 00000001 09ed57bc 01d14348
mscorlib_ni+255bc4 79b29e90 01d14350 79b39ab0
mscorlib_ni+2a9eb8 01d14364 79b39a53 000dbb78
mscorlib_ni+2b9ab0 000dbb78 09ed57bc 01ff39f4
mscorlib_ni+2b9a53 01d14398 01d1439c 00000011
mscorlib_ni+2b9948 0651a884 01d143ec 7a97bf5d
System_ni+15bd65 6785b114 00000000 09ed5748
System_ni+15bf5d 1c5ab292 1b3c01dc 05ebc494
System_Web_ni+6fb165
***These lines below are repeated many times in the log, so I just posted one block of them
1c5a928c 00000000 0627e880 000192ba
1c5a9dce 00000000 0627e7c4 00000000
1c5a93ce 1b3c01dc 05ebc494 1b3c01dc
1c5a92e2
.....(repeated sequence from above)
System_Web_ni+16779c 1b338528 00000003 0629b7a0
System_Web_ni+1677fb 00000000 00000017 0629ac3c
System_Web_ni+167843 00000000 00000003 0629ab78
System_Web_ni+167843 00000000 00000005 0629963c
System_Web_ni+167843 00000000 00000001 0627e290
System_Web_ni+167843 00000000 0627e290 1a813508
System_Web_ni+167843 01d4f21c 79141c49 79141c5c
System_Web_ni+1651c0 00000001 0627e290 00000000
System_Web_ni+16478d 00000001 01ea7730 01ea76dc
System_Web_ni+1646af 0627e290 01d4f4c0 672c43f2
System_Web_ni+164646 00000000 06273aa8 0627e290
System_Web_ni+1643f2 672d1b65 06273aa8 00000000
1c5a41b5 00000000 01d4f520 06273aa8
System_Web_ni+18610c 01d4f55c 0df2a42c 06273f14
System_Web_ni+19c0fe 01d4fa08 0df2a42c 06273e5c
System_Web_ni+152ccd 06273aa8 05e9f214 06273aa8
System_Web_ni+19a8e2 05e973b4 062736cc 01d4f65c
System_Web_ni+19a62d 06a21c6c 79145d80 01d4f7fc
System_Web_ni+199c2d 00000002 672695e8 00000000
System_Web_ni+7b65cc 01d4fa28 00000002 01c52c0c
clr!COMToCLRDispatchHelper+28 679165b0 672695e8 09ee2038
clr!BaseWrapper<Stub *,FunctionBase<Stub *,&DoNothing<Stub *>,&StubRelease<Stub>,2>,0,&CompareDefault<Stub *>,2>::~BaseWrapper<Stub *,FunctionBase<Stub *,&DoNothing<Stub *>,&StubRelease<Stub>,2>,0,&CompareDefault<Stub *>,2>+fa 672695e8 09ee2038 00000001
clr!COMToCLRWorkerBody+b4 000dbb78 01d4f9f8 1a78ffe0
clr!COMToCLRWorkerDebuggerWrapper+34 000dbb78 01d4f9f8 1a78ffe0
clr!COMToCLRWorker+614 000dbb78 01d4f9f8 06a21c6c
1dda1aa 00000001 01b6c7a8 00000000
webengine4!HttpCompletion::ProcessRequestInManagedCode+1cd 01b6c7a8 69f1aa72 01d4fd6c
webengine4!HttpCompletion::ProcessCompletion+4a 01b6c7a8 00000000 00000000
webengine4!CorThreadPoolWorkitemCallback+1c 01b6c7a8 0636a718 0000ffff
clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+195 01d4fe1f 01d4fe1e 0636a488
clr!ThreadpoolMgr::NewWorkerThreadStart+20b 00000000 0636a430 00000000
clr!ThreadpoolMgr::WorkerThreadStart+3d1 00000000 00000000 00000000
clr!ThreadpoolMgr::intermediateThreadProc+4b 000c3470 00000000 00000000
kernel32!BaseThreadStart+34 792b0b2b 000c3470 00000000
NLSSORTING!SORTGETSORTKEY+25In w3wp__PID__5112__Date__02_18_2011__Time_09_07_31PM__671__First Chance Stack Overflow.dmp the assembly instruction at nlssorting!SortGetSortKey+25 in C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\nlssorting.dll from Microsoft Corporation has caused a Qaru exception (0xC00000FD) when trying to write to memory location 0x01d12fc0 on thread 16
Ответы
Ответ 1
Этот вопрос немного устарел, но я просто нашел хороший способ получить трассировку стека моего приложения перед переполнением, и я хотел бы поделиться им с другими googlers:
1) При сбое приложения ASP.NET набор файлов debbuging сбрасывается в "папку сбоя" внутри этой основной папки:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue
2) Эти файлы можно проанализировать с помощью WinDbg, которые вы можете загрузить с одной из приведенных ниже ссылок:
3) После установки на том же компьютере, где ваше приложение разбилось, нажмите Файл > Открыть аварийный дамп и выберите самый большой .tmp файл в вашей "папке сбоев", (у меня было 180 МБ). Что-то вроде:
AppCrash_w3wp.exe_3d6ded0d29abf2144c567e08f6b23316ff3a7_cab_849897b9\WER688D.tmp
4) Затем запустите следующие команды в открывшемся окне команд:
.loadby sos clr
!clrstack
5) Наконец, сгенерированный вывод будет содержать трассировку стека приложений непосредственно перед переполнением, и вы можете легко отследить, что вызвало переполнение. В моем случае это был метод баггинга:
000000dea63aed30 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
000000dea63aedd0 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
000000dea63aee70 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
000000dea63aef10 000007fd88dea0c3 Library.Logging.ExceptionInfo..ctor(System.Exception)
000000dea63aefb0 000007fd88de9d00 Library.Logging.RepositoryLogger.Error(System.Object, System.Exception)
000000dea63af040 000007fd88de9ba0 Library.WebServices.ErrorLogger.ProvideFault(System.Exception, System.ServiceModel.Channels.MessageVersion, System.ServiceModel.Channels.Message ByRef)
Спасибо Paul White и его сообщение в блоге: Отладка Faulting Application w3wp.exe Сбой
Ответ 2
Предел стека по умолчанию для w3wp.exe - это шутка. Я всегда поднимаю его с помощью editbin /stack:9000000 w3wp.exe, этого должно быть достаточно. Сначала избавитесь от, а затем отлаживайте все, что захотите.
Ответ 3
Получите аварийный дамп, запустите его с Microsoft Отладочный диагностический инструмент и покажите нам результат.
Также посмотрите http://support.microsoft.com/kb/919789/en-us, в котором подробно описаны все необходимые шаги.
Ответ 4
Две вещи, которые я постарался бы перед анализом любых дампов памяти.
- Установите средство удаленной отладки на веб-сервере и попробуйте отладить этот путь. Этот инструмент можно найти на установочном DVD-диске Visual Studio.
- Установите Элму. Elmah можно добавить в запущенное приложение ASP.NET для ведения журнала и отладки. Вероятно, я сначала поеду с этим вариантом, и это будет наименее болезненный подход. http://code.google.com/p/elmah/
Ответ 5
Одной из возможностей для вашего приложения, которое ведет себя по-разному в производстве или разработке, может быть то, что в коде есть директивы препроцессора, такие как "#if DEBUG", а при развертывании на производство сборка релизов будет иметь разные сегменты кода, чем ваша сборка отладки.
Другим вариантом будет то, что ваше приложение бросает несвязанное исключение в производство. И код обработки ошибок каким-то образом заканчивается бесконечным циклом вызова функции. Вы можете искать бесконечный цикл, который имеет вызов функции для себя или другую функцию, которая вызывает эту функцию. Это заканчивается бесконечной функцией цикла callig из-за бесконечного цикла for или while. Я прошу прощения за то, что перешел за борт со словом "бесконечный".
Это также случилось со мной раньше, когда я случайно создал свойство, и я возвращаю свойство внутри своей собственности. Как: -
Открытая строка SomeProperty {get {return SomeProperty;}
Кроме того, если возможно, вы можете делать специальные вещи с исключением в функции Application_error вашего global.asax. Используйте server.getlasterror() для получения исключения и регистрации/отображения stacktrace. Возможно, вы захотите сделать то же самое для любых innerexceptions или innerexceptions innerexceptions и так далее.
Возможно, вы уже делали вышеупомянутые вещи, но я хотел упомянуть их на всякий случай.
Кроме того, из вашей трассы, похоже, что ошибка происходит в GetSortKey. Это функция в вашем коде? Если это так, тогда может начаться ваше бесконечное самосознание.
Надеюсь, это поможет.
