Asp.net сбой в mscorlib

Question

Это связано с another question of mine

После устранения очевидного (или я так думал) и самый большой потребитель памяти (изображения в кэше asp.net), не многое изменилось. Мы используем обработку исключений из Enterprise Library в этой сети (не знаю, почему, но мы это делаем), и эти исключения не регистрируются. Только для записи сервер имеет 4 ГБ памяти, поэтому я не думаю, что проблема с физической памятью.

Вот что происходит, согласно журналу событий:

Во-первых, я получаю это со страницы (редко из одной странице дважды):

Exception information: 
Exception type: Exception 
Exception message: mscorlib - Exception of type 'System.OutOfMemoryException' was thrown. 

Тогда это:

Description: 
An unhandled exception occurred and the process was terminated. 
Application ID: /LM/W3SVC/672222825/Root 
Process ID: 1544 
Exception: System.OutOfMemoryException 
Message: Exception of type 'System.OutOfMemoryException' was thrown. 
StackTrace: at System.Threading.ExecutionContext.CreateCopy() 
    at System.Threading._TimerCallback.PerformTimerCallback(Object state) 

Мой вопрос заключается в следующем: как использовать профилировщик, чтобы узнать, что вызывает крах? Я пробовал два профайлера - профайлер памяти .net и dotTrace из JetBrains. Профилирование памяти действительно не дает мне ничего полезного, за исключением того, что у меня много строк. Профилирование производительности также не помогает, потому что время выполнения функций отлично и денди. Если эта ошибка возникает во время работы профилировщика, она просто прекращает профилирование - возможно, я ошибаюсь.

p.s. Извините за форматирование, сделал все, что мог.

Answer 1

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

Единственное, что озадачивает меня в том, что он должен врезаться так некрасиво, а не бросать YouIdiotYoureOverUsingSessionObjectException :)

Ну хорошо, жить и учиться ...

Answer 2

Я бы установил, что вы вызываете Dispose при реализации IDisposable. Достаточно хороший способ проверить, чтобы запустить код через FXCop.

Answer 3

Атрибут ограничения памяти в разделе ProcessModel в файле machine.config, который управляет максимальным использованием памяти ASP.NET перед повторной обработкой.