Не удалось прочитать аварийный дамп в Windbg

Я получаю исключение stackoverflow в своей программе, которое может происходить из сторонней библиотеки, 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?


windbg adplus
person Billybonks    schedule 17.11.2011    source источник

Ответы (3)


arrow_upward
12
arrow_downward

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

.load wow64exts
.effmach x86
!analyze -v

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

person steve    schedule 19.11.2011
comment
хорошо, извините за поздний ответ, я нашел проблему, но тем не менее это должно мне помочь ... но ваша идея кажется хорошей - person Billybonks; 01.12.2011
comment
Это помогло мне только сейчас! Большое спасибо :) - person malkia; 14.12.2012

arrow_upward
1
arrow_downward

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

person user1031730    schedule 17.01.2012

arrow_upward
0
arrow_downward

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

.symfix
.reload
~*kb

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

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

person seva titov    schedule 17.11.2011