StackOverflowException в .Net Windows Service

Question

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

есть ли вообще способ, которым служба Windows может обнаружить, что такое исключение произошло?

В документации по этому исключению MSDN говорит: «Обратите внимание, что приложение, в котором размещается общеязыковая среда выполнения (CLR), может указать, что CLR выгружает домен приложения, в котором происходит исключение переполнения стека, и позволяет соответствующему процессу продолжаться». это то, что я ожидаю от реализации службы Windows, но это не так.

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

Answer 1

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

Ну, вы уже все это знаете. Но, игнорируя это и притворяясь, что этого не произошло, мы видим другой провал. Системный сбой, служба должна была что-то делать, а этого не произошло. Существует не так много сценариев, где это приемлемо. Файл не был обработан, обновление базы данных не произошло, и так далее. Вид неудачи, который может вызвать цепочку неудач позже. Например, финансовый директор обнаружил, что в конце года не хватает миллиона долларов.

Вы не хотели слышать это, но нет разумного способа справиться с этим. Сосредоточьте все свои усилия на поиске жучка, а не лейкопластыря. А переполнение стека всегда программная ошибка.

Answer 2

Хорошо, практический ответ.Вы не застряли с фиксированным размером стека.Вы можете использовать конструктор Thread (ThreadStart, int), чтобы создать его с большим стеком.Дайте ему пару десятков мегабайт.Это должно в значительной степени избежать проблемы, если не решить ее полностью.

Следующее, что нужно сделать, - это начать проверку файла XML, который вам дается обработать.Не уверен, что это необработанный размер файла, который может вызвать SO или плохие данные в .xml.Начните с проверки размера файла и поместите его в отдельный каталог, если он монстр.Обрабатывается вручную, желательно тем, кто создал этот файл.И убедитесь, что у вас есть несколько проблемных файлов, если у вас их еще нет.Попробуйте обработать их в автономном режиме с размером стека монстров.Если это все еще идет, начните искать алгоритм, который может предварительно просмотреть содержимое .xml, чтобы определить источник проблемы.

Задайте другой вопрос, если вы считаете, что причиной может быть содержание файла .xml, ивам нужно выяснить, какой плохой контент может вызвать это (не знаю ничего о xlt).