Estoy trabajando en un vertedero, que trato de investigar, utilizando la tecnología PYKD.
El resultado de lax /2 *!*``vtable' (solo una tecla de retroceso) contiene el siguiente resultado:

745293b8          mfc110u!CPtrList::`vftable'

Sin embargo, cuando intento obtener más información sobre esta clase, aparece una excepción de "símbolo no encontrado":
ódigo fuente de @Python:

dprintln("name=[%s]" % type_stats.name)
if not type_stats.name in typesize_by_type:
  try:
    type_info = typeInfo(type_stats.name)
  except Exception, e:
    dprintln("text=[%s]" % (str(e)))

Salida

name=[mfc110u!CPtrList]
text=['CPtrList' - symbol not found]

El resultado de lalml comando @ devuelve elmfc110u símbolos, como puedes ver aquí:

0:000> lm
start     end        module name
...
744f0000  74930000   mfc110u    (pdb symbols) C:\ProgramData\dbg\sym\mfc110u.i386.pdb\...\mfc110u.i386.pdb
...

Para su información, ahora estoy trabajando con la última versión de PYKD:

0:000> .chain
Extension DLL search Path:
    ...
Extension DLL chain:
    pykd.pyd: image 0.3.3.4, API 1.0.0, built Mon May 14 11:14:43 2018
        [path: C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\winext\pykd.pyd]

ientras tanto, he encontrado una forma muy simple de reproducir el problema sin necesidad de iniciar todo el script (usando el indicador de Windbg):

0:000> !py
Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> typeInfo("mfc110u!CPtrList")
Traceback (most recent call last):
  File "<console>", line 1, in <module>
SymbolException: 'CPtrList' - symbol not found

Además de la respuesta de ussrhero, hay la siguiente información adicional:
El resultado dex /2 *!CPtrList* contiene (entre muchos otros) los siguientes resultados:

009530c4   <application>!CPtrList::~CPtrList
009530be   <application>!CPtrList::CPtrList
...        <application>!CPtrList::...
009abc5c   <application>!CPtrList::`RTTI Base Class Array'
009abc4c   <application>!CPtrList::`RTTI Class Hierarchy Descriptor'
009bcd18   <application>!CPtrList `RTTI Type Descriptor'
009abc30   <application>!CPtrList::`RTTI Base Class Descriptor at (0,-1,0,64)'
7464e9cb   mfc110u!CPtrList::~CPtrList
74544a04   mfc110u!CPtrList::CPtrList
...        mfc110u!CPtrList::...
745293b8   mfc110u!CPtrList::`vftable'
747510da   mfc110u!CPtrList::`vector deleting destructor'
745293cc   mfc110u!CPtrList::`RTTI Complete Object Locator'
7452940c   mfc110u!CPtrList::`RTTI Base Class Array'
745293fc   mfc110u!CPtrList::`RTTI Class Hierarchy Descriptor'
74795778   mfc110u!CPtrList `RTTI Type Descriptor'
745293e0   mfc110u!CPtrList::`RTTI Base Class Descriptor at (0,-1,0,64)'
746fdc68   mfc110u!CPtrList::classCPtrList

El script que estoy usando (heap_stat.py) examina los resultados de!heap -h 0 y busca la entrada correspondiente amfc110u!CPtrList::``vtable'.

El resultado dedt CPtrList comienza con lo siguiente:

0:000> dt CPtrList
<application>!CPtrList => in other words, no 'mfcu110' entry
   +0x000 __VFN_table : Ptr32 

Ya me pregunto desde hace mucho tiempo, ¿cuál es la diferencia entre lamfc110u!CPtrList y el<application>!CPtrList entradas y cuál es el papel exacto de lavtable entrada enx /2 resultado?

¿Algunas ideas
Gracia