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.