it-swarm.com.ru

.NET 4.5: внутренняя ошибка в .NET Runtime (80131506)/отключение одновременного сбора данных

У меня есть долго работающее приложение .NET 4.5, которое случайным образом падает, оставляя сообщение, которое я упомянул в заголовке вопроса, в журнале событий. Выпуск воспроизводится на 3 разных машинах и 2 разных системах (2008 R2 и 2012). Приложение не использует небезопасные/неуправляемые компоненты, это чисто управляемый .NET, единственной неуправляемой вещью является сам CLR.

Вот трассировка стека сайта аварии, который я извлек из дампа:

clr.dll!MethodTable::GetCanonicalMethodTable()  
clr.dll!SVR::CFinalize::ScanForFinalization()  - 0x1a31b bytes  
clr.dll!SVR::gc_heap::mark_phase()  + 0x328 bytes   
clr.dll!SVR::gc_heap::gc1()  + 0x95 bytes   
clr.dll!SVR::gc_heap::garbage_collect()  + 0x16e bytes  
clr.dll!SVR::gc_heap::gc_thread_function()  + 0x3e bytes    
clr.dll!SVR::gc_heap::gc_thread_stub()  + 0x77 bytes    
kernel32.dll!BaseThreadInitThunk()  + 0x1a bytes    
ntdll.dll!RtlUserThreadStart()  + 0x21 bytes    

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

  • Я попытался установить this hotfix, но он не будет установлен ни на одном из моих компьютеров (KB2640103 не применяется или заблокирован другим условием на вашем компьютере), что на самом деле имеет смысл, потому что я использую 4.5, а не 4.0.

  • Я пытался отключить одновременный GC и/или включить GC сервера. Прямо сейчас соответствующая часть моего app.config выглядит так:

    <?xml version="1.0"?>
    <configuration>        
        <runtime>
            <gcConcurrent enabled="false"/>
            <gcServer enabled="true" />
        </runtime>
    <startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>    </startup></configuration>
    

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

ntdll.dll!NtWaitForSingleObject()  + 0xa bytes  
KERNELBASE.dll!WaitForSingleObjectEx()  + 0x9a bytes    
clr.dll!CLREventBase::WaitEx()  + 0x13f bytes   
clr.dll!CLREventBase::WaitEx()  + 0xf7 bytes    
clr.dll!CLREventBase::WaitEx()  + 0x78 bytes    
clr.dll!SVR::t_join::join()  + 0xd8 bytes   
clr.dll!SVR::gc_heap::scan_dependent_handles()  + 0x65 bytes    
clr.dll!SVR::gc_heap::mark_phase()  + 0x347 bytes   
clr.dll!SVR::gc_heap::gc1()  + 0x95 bytes   
clr.dll!SVR::gc_heap::garbage_collect()  + 0x16e bytes  
clr.dll!SVR::gc_heap::gc_thread_function()  + 0x3e bytes    
clr.dll!SVR::gc_heap::gc_thread_stub()  + 0x77 bytes    
kernel32.dll!BaseThreadInitThunk()  + 0x1a bytes    
ntdll.dll!RtlUserThreadStart()  + 0x21 bytes    

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

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

22
HellBrick

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

Прежде чем что-то делать в конфигурации GC ..

Одна быстрая проверка ... Используете ли вы параллельные задачи библиотеки ?. Если да, убедитесь, что вы правильно обрабатываете исключения. Если исключения из разных потоков остаются необработанными, они переходят к финализатору, который затем завершает работу приложения. Есть несколько способов аккуратно обращаться с ними. Обработка «агрегатных» исключений - это один из способов (который мы использовали для решения!).

http://msdn.Microsoft.com/en-us/library/dd537614.aspx

У меня нет 50 баллов, чтобы добавить комментарий, поэтому добавляю его в качестве ответа ...

5
SridharVenkat

У нас была такая же проблема в нашем настольном приложении .NET 4.5 - веб-скребке. Он разбился случайно под большой нагрузкой. Итак, мы искали способы выяснить причину в течение нескольких месяцев: мы перепробовали все! Отключение одновременного GC, установка его в режим сервера и многие другие обходные пути, пока мы не осознаем, что сбой произошел из-за модуля PhantomJS . Он использует некоторые неуправляемые ресурсы и не очищает их впоследствии :( Таким образом, мы создали автономное консольное приложение для интеграции с PhantomJS. Теперь мы запускаем это консольное приложение с помощью Process.Start из нашего веб-скребка и впоследствии уничтожаем его. Это занимает больше времени за соскоб, но больше не вылетает!

0
Daniel Vygolov

Решение, которое мне помогло: удалить .NET 4.5.1, установить 4.0, установить указанное исправление, установить 4.5.1 обратно.

0
Genrih

Я понимаю, что это старый пост, однако я столкнулся с той же проблемой, что и ОП. Точка атлас сделана:

Измените время выполнения на x86 или x64 и попробуйте снова; Вы также можете связываться с одновременными настройками GC, как вы уже пробовали.

Был ключ для меня. Все мои проекты были установлены на Любой процессор за исключением одного (по совпадению точка входа для приложения, которое является проектом консольного приложения). Этот проект был установлен на x86. Как только я изменил его на Любой процессор приложение работало правильно.

0
HighGuard2012

Я только что закончил разговор с Microsoft, так как мне удалось воспроизвести проблему, которая похожа.

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

  • Запустите код в Windows 8.1 (последние обновления). Очевидно, Windows 8.1 имеет более новую версию .NET, чем другие версии Windows.
  • Если вы используете AssemblyBuilder (как я), попробуйте изменить его в режим Run вместо RunAndCollect.
  • Измените время выполнения на x86 или x64 и попробуйте снова; Вы также можете связываться с одновременными настройками GC, как вы уже пробовали.
  • Пока мы говорим, моя ошибка исправлена, что в основном означает, что будет обновление Windows, которое позаботится об этом. Возможно, это также вариант просто ждать этого; Я не ожидаю, что это займет слишком много времени, так как это очень важно для многих программ.
0
atlaste

Моя проблема странная, каждые 5-10 минут мой пул приложений продолжал падать с этим кодом выхода (80131506). Я не уверен, что в высокопоточной задаче/расписании вы должны использовать сборщик мусора, но здесь сработало следующее решение.

Я добавил задание, которое вызывает GC.GetTotalMemory (true) каждую минуту. Я предполагаю, что по какой-то причине GC не вызывает автоматический сборщик мусора достаточно часто для большого количества одноразовых предметов, которые я использую. Но это исправит мою проблему! Это скорее быстрое решение, чем окончательное решение;)

0
Dave Lizotte

Я наконец нашел исправление, которое смог установить. У меня тоже 4.5 и другие исправления для 4.0 не устанавливались. Удаление 4.5 тоже не исправило. Исправить в ссылке на самом деле это исправить.

http://kb.machsol.com/Knowledgebase/Article/50305

0
acheron55