帮助解决一个非常奇怪的 COM+调用栈
我们有一个由旧 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
We have a legacy COM+ dll that is called by an old ASP application. It is periodically crashing, and the call stack is very strange looking
It appears that a call to DllUnregisterServer and to CoInstall appear within the call stack (we don't dynamically install/uninstall anything within the code -- it's just querying a database).
I am wondering if it is possible that MSI "file protection" is kicking in and causing the crash. Do you think that's possible? any way I can dig up more information? (it's an old VFP applicaiton, so I don't think I can get proper debug symbols)
Here's the call stack:
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
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
+0x6ed 偏移量是一个重要的“质量”指标。它告诉您返回地址距离 CoInstall 的已知地址有 1773 个字节。这是相当多的。堆栈跟踪生成器只是没有任何其他更接近的已知地址，因此它只能提供 CoInstall 作为猜测。一旦偏移量超过 0x100，代码实际上是指示的已知函数的一部分的可能性开始迅速减少。
跟踪中有很多条目具有巨大的偏移量。使整个轨迹的质量相当低。编辑堆栈跟踪并仅保留高质量的行：
对于获取 COM 对象类工厂的跨单元请求来说，这是一个相当标准的堆栈跟踪。为什么失败是无法猜测的，您没有 Foxpro 的调试符号，也没有记录 HRESULT。
The +0x6ed offset is an important 'quality' indicator. What it tells you is that the return address is 1773 bytes from the known address of CoInstall. That's rather a lot. The stack trace builder just didn't have any other known address that was closer so it could only offer CoInstall as a guess. Once the offset goes beyond 0x100, the odds that the code is actually part of the indicated known function start to dwindle rapidly.
There are a lot of entries in the trace that have huge offsets. Making the entire trace rather low quality. Editing the stack trace and leaving only good quality lines in place:
Which is a pretty standard stack trace for a cross-apartment request to get a COM object class factory. Why it failed is not guessable, you don't have debug symbols for foxpro and didn't document the HRESULT.
该堆栈转储似乎不合理。几乎可以肯定它没有用。
我建议编写一个未处理的异常处理程序并尝试让它再次崩溃。您的处理程序可以尝试执行更好的堆栈转储甚至正确的故障转储。
参见
处理程序将位于调用 dll 代码的代码中。
That stack dump does not appear to be plausible. It is almost certainly not useful.
I suggest writing an unhandled exception handler and trying to get it to crash again. Your handler can try to do a better stack dump or even a proper crash dump.
See
The handler would be in your code that calls the dll code.