Как мне интерпретировать результаты проверки кучи WinDbg? - PullRequest
1 голос
/ 01 марта 2012

В WinDbg я выполнил команду !heap -s -v на семи различных аварийных дампах, вызванных повреждением кучи, и у всех были следующие результаты:

..................List corrupted: (Blink->Flink = 0000000000000000) != (Block = 00000000026d0010)
HEAP 0000000002030000 (Seg 00000000026d0000) At 00000000026d0000 Error: block list entry corrupted

HEAP 0000000002030000 (Seg 00000000026d0000) At 00000000026d0000 Error: SegmentIndex field corrupted

HEAP 0000000002030000 (Seg 00000000026d0000) At 0000000002749400 Error: invalid block size

Как мне следует интерпретировать эти результаты?

Я интерпретировал (Seg 00000000026d0000) как означающее, что WinDbg считает, что это сегмент (_HEAP_SEGMENT), но на самом деле это адрес кеша большого блока (это соответствует каждому дампу):

+0x2b8 LargeBlocksIndex : 0x00000000`026d0000 Void

Я подтвердил, что дамп, созданный из той же операционной системы и того же процесса, не вызывает проблем с проверкой WinDbg, пока не произойдет сбой.

Короче говоря, я не знаю, почему WinDbg жалуется на адрес 26d0000 или почему он может интерпретировать его как сегмент (если это даже то, что он делает).

Все дампы были с машины Windows 2003 R2. Процесс 64-битный.

1 Ответ

0 голосов
/ 22 марта 2012

Оказывается, что конкретный сбой, с которым я имел дело, был результатом ограничения на объем данных внутри сегментов кучи Windows 2003 (~ 106 ГиБ). Память становилась слишком фрагментированной, и программе не удавалось найти место внутри сегментов для выделения размером чуть менее 1 МБ. Первоначально я исключил это из-за объема физической памяти на машине (192 ГБ) и ограничения на использование памяти для каждого процесса (8 ТБ).

Мне еще предстоит выяснить причину результатов WinDbg, но я хочу игнорировать его как вероятный ложный положительный результат, поскольку куча находится в несовместимом состоянии с путями кода, которые выполняются, когда куча исчерпывает память сегмента.

...