Подтвердить что ты не робот

.NET 4.5: внутренняя ошибка в .NET Runtime (80131506)/отключение параллельного GC

У меня есть давно работающее приложение .NET 4.5, которое случайно падает, оставляя сообщение, указанное в заголовке вопроса в журнале событий. Проблема воспроизводится на трех разных машинах и в двух разных системах (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

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

  • Я попытался установить это исправление, но оно не будет установлено ни на одной из моих машин (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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

Наконец-то я нашел исправление, которое мог установить. У меня также есть 4.5, а другое исправление для 4.0 не было установлено. Удаление 4.5 тоже не исправило. Исправьте ссылку, которая фактически зафиксировала ее.

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

Ответ 5

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

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

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

Ответ 6

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