Помогите с действительно странным вызовом COM + - PullRequest
Новая
       15

Помогите с действительно странным вызовом COM +

2 голосов
/ 21 сентября 2011

У нас есть устаревшая библиотека COM +, которая вызывается старым ASP-приложением. Периодически происходит сбой, и стек вызовов выглядит очень странно

Похоже, что вызов DllUnregisterServer и CoInstall появляется внутри стека вызовов (мы ничего не устанавливаем / динамически ничего внутри кода - это просто запрос базы данных).

Мне интересно, возможно ли, что MSI "защита файлов" запускает и вызывает сбой. Как вы думаете, это возможно? В любом случае я могу выкопать больше информации? (это старое приложение VFP, поэтому я не думаю, что смогу получить правильные символы отладки)

Вот стек вызовов: 


Call Stack: 
vfp9t! + 0x2272f
vfp9t!VFPDllGetClassObject + 0xb6
ctcvccomasyncproxy!DllGetClassObject + 0x3e
ole32!CoInitializeSecurity + 0x5ff5
ole32!CoInitializeSecurity + 0x5bdc
ole32!CoGetTreatAsClass + 0x2a2
ole32!CoInitializeSecurity + 0x3a2b
COMSVCS!DispManGetContext + 0xbc07
ole32!CoInitializeSecurity + 0x3a2b
ole32!CoInstall + 0x6ed
ole32!CoQueryAuthenticationServices + 0x21aa
ole32!CoQueryAuthenticationServices + 0x2c56
ole32!CoGetContextToken + 0xd48d
ole32!CreateStreamOnHGlobal + 0x1b7c
ole32!CoCreateObjectInContext + 0xd9f
ole32!CoInstall + 0x903
ole32!CoGetContextToken + 0x12f5b
RPCRT4!NdrServerInitialize + 0x1fc
RPCRT4!NdrStubCall2 + 0x217
RPCRT4!CStdStubBuffer_Invoke + 0x82
ole32!StgGetIFillLockBytesOnFile + 0x13b27
ole32!StgGetIFillLockBytesOnFile + 0x13ad4
ole32!DcomChannelSetHResult + 0xaab
ole32!DcomChannelSetHResult + 0x495
ole32!CoFreeUnusedLibrariesEx + 0xb06
ole32!StgGetIFillLockBytesOnFile + 0x139e1
ole32!StgGetIFillLockBytesOnFile + 0x13872
ole32!StgGetIFillLockBytesOnFile + 0x12d59
ole32!CoFreeUnusedLibrariesEx + 0x9f5
ole32!CoFreeUnusedLibrariesEx + 0x9c0
USER32!LoadCursorW + 0x4cf5
USER32!LoadCursorW + 0x4e86
USER32!TranslateMessageEx + 0x10d
USER32!DispatchMessageW + 0xf
COMSVCS!DllUnregisterServer + 0x270
COMSVCS!DllUnregisterServer + 0x180
COMSVCS!DllUnregisterServer + 0xc6c
COMSVCS!DllUnregisterServer + 0xf4d
msvcrt!_endthreadex + 0xa3
kernel32!GetModuleHandleA + 0xdf

Ответы [ 2 ]

2 голосов
/ 01 октября 2011

ole32! CoInstall + 0x6ed

Смещение + 0x6ed является важным показателем качества.Он говорит вам, что адрес возврата составляет 1773 байта от известного адреса CoInstall.Это довольно много.У построителя трассировки стека просто не было другого известного адреса, который был бы ближе, поэтому он мог только предложить CoInstall в качестве предположения.Как только смещение превышает 0x100, вероятность того, что код фактически является частью указанной известной функции, начинает быстро уменьшаться.

В трассе много записей с огромными смещениями.Делаем весь след довольно низкого качества.Редактирование трассировки стека и оставление на месте только линий хорошего качества: 

vfp9t!VFPDllGetClassObject + 0xb6
ctcvccomasyncproxy!DllGetClassObject + 0x3e
...
RPCRT4!CStdStubBuffer_Invoke + 0x82
...
USER32!DispatchMessageW + 0xf

Это довольно стандартная трассировка стека для перекрестного запроса на получение фабрики класса объектов COM.Почему это не удалось, не понятно, у вас нет отладочных символов для foxpro и вы не документировали HRESULT.

0 голосов
/ 01 октября 2011

  1. Этот дамп стека не выглядит правдоподобным. Это почти наверняка бесполезно.

  2. Я предлагаю написать необработанный обработчик исключений и попытаться снова вызвать его сбой. Ваш обработчик может попытаться сделать лучший дамп стека или даже правильный аварийный дамп.
    Смотри

В вашем коде будет обработчик, который вызывает код dll.

...