Невозможно прочитать аварийный дамп в windbg - PullRequest
Новая
       36

Невозможно прочитать аварийный дамп в windbg

4 голосов
/ 17 ноября 2011

Я получаю исключение стека переполнения в моей программе, которое может происходить из третьей стороны, microsoft.sharepoint.client.runtime.dll.

Используя adplus для создания аварийного дампа, я сталкиваюсь с проблемой, из-за которой я пытаюсь получить какую-либо информацию из нее, когда открываю ее в windbg. Вот что я получаю в ответ: 

> 0:000> .restart /f

Loading Dump File [C:\symbols\FULLDUMP_FirstChance_epr_Process_Shut_Down_DocumentumMigrator.exe__0234_2011-11-17_15-19-59-426_0d80.dmp]
User Mini Dump File with Full Memory: Only application data is available

Comment: 'FirstChance_epr_Process_Shut_Down'
Symbol search path is: C:\symbols
Executable search path is: 
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Machine Name:
Debug session time: Thu Nov 17 15:19:59.000 2011 (UTC + 2:00)
System Uptime: 2 days 2:44:48.177
Process Uptime: 0 days 0:13:05.000
.........................................WARNING: rsaenh overlaps cryptsp
.................WARNING: rasman overlaps apphelp
......
..WARNING: webio overlaps winhttp
.WARNING: credssp overlaps mswsock
.WARNING: IPHLPAPI overlaps mswsock
.WARNING: winnsi overlaps mswsock
............
wow64cpu!CpupSyscallStub+0x9:
00000000`74e42e09 c3              ret

Любые идеи о том, как я могу получить больше информации из дампа, или как использовать его, чтобы найти, где происходит моя ошибка stackoverflow?

Ответы [ 3 ]

11 голосов
/ 20 ноября 2011

Проблема, с которой вы сталкиваетесь, состоит в том, что процесс 32-битный, но вы работаете на 64-битном, поэтому ваш дамп является 64-битнымЧтобы использовать дамп, вы должны выполнить следующие команды: 

.load wow64exts
.effmach x86
!analyze -v

Последняя команда должна дать вам значимую трассировку стека.

1 голос
/ 17 января 2012

На этой странице содержится много полезной информации и методов для анализа проблемы. http://www.dumpanalysis.org/blog/index.php/2007/09/11/crash-dump-analysis-patterns-part-26/

0 голосов
/ 17 ноября 2011

Вы не упомянули, является ли ваш код управляемым или неуправляемым.Предполагая, что это неуправляемо.В отладчике: 

.symfix
.reload
~*kb

Просмотрите стек вызовов для всех потоков и определите поток, вызвавший SO.С SO легко идентифицировать поток, потому что стек вызовов будет очень длинным.Переключитесь на этот поток с помощью команды ~<N>s, где указан номер потока, выведите больше стека вызовов с помощью команды k 200, чтобы получить до 200 строк стека вызовов.В самом низу стека вызовов вы сможете увидеть код, который создал вложенный цикл.

Если ваш код управляется, используйте расширение SOS для сброса стеков вызовов.

...