Вопрос

Вчера вечером я развернул веб-приложение ASP.NET, а когда проснулся сегодня утром, оно работало очень медленно и иногда просто выдавало ошибку «Служба недоступна».

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

Произошло необработанное исключение, и процесс был завершен.

Исключение:System.Runtime.Serialization.SerializationException

Сообщение:Невозможно найти сборку «MonoTorrent, версия = 0.80.0.0, культура = нейтральная, PublicKeyToken = null».

Я озадачен тем, что он работал отлично, когда я его развернул (MonoTorrent необходим для получения количества раздающих/личеров для определенного торрента с трекера - это работало нормально), но он больше не работает, и всякий раз, когда код, использующий MonoTorrent вмешивается, рабочий процесс просто аварийно завершает работу.

MonoTorrent.dll находится в каталоге /bin/.


ОБНОВЛЕНИЕ 04.06.10: Я скомпилировал исходный код MonoTorrent вместе с остальной частью моего веб-приложения, но оно все равно вылетает всякий раз, когда использует MonoTorrent.Однако сейчас говорится, что это Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.Здесь OpenPeer — это имя сборки веб-приложения.

Нет правильного решения

Другие советы

Это может произойти в следующих случаях:

Приложение ASP.NET создает фоновый поток, который выдает неперехваченное исключение.Похоже, что ASP.NET перехватывает исключение и хочет зарегистрировать его в журнале событий.Для этого он отправляет это исключение из домена приложения веб-приложения в свой собственный домен приложения (по умолчанию для процесса w3wp).Для этого требуется сериализация/десериализация исключения.

Если исключение является пользовательским (т.определенное веб-приложением), его нельзя десериализовать в основном домене приложения ASP.NET, поскольку сборка, определяющая исключение, обычно находится в каталоге bin веб-приложения, а не там, где находится w3wp.exe (c:\windows\system32\inetsrv ).Это вызывает исключение сериализации и сбой w3wp.

Существуют возможные способы решения проблемы (в очень субъективном порядке предпочтения):

  1. Скопируйте недостающую DLL в папку c:\windows\system32\inetsrv.
  2. Установите недостающую DLL в GAC.
  3. Устранить причину исключения (сложнее сделать, чем сказать, как мы говорим по-французски)
  4. Перехватывайте все исключения из фонового потока самостоятельно и ведите журналирование самостоятельно.

Примечания:

  • Если используется WCF и неперехваченное исключение — FaultException, WCF проглатывает его и сбоя не происходит.
  • Если неперехваченное исключение находится в потоке веб-запроса, возникает желтый экран смерти, а не это исключение сериализации.
  • Это действительно похоже на ошибку в ASP.NET.
  • На самом деле вышеизложенное представляет собой краткое изложение моих вчерашних исследований по этому вопросу и является лишь теорией.Я протестировал исправления 1 и 4, а также использовал FaultException.

Пытаться очистка временных файлов ASP.NET.Раньше это решало для меня некоторые странные проблемы.

В противном случае, Fusion-регистрация может пролить свет.

ОБНОВЛЯТЬ:@Чарли, я не знаю, что делать с этими журналами... похоже, что неудачный журнал взят из другого домена приложений.Обратите внимание, что для AppBase установлено значение «file:///c:/windows/system32/inetsrv/», а для AppName — w3wp.exe.

Я почти уверен, что средство просмотра событий должно отображать идентификатор приложения:LM/W3SVC/#/ROOT, если это также домен приложения по умолчанию.На данный момент все, что у меня есть, это случайные догадки.

  1. Я заметил, что вы используете x64... возможно, MonoTorrent требуется x86?
  2. Вы дважды проверили, что каталог является приложением IIS и настроен для правильной версии ASP.NET?
  3. Есть ли на этом сервере какое-нибудь другое приложение, использующее MonoTorrent?Может быть, служба WCF или что-то в этом роде?Я не уверен, где происходит сериализация....
  4. Попробуйте подключить Событие AssemblyResolve и загружаем его вручную.
  5. Можете ли вы воспроизвести на машине разработки?Если нет, возможно, это неправильная установка FX.Удалите и переустановите.
  6. Перезапуск, перезапуск или остановка/запуск AppPool временно устраняют проблему или приводят к ее появлению?

Возможно, вы также захотите напечатать текст своего скриншота, чтобы получить немного любви от Google....

Вот некоторые вещи, которые вы можете попробовать..

1.) Очистить каталог Temp ASP.Net. Перезапустите IIS и переработать пул приложений.

2.) Убедитесь, что ваше веб-приложение запущено. ПОЛНОЕ ДОВЕРИЕ если ему действительно нужно ПОЛНОЕ ДОВЕРИЕ.

3.) Возьмите сборку, попробуйте использовать ее в другом приложении asp.net и запустите тестовое приложение на отдельном сервере.Это может помочь вам диагностировать проблему.Также попробуйте запустить тестовое приложение asp.net на том же сервере, но в отдельном пуле приложений.

4.) Убедитесь, что Веб-сайт IIS вашего приложения работает под учетной записью пользователя с необходимыми правами безопасности..Попробуйте запустить приложение под учетной записью Администратора.

РЕДАКТИРОВАТЬ-1

5.) Также проверьте, совпадает ли версия сборки с указанной в web.config.Если есть несоответствие версий, вы можете сделать Перенаправление привязки сборки в веб.конфигурации.

6.) Также попробуйте зарегистрировать сборку в GAC и посмотреть, правильно ли она загружается.

РЕДАКТИРОВАНИЕ-2

7.) Попробуйте перенастроить поддержку ASP.NET на сервере или, возможно, поможет перенастройка среды выполнения платформы.Возможно, это ненадежное решение, но, учитывая состояние проблемы, мы можем попробовать различные решения.

8.) Убедитесь, что вы ничего не пропустили. критическое обновление вашего сервера Windows Платформа.

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

Прежде всего, я внимательно просматриваю MonoTorrent.dll до того, как вы зададите свой вопрос, и сегодня снова просматриваю его.Я нашел и функцию, загружающую dll.Мое первое мнение: что-то связано с разрешениями.

Я надеюсь, что у вас есть доступ к серверу, верно?

Мои первые шаги заключаются в следующем:

Убедитесь, что ваш monotorrent.dll действительно имеет правильные разрешения для каталога bin., для чтения и выполнения вашим приложением asp.net.Иногда копия одной dll не получала разрешений для каталога, но использовала свои собственные разрешения.Чтобы проверить, есть ли у вашего DLL разные разрешения от остальных, просто щелкните правой кнопкой мыши и посмотрите свойства | Безопасность, затем перейдите в Bin Directory и сделайте то же самое, и сравните разрешения на безопасность.Если они разные, снова примените разрешения каталога и убедитесь, что dll унаследована каталогом.

Мой второй шаг

Загрузите ProcessMonitor с сайта sysinternals.

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Запустите ProcessMonitor и попробуйте воссоздать ошибку., остановите его и проанализируйте, чтобы увидеть, где и почему dll получает запрещенные разрешения на запуск.С помощью ProcessMonitor вы даже можете увидеть, есть ли какие-либо библиотеки, которые не удалось найти!

Я проверил библиотеки MonoTorrent и не нашел ничего необычного.У него есть вызовы kerner32.dll, и он использует небезопасный код для запуска, ничего особенного.

Итак, если вы сделаете эти два шага и дадите мне отзыв, возможно, я смогу пойти дальше.(если не решите вы и что найдете)

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

  1. Удалить все временные файлы
  2. Удалите все временные файлы ASP.NET IIS.
  3. Перезапустить сервер

Проблема в том, что веб-приложения ASP.NET приводят к тому, что на диске остается много временных файлов, из-за динамической компиляции регулярных выражений, сборок сериализации и т. д. такие временные файлы никогда не удаляются, и во временных местах начинает собираться все больше и больше мусора. ASP.NET работает все медленнее и медленнее, и наступает момент, когда дефрагментация диска и памяти достигает очень высокой точки, и все начинает давать сбой.

Никто не любит перезапускать сервер раз в неделю, но я помню, что у нас не было выбора: в ASP.NET 1.1 у нас была стабильная система после перезагрузки каждый день, в ASP.NET 2.0 и более поздних версиях хорошо, если перезагрузка запланирована раз в неделю. .

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

Этот метод мне подходит.

Часовой пояс сервера отличается от вашего часового пояса?У меня возникла эта проблема при развертывании файлов ресурсов: время компиляции было в будущем, поэтому они не загружались.

Я предполагаю, что у вас много открытых, но не закрытых соединений.Я имею в виду, что соединения не возвращаются в пул.Когда вы запускаете приложение, все выглядит нормально, но через некоторое время в пуле доступно только несколько сокетов, и оно работает медленно.Другое дело - незакрытое соединение может удерживать DLL в памяти, не позволяя освободить обработчик.Попробуйте отладить уничтожение объекта.

Я знаю, что это просто, но однажды у меня возникла эта проблема, потому что у меня был проект веб-приложения, который содержит

    References

Папка и я только что скопировали файлы в

    Bin

папку в любом веб-приложении .net в Окна свойств проекта, а Вкладка «Путь к ссылке» доступен, и по умолчанию в него ничего не должно быть включено.проверьте эту опцию, а также Вкладка «Сборка» в Окно свойств проекта который Выходной путь быть таким же, как мусорное ведро\

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top