Сбой приложения в режиме выпуска

У меня проблема с моим приложением ASP.NET. Он разрабатывался около года без отключения режима отладки. Я хотел проверить, работает ли он без отладки, но это не так, но когда я устанавливаю debug = "true", он работает нормально.

Когда я пытаюсь открыть приложение в первый раз, я получаю ошибку «Сервер недоступен». В журнале событий две ошибки:

  1. Ошибка .NET Runtime 2.0 - сбойное приложение aspnet_wp.exe, версия 2.0.50727.3082, штамп 492b8702, сбойный модуль kernel32.dll, версия 5.1.2600.3119, штамп 46239c44, отладка? 0, адрес ошибки 0x00012a5b.
  2. ASP.NET 2.0.50727.0 - Неожиданный конец процесса aspnet_wp.exe (PID: 4932) (может быть написано немного иначе, это переведено).

Моя версия IIS - 5.1, работающая в Windows XP.

Буду признателен за любые предложения.

ОБНОВЛЕНИЕ: изменение режима отладки производится в web.config

Ответов (7)

Решение

Сбой, который вы описываете, происходит в kernel32.dll - это может указывать на то, что это сбой не внутри вашего управляемого кода, а скорее в самом ядре .NET (тьфу) - в этом случае такие вещи, как проверка путей к прекомпилятору и т. Д., Будут не дает никаких положительных результатов (ИМХО).

Я бы посоветовал вам попробовать решить эту проблему с помощью «бинарного поиска» (для виновника) :-). В качестве первой «итерации» я бы создал простую aspx-страницу (/Test.aspx), оставил бы режим отладки отключенным и попытался бы перейти на страницу (без кода программной части, просто базовый HTML с заголовком и Hello, world body). Это позволит убедиться, что ASP.NET установлен и правильно работает на вашем сервере IIS.

Если эта простейшая страница снова выйдет из строя, я предлагаю именно то, что @AO упомянул в комментариях: повторно зарегистрируйте ASP.NET в IIS:

rem (reregister ASP.NET in IIS)
rem (run as administrator!)
%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -i

После запуска простейшей страницы я бы добавил простой код программной части, попробуйте это. После запуска кода программной части я бы попытался обновить реальную стартовую страницу вашего приложения, удалив ВСЕ выделенный код, оставив только разметку и попробовав нажать на страницу - да, это будет выглядеть ужасно, но, по крайней мере, может отображаться :-) . Впоследствии я бы попробовал добавить только логику инициализации, посмотрю, как это будет ...

По сути, вам нужно найти любую «вещь» в вашем приложении, которая вызывает сбой. Я предполагаю, что это две крайности: разметка + отсутствие кода = работает, разметка + весь код = сбой; «Подход» бинарного поиска включит половину вашего кода, посмотрите, отображается ли он по-прежнему (сейчас мы не беспокоимся о функциональности - он, конечно, не будет вести себя так, как ожидалось). Если он не отображается, отключите вторую половину первой половины (т.е. будет активна только четверть вашего кода), попробуйте это. Продолжайте, пока не ограничите поиск проблемной областью ...

Еще один подход, который я предлагаю, - установить Server 2003 (IIS6) / Server 2008 (IIS7) на виртуальной машине - VirtualPC, VMWare, VirtualBox (если у вас нет доступа к загрузкам MSDN образов серверов, вы всегда можете загрузить пробные версии - Пробная версия Server 2008 рассчитана на 60 дней плюс два «сброса»). После установки чистой ОС на виртуальную машину попробуйте развернуть приложение и посмотреть, как оно ведет себя в этой среде.

Есть более старый вопрос по аналогичной проблеме:

Программа вылетает только при сборке релиза - как отлаживать?

Это также может помочь:

http://blogs.msdn.com/rahulso/archive/2006/03/02/what-is-a-crash-technically-in-asp-net-and-what-to-do-if-it-happens. aspx

Вы пытались подключиться к процессу с помощью (удаленного) отладчика, даже если он не встроен в режим отладки?

Я предлагаю вам проверить свой код на утверждения, содержащие не отладочный код. Я несколько раз делал частую ошибку при написании кода вроде следующего:

Утвердить (doSomeCrucialOperation ());

при компиляции в режиме выпуска весь Assert с вызовом операции не компилируется.

Убедитесь, что у вас нет условного кода, проверяющего среду отладки. Однажды я потратил дни, пытаясь отследить случайный сбой ... и в конце концов наткнулся на что-то вроде этого:

#ifdef DEBUG
  threadPoolCount = 1;
#else
  threadPoolCount = 16;

Угадайте, что ... это была ошибка потоковой передачи! В C# это будет выглядеть примерно так:

[Conditional("Debug")]

Отладка релиза всегда сложна, потому что единственное, на что вы полагаетесь при отладке проблем, - это именно то, что в первую очередь останавливает ее сбой. Так что вам придется импровизировать и вернуться к списку инструментов, имеющихся в вашем распоряжении.

Немного уменьшите проблему: удалите / отключите фрагмент за фрагментом кода, пока он не перестанет давать сбой, затем повторно включите биты, чтобы он снова сбой, сужая поле проблемы. Разбейте проблему от «он где-то рушится» до «где-то здесь рушится ».

Журнал. Регистрируйте больше, чем обычно. Оптимистично ведите журнал («программа достигла этой точки с X = {0}»). Используя хорошую подсистему ведения журнала, вы всегда можете оставить их и отключить вывод. Затем вы можете проанализировать путь, по которому ваша программа достигла точки отказа, и определить, где может быть проблема.

Контролируйте свой сайт с помощью инструмента DebugDiag и выявляйте все утечки. Не забудьте установить PDB.

Дополнительную информацию см. В разделе « Отладка приложений в производственной среде ».

Попробуйте очистить временные библиотеки DLL

iisreset /stop
del "%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\*.*" /s/f
iisreset /start

Убедитесь, что вы правильно освобождаете неуправляемые ресурсы. Использование USING и .Dispose.