Недавно у нас был 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 за помощь в комментариях.
Вот что я сделал, чтобы найти корень повреждения кучи:
Включено полная проверка кучи с помощью gflags:
gflags -p /enable MyProcess.exe /full
Поймал результирующий аварийный дамп с помощью ADPlus:
adplus.exe -crash -o <outputdirectory> -p <PID>
Открыл получившийся аварийный дамп в WinDbg и запустил:
!analyze -v
Спасибо за @MarcSherman и @SevaTitov в комментариях.
Других решений пока нет …