Ошибка приложения в режиме выпуска - PullRequest
Новая
       31

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

1 голос
/ 27 февраля 2009

У меня проблема с моим приложением 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.

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

UPDATE: Смена режима отладки производится в web.config

Ответы [ 7 ]

8 голосов
/ 03 марта 2009

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

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

Если эта самая простая страница снова не работает, я предлагаю именно то, что @JSC упомянуло в комментариях: перерегистрируйте 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 дней плюс две "перезагрузки"). После установки чистой ОС на виртуальной машине попробуйте развернуть приложение и посмотреть, как оно ведет себя в этой среде.

3 голосов
/ 27 февраля 2009

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

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

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

[Conditional("Debug")]
3 голосов
/ 27 февраля 2009

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

Утверждай (doSomeCrucialOperation ());

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

1 голос
/ 06 марта 2009

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

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

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

0 голосов
/ 07 марта 2009

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

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

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

0 голосов
/ 06 марта 2009

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

Подробнее см. " Отладка приложений в производственной среде "

0 голосов
/ 27 февраля 2009

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

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

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

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

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

...