WPF: поиск и устранение неисправностей приложений с чрезмерно высокой загрузкой процессора на Win 7 64 с использованием WinDbg

Question

У меня есть приложение .NET 3.5 WPF, которое будет время от времени использовать 96-99% времени процессора при запуске только на Win 7 64 бит. Конечно, когда это происходит, даже само приложение перестает работать правильно. Это еще одна проблема, которая возникает только в 64-битной версии Windows 7.

Приложение в настоящее время находится в этом состоянии, и я хочу использовать WinDbg или другое средство отладки, чтобы захватить как можно больше информации. Кто-нибудь, кто может помочь с этим в режиме реального времени?

Во-первых, это то, что я могу получить от Process Explorer: По мере того как прикрепленное изображение показывает , у меня есть количество нитей 40 с кучей из них, имеющий начальный адрес:

mscorwrks.dll!GetMetaDataInternalInterfaceFromPublic+0x934c. 

Есть о 24 потока, которые в настоящее время показывают это как начальный адрес. Но я не могу связать это с чем-либо в моем коде.

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

!runaway 3 

, который дает мне:

0:039> !runaway 3 
User Mode Time 
    Thread  Time 
    33:29bc  0 days 0:27:48.711 
    21:2880  0 days 0:26:22.021 
    34:18cc  0 days 0:24:38.873 
    18:2a04  0 days 0:23:56.753 
    23:2618  0 days 0:18:58.947 
    24:27e8  0 days 0:17:36.859 
    30:21d4  0 days 0:17:05.800 
    32:248c  0 days 0:17:04.286 
    35:2b00  0 days 0:16:20.809 
    22:2680  0 days 0:15:37.597 
    5:2a28  0 days 0:15:10.234 
    31:ee4  0 days 0:15:07.348 
    20:20f0  0 days 0:14:32.903 
    17:29ac  0 days 0:14:02.202 
    10:20dc  0 days 0:00:51.152 
    11:2ad0  0 days 0:00:11.247 
    37:2c14  0 days 0:00:06.489 
    38:2f3c  0 days 0:00:01.466 
    25:1db8  0 days 0:00:00.920 
    1:2a84  0 days 0:00:00.452 
    0:1494  0 days 0:00:00.093 
    2:1ba0  0 days 0:00:00.078 
    29:53c  0 days 0:00:00.015 
    27:278c  0 days 0:00:00.015 
    7:8d4  0 days 0:00:00.015 
    4:2620  0 days 0:00:00.015 
    39:215c  0 days 0:00:00.000 
    36:2088  0 days 0:00:00.000 
    28:26e0  0 days 0:00:00.000 
    26:2960  0 days 0:00:00.000 
    19:2a10  0 days 0:00:00.000 
    16:2a70  0 days 0:00:00.000 
    15:24a8  0 days 0:00:00.000 
    14:2208  0 days 0:00:00.000 
    13:2bcc  0 days 0:00:00.000 
    12:2a6c  0 days 0:00:00.000 
    9:1a38  0 days 0:00:00.000 
    8:2a98  0 days 0:00:00.000 
    6:1200  0 days 0:00:00.000 
    3:2af8  0 days 0:00:00.000 
Kernel Mode Time 
    Thread  Time 
    11:2ad0  0 days 0:00:03.650 
    10:20dc  0 days 0:00:02.230 
    33:29bc  0 days 0:00:00.686 
    34:18cc  0 days 0:00:00.577 
    21:2880  0 days 0:00:00.327 
    18:2a04  0 days 0:00:00.327 
    24:27e8  0 days 0:00:00.280 
    35:2b00  0 days 0:00:00.249 
    1:2a84  0 days 0:00:00.218 
    30:21d4  0 days 0:00:00.156 
    22:2680  0 days 0:00:00.140 
    5:2a28  0 days 0:00:00.140 
    37:2c14  0 days 0:00:00.124 
    23:2618  0 days 0:00:00.109 
    2:1ba0  0 days 0:00:00.109 
    25:1db8  0 days 0:00:00.093 
    20:20f0  0 days 0:00:00.093 
    17:29ac  0 days 0:00:00.093 
    0:1494  0 days 0:00:00.078 
    7:8d4  0 days 0:00:00.062 
    32:248c  0 days 0:00:00.046 
    3:2af8  0 days 0:00:00.046 
    31:ee4  0 days 0:00:00.031 
    8:2a98  0 days 0:00:00.031 
    38:2f3c  0 days 0:00:00.015 
    27:278c  0 days 0:00:00.015 
    16:2a70  0 days 0:00:00.015 
    15:24a8  0 days 0:00:00.015 
    39:215c  0 days 0:00:00.000 
    36:2088  0 days 0:00:00.000 
    29:53c  0 days 0:00:00.000 
    28:26e0  0 days 0:00:00.000 
    26:2960  0 days 0:00:00.000 
    19:2a10  0 days 0:00:00.000 
    14:2208  0 days 0:00:00.000 
    13:2bcc  0 days 0:00:00.000 
    12:2a6c  0 days 0:00:00.000 
    9:1a38  0 days 0:00:00.000 
    6:1200  0 days 0:00:00.000 
    4:2620  0 days 0:00:00.000 

Когда я выполняю g продолжить процесс, я получаю

0:039> g 
(2944.1d6c): Break instruction exception - code 80000003 (first chance) 
mscorlib_ni+0x367240: 
000007fe`f8337240 cc    int  3 

и процесс остается приостановленным. Как продолжить?

Answer 1

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

.symopt + 0х100; .symfix с: \ websym; .reload

Я думаю, что нить 39 является впрыскивается отладчик нить так это нормально, чтобы получить эту команду останова один раз после удара g. Если вы получаете его более одного раза, возникает проблема.

Но прежде, чем поразить г, переключатель первого потока (33 в вашем случае) в убегающем выходе, как это: ~ 33s

Затем загрузите правильный DLL расширения .NET отладчика. Если до .NET 4, сделайте следующее:

.loadby SOS.dll mscorwks

Если .NET 4, а затем сделать:

.loadby SOS.dll CLR

Теперь это сделать, чтобы увидеть управляемый стек:

clrstack

затем ударил г, дайте ему поработать несколько секунд, ворваться снова, а затем выпустить clrstack снова!. Повторите несколько раз, чтобы дать вам представление о том, что делает поток 33. Обратите внимание: каждый раз, когда вы ломаетесь, вам придется переключиться обратно в поток 33 до выпуска! Clrstack.

Если отображаемый управляемый стек не отображается, введите kb, чтобы просмотреть собственный стек.

Возможно, вам также необходимо выяснить, были ли вы управляете исключениями для этого потока. ! pe сделает это для вас (после того, как вы перейдете к этой теме). Вы также можете сбрасывать все управляемые объекты исключений. Я думаю, что команда - это dumpallexceptions, но проверять помощь (используя! Help), чтобы быть уверенным. Примечание. .NET preallocates 3 объекта исключения при запуске, которые могут (в большинстве случаев) игнорироваться на выходе! Dumpallexceptions (один из них связан с ситуациями нехватки памяти).

Марк

Answer 2

Я думаю, что исключения CLR то, что, что останавливает вас от продолжения процесса. Исключить эти исключения с помощью «sxi clr» и продолжить

Answer 3

Простой трюк состоит в том, чтобы захватить группу зависающих дампов (один минутный интервал), когда загрузка процессора высока, а затем проанализировать их в WinDbg. Используя runaway, вы можете увидеть, какие потоки потребляют большую часть процессора, а затем проверить его стек вызовов, чтобы найти возможную причину.

То, что вы сделали, называется живым отладчиком, и это непросто для новичка.