Tengo un problema donde nuestra aplicación se cuelga en las máquinas de nuestros clientes que he estado usando durante días sin resolver. El problema surge bastante al azar de lo que hemos visto, aunque ese no sea el verdadero caso. El cliente también informa que la CPU está alcanzando su máximo cuando la aplicación se cuelga.Cuelgue la aplicación COM con el complemento C#
El problema es que no tengo idea de dónde está fallando la aplicación (suspensión). También tenemos un par de complementos escritos en C# como complementos para la aplicación COM principal.
He logrado que el cliente lleve una MiniDump con ProcExp en una máquina donde ocurrió el problema. Sin embargo, tampoco estoy muy familiarizado con WinDBG o MiniDumps para el caso. He ejecutado !analyze -v y !analyze -v -hang, que produce algunos resultados, incluida la pila a continuación. Por lo que puedo decir, parece que la aplicación está en transición a uno de nuestros complementos de C# (CLR) y luego de nuevo a COM, que debería ser una interfaz de regreso a la aplicación principal que está disponible para los complementos. ¿Pero entonces, qué? ¿Es posible decir algo más de esta pila?
La aplicación principal está escrita en VB6 si eso es importante.
0012da70 7e3693e9 7e3693a8 0012daf0 00000000 ntdll!KiFastSystemCallRet
0012da9c 7e37a43b 0012daf0 00000000 0000000f user32!NtUserPeekMessage+0xc
0012dac8 7348e6fd 0012daf0 00000000 0000000f user32!PeekMessageA+0xeb
0012db1c 77532a9c 00d03774 00000000 00000000 msvbvm60!CMsgFilter::MessagePending+0x21f
0012db60 77532a48 00000102 0012dbec 00000001 ole32!CCliModalLoop::HandlePendingMessage+0x40
0012dba8 7751eda6 80010116 80010115 00000000 ole32!CCliModalLoop::HandleWakeForMsg+0x46
0012dbbc 77547297 0012ddf0 00000001 0012dbe8 ole32!CCliModalLoop::BlockFn+0x8b
0012dc30 0ae8a2fd 00000002 00000001 00000001 ole32!CoWaitForMultipleHandles+0xcf
0012dc50 0ae8a264 00000000 00000001 00000001 mscorwks!NT5WaitRoutine+0x51
0012dcbc 0ae8a1c8 00000001 0012ddf0 00000000 mscorwks!MsgWaitHelper+0xa5
0012dcdc 0af3ccd0 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateAptStateWait+0x28
0012dd60 0af3cd65 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
0012ddb0 0ae8c026 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateWait+0x40
0012de00 0ae90f4c 00000001 05ae5c80 0012de60 mscorwks!Thread::JoinEx+0x86
0012de10 0b00ea40 00000001 00000001 5bdf0a2d mscorwks!Thread::Join+0x14
0012de60 0af0b9a7 00000001 0012deb0 0af0ba10 mscorwks!RCWCleanupList::CleanupWrappersInCurrentCtxThread+0x15a
0012de6c 0af0ba10 001df674 0012df10 5bdf0afd mscorwks!RCW::Initialize+0x78
0012deb0 0af0b6a7 001df674 0012df10 5bdf0b6d mscorwks!RCW::CreateRCW+0x84
0012df20 0af0b7b5 00000000 0012df5c 5bdf0b21 mscorwks!COMInterfaceMarshaler::CreateObjectRef+0x45
0012df6c 0ae892a8 5bdf3065 0012e6c8 0012e6c8 mscorwks!COMInterfaceMarshaler::FindOrCreateObjectRef+0xac
0012e428 0ae89444 001df658 11a11014 00000001 mscorwks!GetObjectRefFromComIP+0x1ec
0012e448 0ae894ab 05b3b0a8 001df658 0e896204 mscorwks!UnmarshalObjectFromInterface+0x19
0012e464 0af164d1 0012e6c8 0012e6ac 0af164c1 mscorwks!InterfaceMarshalerBase::ConvertSpaceNativeToCLR+0x30
0012e470 0af164c1 0012e748 0012e738 5bdf32e1 mscorwks!DefaultMarshalOverrides<InterfaceMarshalerBase>::ReturnCLRFromNativeRetval+0xb
0012e6ac 0aeb4bff 11741a76 0012e734 0012e74c mscorwks!RunML+0x9ac
0012e780 11740172 05ae5c80 0012e7d4 501b6046 mscorwks!CLRToCOMWorker+0x25f
...
... Stack begins down here in our main COM application.
Edición 1: Algunos pensamientos que tengo después de leer algunos otros mensajes en el foro. Me parece que el bloqueo se introduce siguiendo una clasificación de los tipos de datos de .NET a COM. Ahora que he leído sobre another problem que parecía originarse en el hecho de que las variables locales pasaban a un método COM eran basura recolectada y, por lo tanto, el tiempo de ejecución de VB6 tenía problemas para tratar con la memoria desasignada. Esa otra publicación no era exactamente este problema, pero me hizo pensar.
En el código .NET poner en COM que tienen este tipo de código
void SomeNETMethod(MyObject obj, bool doIt) {
string someString = obj.SomeString;
this.myComComponent.DoItInCOM(ref someString, ref doIt); // This is where it hangs.
}
Podría la ref bool así como la directa de método a método que se pasa el parámetro tiene nada que ver con nada? Como puede ver, estoy tropezando en la oscuridad aquí ...
VB6 y las roscas son agua y fuego. Parece un punto muerto cuando el hilo principal VB6 deja de bombear el bucle de mensajes. Necesita el depurador VB6 para averiguar qué está haciendo. –
@HansPassant ¿podrían ocurrir estos problemas a pesar de que nuestros complementos de C# no tienen múltiples subprocesos? El único "otro" hilo que puedo ver aquí es el hilo del GC, pero supongo que ese no es el problema. – lbergnehr
¿Hay algún DoEvents en alguna parte del código VB6 al que se llame? Como señala @HansPassant, el hilo principal VB6 puede no ser realmente compatible con el hilo C# (especialmente si tiene alguna interacción WinForms o WPF) y un montón de magia se realiza detrás del escenario en el código de interoperabilidad para unir los hilos.He encontrado en el pasado que cualquier DoEvents llamado desde una aplicación VB6 que se llama desde DotNet eventualmente conducirá a algún tipo de bloqueo/bloqueo. –