Разница между выводом! sos.rcw и! sos.dumprcw

Недавно мне потребовалось отладить дамп памяти процесса CLR, в котором очередь финализации блокировалась COM-объектом. Хотя я в основном определил проблему, я не уверен в различиях между некоторыми результатами и прошу некоторых пояснений.

Я использовал SOSEX для сброса RCW. Результат выглядит следующим образом:

0:019> !sosex.rcw
SyncBlock           OwnerObject           RCW                RefCount   IUnknown           VTable             
------------------------------------------------------------------------------------------------------------
000000811807b238    0000008118251e18      00000081176b02e0          0   0000008116a6bc68   0061005c00730077
000000811807b5f8    00000081182b7380      0000008118104590          0   0000008116a6bc68   004d005c00730077
0000008562fed748    000000811831f498      0000008562fe7510        129   0000008116a6bc68   00000085632a2ee0
000000856300e168    00000084182ae2f0      0000008563082d00          0   0000008116a6bc68   000000856306a660
--------------
4 RCWs

Дамп vtable не помогает идентифицировать COM-объект.

0:019> dps 00000085632a2ee0
00000085`632a2ee0  00007ffc`31832938 clr!DomainAssembly::`vftable'
00000085`632a2ee8  00000081`18099170
00000085`632a2ef0  00000085`631db8d0
00000085`632a2ef8  00000000`00000000
00000085`632a2f00  00007ffb`d24e4d20
00000085`632a2f08  0063006e`0000000c
00000085`632a2f10  00000085`1833ade9
00000085`632a2f18  00000000`00000000
00000085`632a2f20  00000001`00000007
00000085`632a2f28  00000000`00000000
00000085`632a2f30  00000000`00000000
00000085`632a2f38  00000000`00000000
00000085`632a2f40  00530041`002f0073
00000085`632a2f48  00000085`1833ade1
00000085`632a2f50  00000085`62fe7600
00000085`632a2f58  00000085`631dbd50
0:019> dps 00007ffc`31832938
00007ffc`31832938  00007ffc`31220ac0 clr!DomainAssembly::`vector deleting destructor'
00007ffc`31832940  00007ffc`311405d0 clr!CAssemblyIdentityManager::AddRef
00007ffc`31832948  00007ffc`3119e080 clr!DomainAssembly::Begin
00007ffc`31832950  00007ffc`3119fbe0 clr!DomainAssembly::Allocate
00007ffc`31832958  00007ffc`3119f0f0 clr!DomainAssembly::DeliverSyncEvents
00007ffc`31832960  00007ffc`3119e4d0 clr!DomainAssembly::DeliverAsyncEvents
00007ffc`31832968  00007ffc`311a01c0 clr!DomainAssembly::FindNativeImage
00007ffc`31832970  00007ffc`3160d630 clr!CorHostProtectionManager::QueryInterface
00007ffc`31832978  00007ffc`311405d0 clr!CAssemblyIdentityManager::AddRef
00007ffc`31832980  00007ffc`311405d0 clr!CAssemblyIdentityManager::AddRef
00007ffc`31832988  00007ffc`3160d660 clr!CorHostProtectionManager::SetProtectedCategories
00007ffc`31832990  00007ffc`31406100 clr!CorHostProtectionManager::SetEagerSerializeGrantSets
00007ffc`31832998  00007ffc`31500a30 clr!CCLRErrorReportingManager::QueryInterface
00007ffc`318329a0  00007ffc`311405d0 clr!CAssemblyIdentityManager::AddRef
00007ffc`318329a8  00007ffc`311405d0 clr!CAssemblyIdentityManager::AddRef
00007ffc`318329b0  00007ffc`314fcc50 clr!CCLRErrorReportingManager::GetBucketParametersForCurrentException

Однако, если я использую! Sos.dumprcw, отображается другой адрес vtable (и IUnknown):

0:019> !sos.dumprcw 0000008562fe7510
Managed object:             000000811831f498
Creating thread:            0000008562ff0050
IUnknown pointer:           000000811693a8d0
COM Context:                0000008116a6bc68
Managed ref count:          1
IUnknown V-table pointer :  00007ffc33609078 (captured at RCW creation time)
Flags:                      
COM interface pointers:
              IP          Context               MT Type
000000811693a8d0 0000008116a6bc68 00007ffbd19db8c8 Microsoft.Web.Administration.Interop.IAppHostAdminManager

Выгрузка этого «указателя IUnknown V-table» идентифицирует источник ссылки COM.

0:019> dps 00007ffc33609078 
00007ffc`33609078  00007ffc`33607cb0 nativerd!CONFIG_SYSTEM::QueryInterface
00007ffc`33609080  00007ffc`33605750 nativerd!CONFIG_SYSTEM::AddRef
00007ffc`33609088  00007ffc`33605700 nativerd!CONFIG_SYSTEM::Release
00007ffc`33609090  00007ffc`33627fe0 nativerd!CONFIG_SYSTEM::GetAdminSection
00007ffc`33609098  00007ffc`33603fb0 nativerd!CONFIG_SYSTEM::GetMetadata
00007ffc`336090a0  00007ffc`33609e40 nativerd!CONFIG_SYSTEM::SetMetadata
00007ffc`336090a8  00007ffc`3364fc30 nativerd!CONFIG_SYSTEM::get_ConfigManager
00007ffc`336090b0  00007ffc`3364ecc0 nativerd!CONFIG_SYSTEM::CommitChanges
00007ffc`336090b8  00007ffc`3363c7d0 nativerd!CONFIG_SYSTEM::get_CommitPath
00007ffc`336090c0  00007ffc`336235c0 nativerd!CONFIG_SYSTEM::put_CommitPath
00007ffc`336090c8  00007ffc`33626190 nativerd!CONFIG_SYSTEM::`vector deleting destructor'
00007ffc`336090d0  00007ffc`3362e780 nativerd!CONFIG_MAPPING_EXTENSION::QueryInterface
00007ffc`336090d8  00007ffc`33604730 nativerd!CONFIG_MAPPING_EXTENSION::AddRef
00007ffc`336090e0  00007ffc`33604190 nativerd!CONFIG_MAPPING_EXTENSION::Release
00007ffc`336090e8  00007ffc`336530c0 nativerd!CONFIG_MAPPING_EXTENSION::GetSiteNameFromSiteId
00007ffc`336090f0  00007ffc`33652e20 nativerd!CONFIG_MAPPING_EXTENSION::GetSiteIdFromSiteName

В чем разница между выводом! Sos.dumprcw и! Sosex.rcw в отношении vtable?

Команда dumprcw выявила RCW для интерфейса IAppHostAdminManager. Погоня за указателем интерфейса привела вас к конкретной реализации интерфейса. Судя по всему, он похоронен в недрах C++ расширения IIS, реализующего хост asp.net.

Hans Passant 26.10.2018 19:30

@HansPassant Да, это тоже был мой вывод. Я надеялся определить, какой компонент в нашей кодовой базе создавал экземпляры IAppHostAdminManager, но, похоже, это внутренний интерфейс в Microsoft.Web.Administration.dll, поэтому Microsoft.Web.Administration.ServerManager кажется единственным вероятным кандидатом. Он не был утилизирован должным образом и застревает в процессе завершения. Однако, возвращаясь к основному вопросу, я хотел бы знать, почему адреса vtable, сообщаемые! Sos.dumprcw и! Sosex.rcw, отличаются. Таблица vtable, сообщаемая! Sosex.rcw, не кажется полезной (или неправильной?).

Dono 27.10.2018 06:03
0
2
182
0

Другие вопросы по теме