Утечка встроенной памяти Windbg не может найти основную причину

avatar
Gopinath
7 апреля 2018 в 22:17
621
1
1

У меня утечка памяти в приложении веб-службы .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  ...............

Я не уверен, что нахожусь на правильном пути анализа причин

Источник
Thomas Weller
8 апреля 2018 в 10:56
0

Откуда вы взяли 01fb32a0?

magicandre1981
8 апреля 2018 в 16:02
0

анализировать использование памяти с помощью профилировщика или ETW (WPR.exe/WPA.exe из Windows Performance Toolkit)

Gopinath
8 апреля 2018 в 18:02
0

@ThomasWeller 01fb32a0 также является одним из элементов Heap_entry, показывающих, что он занят. Когда я сделал !eeheap -gc, он показал, что был обнаружен 12601 потенциальный недостижимый блок.

Ответы (1)

avatar
mistika
18 января 2020 в 01:13
0

Этот < модуль > в начале является признаком динамически генерируемой сборки.

Загрузить расширение SOS, используя .loadby sos clr (для дампа текущей машины) или .cordll -ve -u -l, если вы отлаживаете чужой дамп (работает плохо) в старом Windbg 6.x, но хорошо работает для WinDbg из Windows Development Kit 8 и выше)

Выполните !eeheap и проверьте раздел Module Thunk heaps. Он должен содержать тысячи записей:

--------------------------------------
Module Thunk heaps:
Module 736b1000: Size: 0x0 (0) bytes.
Module 004f2ed4: Size: 0x0 (0) bytes.
...
<thousands of similar lines>
...
Total size:      Size: 0x0 (0) bytes.

В моем случае это были сборки, сгенерированные для сериализации классом MS XmlSerializer, которые заняли всю память:

00000000`264b7640 00 00 3e 00 ce 01 00 00 00 00 00 00 00 3c 4d 6f  ..>..........<Mo
00000000`264b7650 64 75 6c 65 3e 00 4d 69 63 72 6f 73 6f 66 74 2e  dule>.Microsoft.
00000000`264b7660 47 65 6e 65 72 61 74 65 64 43 6f 64 65 00 52 65  GeneratedCode.Re
00000000`264b7670 66 45 6d 69 74 5f 49 6e 4d 65 6d 6f 72 79 4d 61  fEmit_InMemoryMa
00000000`264b7680 6e 69 66 65 73 74 4d 6f 64 75 6c 65 00 6d 73 63  nifestModule.msc
00000000`264b7690 6f 72 6c 69 62 00 53 79 73 74 65 6d 2e 53 65 63  orlib.System.Sec

Я мог бы избежать этой утечки, используя только один экземпляр XmlSerializer для каждого типа.

В вашем случае кажется, что какая-то другая вещь (wily.MockModule) генерирует сборки, и может потребоваться какое-то другое решение