У меня утечка памяти в приложении веб-службы .Net. По предложению я могу проанализировать файл дампа. Я предполагаю, что это утечка собственной памяти. Но я не могу понять основную причину проблемы. Я выполнил шаги, указанные в ссылке
Вот что у меня есть на данный момент
сводка адресов
--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Heap 328 4a256000 ( 1.159 GB) 69.38% 57.93%
<unknown> 1253 1b64b000 ( 438.293 MB) 25.63% 21.40%
Free 246 151fa000 ( 337.977 MB) 16.50%
Собственная куча
0:000> !heap -s
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-----------------------------------------------------------------------------
001b0000 00000002 1036480 1024552 1036480 411 745 68 5 0 LFH
00010000 00008000 64 4 64 2 1 1 0 0
001b0000 использует более 1 ГБ
Информация о размещении
0:000> !heap -stat -h 001b0000
heap @ 001b0000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
4e24 3a24 - 11bf2510 (28.82)
1001f e89 - e8ac297 (23.61)
Фильтрация 4e24
0:000> !heap -flt s 4e24
_HEAP @ 1b0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
01fa4810 09c6 0000 [00] 01fa4818 04e24 - (busy)
01fa9640 09c6 09c6 [00] 01fa9648 04e24 - (busy)
01fae470 09c6 09c6 [00] 01fae478 04e24 - (busy)
Много дел
0:000> dc 01fb32a0 L 2000
01fb32a0 b87718ff 0c12a52e 6f4d3c00 656c7564 ..w......<Module
01fb32b0 6977003e 4d2e796c 4d6b636f 6c75646f >.wily.MockModul
01fb32c0 65440065 6c756166 79442074 696d616e e.Default Dynami
01fb32d0 6f4d2063 656c7564 6c697700 67412e79 c Module.wily.Ag
01fb32e0 00746e65 2e6d6f63 796c6977 6573692e ent.com.wily.ise
01fb32f0 7261676e 65722e64 74736967 49007972 ngard.registry.I
01fb3300 69676552 79727473 76726553 00656369 RegistryService.
01fb3310 6f63736d 62696c72 73795300 006d6574 mscorlib.System.
01fb3320 656a624f 50007463 79786f72 67655249 Object.ProxyIReg
01fb3330 72747369 72655379 65636976 6f4d4e00 istryService.NMo
01fb3340 49006b63 6f766e49 69746163 61486e6f ck.IInvocationHa
01fb3350 656c646e 695f0072 636f766e 6f697461 ndler._invocatio
01fb3360 6e61486e 72656c64 73795300 2e6d6574 nHandler.System.
01fb3370 6c666552 69746365 4d006e6f 6f687465 Reflection.Metho
01fb3380 666e4964 6d5f006f 6f687465 666e4964 dInfo._methodInf
01fb3390 70614d6f 766e4900 00656b6f 2e6d6f63 oMap.Invoke.com.
01fb33a0 796c6977 6573692e 7261676e 74752e64 wily.isengard.ut
01fb33b0 742e6c69 00656572 65726944 726f7463 il.tree.Director
01fb33c0 74615079 646e4168 72746e45 65520079 yPathAndEntry.Re
01fb33d0 74736967 6e457972 00797274 72657571 gistryEntry.quer
01fb33e0 746e4579 73656972 6d6f6300 6c69772e yEntries.com.wil
01fb33f0 73692e79 61676e65 6f2e6472 696f676e y.isengard.ongoi
01fb3400 7571676e 00797265 65755141 6f4e7972 ngquery.AQueryNo
01fb3410 69666974 69746163 72006e6f 73696765 tification.regis
01fb3420 4f726574 696f676e 7551676e 00797265 terOngoingQuery.
01fb3430 2e6d6f63 796c6977 6573692e 7261676e com.wily.isengar
01fb3440 6f702e64 666f7473 65636966 736f5000 d.postoffice.Pos
01fb3450 66664f74 53656369 69636570 72656966 tOfficeSpecifier
01fb3460 72694400 6f746365 61507972 61006874 .DirectoryPath.a
01fb3470 6e456464 00797274 45746567 7972746e ddEntry.getEntry
01fb3480 6c656400 45657465 7972746e 74656700 .deleteEntry.get
01fb3490 44627553 63657269 69726f74 2e007365 SubDirectories..
01fb34a0 726f7463 74632e00 0000726f 00000000 ctor..ctor......
01fb34b0 00000000 00000000 00000000 00000000 ...............
Я не уверен, что нахожусь на правильном пути анализа причин
Откуда вы взяли 01fb32a0?
анализировать использование памяти с помощью профилировщика или ETW (WPR.exe/WPA.exe из Windows Performance Toolkit)
@ThomasWeller 01fb32a0 также является одним из элементов Heap_entry, показывающих, что он занят. Когда я сделал !eeheap -gc, он показал, что был обнаружен 12601 потенциальный недостижимый блок.