我们有一个旧的COM应用程序调用的旧版COM + dll。它定期崩溃，并且调用堆栈看起来很奇怪
似乎在调用堆栈中出现了对DllUnregisterServer和CoInstall的调用(我们不会在代码中动态安装/卸载任何内容，它只是在查询数据库)。
我想知道是否有可能MSI“文件保护”启动并导致崩溃。您认为有可能吗？有什么办法可以获取更多信息？ (这是一个旧的VFP应用程序，因此我认为我无法获得适当的调试符号)
这是调用堆栈:Call Stack:vfp9t! + 0x2272fvfp9t!VFPDllGetClassObject + 0xb6ctcvccomasyncproxy!DllGetClassObject + 0x3eole32!CoInitializeSecurity + 0x5ff5ole32!CoInitializeSecurity + 0x5bdcole32!CoGetTreatAsClass + 0x2a2ole32!CoInitializeSecurity + 0x3a2bCOMSVCS!DispManGetContext + 0xbc07ole32!CoInitializeSecurity + 0x3a2bole32!CoInstall + 0x6edole32!CoQueryAuthenticationServices + 0x21aaole32!CoQueryAuthenticationServices + 0x2c56ole32!CoGetContextToken + 0xd48dole32!CreateStreamOnHGlobal + 0x1b7cole32!CoCreateObjectInContext + 0xd9fole32!CoInstall + 0x903ole32!CoGetContextToken + 0x12f5bRPCRT4!NdrServerInitialize + 0x1fcRPCRT4!NdrStubCall2 + 0x217RPCRT4!CStdStubBuffer_Invoke + 0x82ole32!StgGetIFillLockBytesOnFile + 0x13b27ole32!StgGetIFillLockBytesOnFile + 0x13ad4ole32!DcomChannelSetHResult + 0xaabole32!DcomChannelSetHResult + 0x495ole32!CoFreeUnusedLibrariesEx + 0xb06ole32!StgGetIFillLockBytesOnFile + 0x139e1ole32!StgGetIFillLockBytesOnFile + 0x13872ole32!StgGetIFillLockBytesOnFile + 0x12d59ole32!CoFreeUnusedLibrariesEx + 0x9f5ole32!CoFreeUnusedLibrariesEx + 0x9c0USER32!LoadCursorW + 0x4cf5USER32!LoadCursorW + 0x4e86USER32!TranslateMessageEx + 0x10dUSER32!DispatchMessageW + 0xfCOMSVCS!DllUnregisterServer + 0x270COMSVCS!DllUnregisterServer + 0x180COMSVCS!DllUnregisterServer + 0xc6cCOMSVCS!DllUnregisterServer + 0xf4dmsvcrt!_endthreadex + 0xa3kernel32!GetModuleHandleA + 0xdf
最佳答案
+ 0x6偏移是重要的“质量”指标。它告诉您的是，返回地址距离CoInstall的已知地址还有1773个字节。相当多。堆栈跟踪构建器只是没有其他更接近的已知地址，因此只能提供CoInstall作为猜测。一旦偏移量超过0x100，则代码实际上是所指示的已知函数的一部分的几率开始迅速下降。
跟踪中有很多条目具有很大的偏移量。使整个跟踪质量相当低。编辑堆栈跟踪并仅保留高质量的行:
vfp9t!VFPDllGetClassObject + 0xb6
ctcvccomasyncproxy!DllGetClassObject + 0x3e
...
RPCRT4!CStdStubBuffer_Invoke + 0x82
...
USER32!DispatchMessageW + 0xf
这是跨部门请求以获得COM对象类工厂的相当标准的堆栈跟踪。失败的原因是不可猜测的，您没有foxpro的调试符号，也没有记录HRESULT。