Help with a really strange COM+ callstack

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!DllUnregisterS开发者_StackOverflowerver + 0xc6c
COMSVCS!DllUnregisterServer + 0xf4d
msvcrt!_endthreadex + 0xa3
kernel32!GetModuleHandleA + 0xdf

---

ole32!CoInstall + 0x6ed

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:

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

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.

---

1. That stack dump does not appear to be plausible. It is almost certainly not useful.

2. 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

   • http://msdn.microsoft.com/en-us/library/windows/desktop/ms680634.aspx
   • http://www.microsoft.com/msj/0197/Exception/Exception.aspx
   • http://msdn.microsoft.com/en-us/library/windows/desktop/ms680360.aspx

The handler would be in your code that calls the dll code.