Question

我们有一个旧的ASP应用程序调用的旧版COM + dll。它会定期崩溃，并且调用堆栈非常奇怪

似乎调用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

Answer 1

ole32！CoInstall + 0x6ed

+ 0x6ed偏移量是一个重要的“质量”指标。它告诉你的是，返回地址是来自CoInstall的已知地址的1773个字节。那是相当多的。堆栈跟踪构建器只是没有任何其他已知的更接近的地址，因此它只能提供CoInstall作为猜测。一旦偏移超过0x100，代码实际上是已知函数的一部分的几率开始迅速减少。

跟踪中有很多条目具有巨大的偏移量。使整个痕迹质量相当低。编辑堆栈跟踪并仅留下高质量的线：

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

对于获取COM对象类工厂的跨公寓请求，这是一个非常标准的堆栈跟踪。为什么它失败是不可猜测的，你没有foxpro的调试符号，也没有记录HRESULT。

Answer 2

堆栈转储看起来似乎不合理。几乎肯定没用。
我建议编写一个未处理的异常处理程序并尝试再次崩溃。您的处理程序可以尝试执行更好的堆栈转储甚至是正确的故障转储见

处理程序将在您的代码中调用dll代码。

帮助一个非常奇怪的COM +调用堆栈

2 个答案: