отладка исчезающего приложения .NET с помощью ADPlus, получение исключения CONTRL_C_OR_Debug_Break

Недавно у нас был 64-битный процесс .NET 4.0 с некоторым неуправляемым сбоем кода, просто исчезнувшим. Никакие записи средства просмотра событий, никакие диалоговые окна ошибок Windows, и наши текущие инструкции регистрации и трассировки не указывают на что-либо очевидное. База кода очень большая, поэтому добавление дополнительных операторов трассировки определенно займет много времени.

У нас есть несколько сторонних библиотек DLL, но у нас есть доступ ко всем необходимым файлам PDB. Авария происходит часто в течение дня, но не через равные промежутки времени. Наша группа подозревает, что причиной может быть неправильный многоадресный трафик, но мы не уверены на 100%.

Мы использовали ADPlus для отладки процесса в режиме сбоя:

adplus -crash -p <pid> -o c:\temp

и мы получаем очень странное поведение … последний мини-дамп, когда происходит сбой, это первый шанс «CONTRL_C_OR_Debug_Break исключение»; мы наверняка не нажимаем «Ctrl + C». Каждый раз, когда мы подключали отладчик, мы получали этот мини-дамп где-то от 10 минут до 2 часов после запуска. Никаких исключений второго шанса, а также неуправляемая память или процессор.

По общему признанию, я новичок, когда дело доходит до CDB / ADPlus / WinDbg, но я знаю, по крайней мере, несколько команд windbg / SOS, чтобы плавать вокруг нескольких аварийных дампов; на этом минидампе я в тупике.

Собираюсь ли я правильно диагностировать эту проблему? Что еще мы можем сделать?

ОБНОВИТЬ

После получения правильных файлов символов Windows Server 2008 это выглядит как стек. Какой лучший способ выследить возможную кучу коррупции?

0:039> k
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP          RetAddr           Call Site
00000000`2d06f4f0 00000000`77834736 ntdll!RtlReportCriticalFailure+0x2f
00000000`2d06f5c0 00000000`77835942 ntdll!RtlpReportHeapFailure+0x26
00000000`2d06f5f0 00000000`778375f4 ntdll!RtlpHeapHandleError+0x12
00000000`2d06f620 00000000`777ddc8f ntdll!RtlpLogHeapFailure+0xa4
00000000`2d06f650 00000000`7767307a ntdll! ?? ::FNODOBFM::`string'+0x10c54
00000000`2d06f6d0 00000000`72a88cc4 kernel32!HeapFree+0xa
00000000`2d06f700 00000000`6ea37ffb msvcr100!free+0x1c
00000000`2d06f730 00000000`eb692d6c jvm+0x187ffb
00000000`2d06f738 00000000`2d06f7a8 0xeb692d6c
00000000`2d06f740 00000000`00000000 0x2d06f7a8

ОБНОВЛЕНИЕ 2

Оказывается, комбинация нашего приложения + более новая версия jdk действительно разрушала кучу. Поймал аварийный дамп, установив в gflags:

gflags -p /enable MyProcess.exe /full

До сих пор точно не знаю почему, но понижение версии нашего jvm на самом деле решило проблему на данный момент. Большое спасибо @MarcSherman и @SevaTitov за помощь в комментариях.

1

Решение

Вот что я сделал, чтобы найти корень повреждения кучи:

  1. Установлены Инструменты отладки для Windows как автономный компонент.
  2. Включено полная проверка кучи с помощью gflags:

    gflags -p /enable MyProcess.exe /full
    
  3. Поймал результирующий аварийный дамп с помощью ADPlus:

    adplus.exe -crash -o <outputdirectory> -p <PID>
    
  4. Открыл получившийся аварийный дамп в WinDbg и запустил:

    !analyze -v
    

Спасибо за @MarcSherman и @SevaTitov в комментариях.

1

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]