нечетная утечка ручки

Question

Мое приложение (базовое приложение - взаимодействие MFC с C ++ / CLI, но оно также содержит много C #, Windows Forms, WPF) имеет утечку дескриптора.Вскоре после запуска приложения я вижу, что количество дескрипторов в диспетчере задач непрерывно растет (со скоростью 10 новых дескрипторов в секунду).Поэтому я использовал handles.exe , чтобы посмотреть, что это за дескрипторы.Я обнаружил, что протекающие ручки - это технологические ручки.И они являются дескрипторами процесса моего приложения.

Поэтому мне интересно, какие операции обычно создают дескриптор процесса, в котором оно выполняется. Есть идеи?Вы когда-нибудь видели что-то подобное?Что еще я мог сделать, чтобы отследить утечку, учитывая, что я не могу использовать отладочные библиотеки DLL и что я могу использовать только инструменты, которые можно развернуть xcopy.

Обновление:

Я смог добавить windbg и ! Handle,! Htrace в него и обнаружил, что все дескрипторы процесса созданы с использованием следующих трассировок стека(упорядочено по частоте):

0x79f7570b: mscorwks!CorExitProcess+0x00022055
0x79f03edd: mscorwks!GetPrivateContextsPerfCounters+0x0000b6fe
0x79f04b87: mscorwks!GetPrivateContextsPerfCounters+0x0000c3a8
0x79f04b03: mscorwks!GetPrivateContextsPerfCounters+0x0000c324
0x79f919bf: mscorwks!CorExitProcess+0x0003e309
0x79f91b28: mscorwks!CorExitProcess+0x0003e472
0x792d6b4c: mscorlib_ni+0x00216b4c
0x1391a663: +0x1391a663
0x1391a0b1: +0x1391a0b1
0x7a9ea544: System_ni+0x005aa544
0x792a842f: mscorlib_ni+0x001e842f

или

0x7c8106f5: kernel32!CreateThread+0x0000001e
0x79f04bb2: mscorwks!GetPrivateContextsPerfCounters+0x0000c3d3
0x79f04b03: mscorwks!GetPrivateContextsPerfCounters+0x0000c324
0x79f919bf: mscorwks!CorExitProcess+0x0003e309
0x79f91b28: mscorwks!CorExitProcess+0x0003e472
0x792d6b4c: mscorlib_ni+0x00216b4c
0x1391a663: +0x1391a663
0x1391a0b1: +0x1391a0b1
0x7a9ea544: System_ni+0x005aa544
0x792a842f: mscorlib_ni+0x001e842f

или

0x08ec2eba: +0x08ec2eba
0x792b8277: mscorlib_ni+0x001f8277
0x792b8190: mscorlib_ni+0x001f8190
0x792b8040: mscorlib_ni+0x001f8040
0x792b7ff2: mscorlib_ni+0x001f7ff2
0x677e48f3: System_Runtime_Remoting_ni+0x000748f3
0x677e44be: System_Runtime_Remoting_ni+0x000744be
0x677e46ec: System_Runtime_Remoting_ni+0x000746ec
0x677e8408: System_Runtime_Remoting_ni+0x00078408
0x7926eb8d: mscorlib_ni+0x001aeb8d

Теперь, что это говорит мне?

Answer 1

Стеки вызовов выглядят неправильно. Правильно ли вы настроили сервер символов? .symfix должен сделать трюк в Windbg. После этого вы должны получить лучшую трассировку стека.

Похоже, что часть кода, в которой решена эта проблема, имеет смысл разбить на DuplicateHandle и OpenProcess и вывести туда стек управляемых вызовов. Эти два метода являются единственными, которые могут создать реальный дескриптор процесса.

Вы можете объявить такую ​​точку останова и выполнять команды при достижении точки останова. В этом случае распечатывается управляемый стек, а затем выполнение продолжается.

bp kernel32!OpenProcess "!ClrStack;g"

Answer 2

Те же проблемы с веб-сервисом, вызывающим COM-объекты через взаимодействие.

Я решил эту проблему, явно вызвав Marshal.ReleaseComObject для созданных мною объектов взаимодействия. Никаких проблем после этого момента для меня.

Надеюсь, это поможет.

Answer 3

Итак ... вы явно используете счетчики производительности (если это так, попробуйте отключить их, чтобы сузить источник утечек).