eccezione COM su “componente personalizzato” - come identificare DLL?

Question

Abbiamo una grande applicazione legacy VB costituito da un certo numero di DLL (un paio di dozzine o giù di lì), tutti installati in un'unica COM + Application Server. Di tanto in tanto, qualcosa accade che le cause Dllhost.exe a crollare (e riavvia automaticamente), lasciando questo messaggio nel registro eventi applicazioni di Windows ...

  

Il sistema ha richiamato un componente personalizzato e tale componente è   fallito e ha generato un'eccezione. Questo indica un problema con la   componente personalizzato. Notifica l'autore di questa componente che ha un fallimento   verificato e fornire loro le informazioni qui di seguito.
  ID applicazione server: {8CC02F18-2733-4A17-9E5C-1A70CB6B6977}
  Application Server ID istanza: {1940A147-8A5E-45FA-86FE-DAF92A822597}
  Nome applicazione server: MyTestApp
  La natura grave di questo errore ha causato il terminazione del processo.
  Eccezione: C0000005
  Indirizzo: 0x758DA3DA

     

Fonte: Complus
  ID evento: 4786
  Livello: errore

Lungo il lato questo è un altro registro, in particolare su dllhost.exe ...

  

ha provocato l'errore nome dell'applicazione: dllhost.exe, Versione: 6.0.6000.16386, timestamp: 0x4549b14e
  Faulting nome del modulo: Msvcrt.dll, Versione: 7.0.6002.18005, timestamp: 0x49e0379e
  codice di eccezione: 0xc0000005
  Guasto offset: 0x0000a3da
  Faulting id processo: 0x83c
  Errore applicazione ora di inizio: 0x01cb50c507ee0166
  Faulting percorso di applicazione:% 11
  Faulting percorso modulo:% 12
  Relazione Id:% 13

Lo so che sta segnalando un guasto nel runtime C (MSVCRT), ma idealmente ho bisogno di rintracciare questo ritorno nella DLL che si chiama in msvcrt (probabilmente con dati non corretti / parametri). Quindi, senza l'installazione di un debugger, c'è qualche modo per identificare la DLL che causa questo? Sto cercando di vedere se c'è un dump di memoria da nessuna parte che posso utilizzare per analizzare offline - e quindi legare l'Indirizzo per qualcosa di specifico. Ma senza che, io non sono sicuro che sia possibile. Può il COM sottosistema essere detto per generare un minidump quando un'applicazione ospitata crash (sì, può [probabilmente] - c'è una casella di controllo sulla scheda 'Dump')?.

Questo è su Windows Server 2008 R1 a 32 bit (ma anche essere interessati a Server 2003 come pure).

Non influisce la disponibilità della app -. Com + semplicemente riavvia dllhost e l'applicazione continua, ma è un inconvienience che sarebbe utile per risolvere

windbg Modifica Va bene, ho un crash dump, ho, ma è non aiuta. Non sono sicuro se devo essere di spessore (una possibilità) o qualcos'altro :-) uscita di !analyze -v è al di sotto, ma non mi sta mostrando qualche cosa nelle nostre DLL, anche se sembra che non è stato in grado di risolvere FAULTING_IP? Io non sono sicuro dove girare successiva.

Mi chiedo se qualcuno dei miei di PDB sono dubbia e essere quelli nuovi di generazione del valore - agganciato in server di simboli di Microsoft, in modo che non dovrebbe essere, ma non è sicuro di quale modulo è di (apparentemente) di segnalazione simboli sbagliati per ( BUGCHECK_STR e PRIMARY_PROBLEM_CLASS) (o sono questi simboli sul server il codice è stato originariamente eseguito su?). Sarebbe meglio mettere i PDBs sul server stesso?

In caso contrario, altre idee? Ho usato brevemente windbg prima, ma io non sono un utente regolare di esso, quindi forse c'è qualche altro incantesimi ho bisogno di digitare per scavare più a fondo? Guidance benvenuto: -)

*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

FAULTING_IP: 
+5c112faf02e0d82c
00000000 ??              ???

EXCEPTION_RECORD:  ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00000000
   ExceptionCode: 80000003 (Break instruction exception)
  ExceptionFlags: 00000000
NumberParameters: 0

FAULTING_THREAD:  00000f1c
DEFAULT_BUCKET_ID:  WRONG_SYMBOLS
PROCESS_NAME:  dllhost.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION}  Breakpoint  A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
MOD_LIST: <ANALYSIS/>
NTGLOBALFLAG:  0
APPLICATION_VERIFIER_FLAGS:  0
MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0xf1c (0)
Current frame: 
ChildEBP RetAddr  Caller,Callee

LAST_CONTROL_TRANSFER:  from 77b15620 to 77b15e74
PRIMARY_PROBLEM_CLASS:  WRONG_SYMBOLS
BUGCHECK_STR:  APPLICATION_FAULT_WRONG_SYMBOLS

STACK_TEXT:  
0022fa68 77b15620 77429884 00000064 00000000 ntdll!KiFastSystemCallRet
0022fa6c 77429884 00000064 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
0022fadc 774297f2 00000064 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xbe
0022faf0 778e2c44 00000064 ffffffff 00e42374 kernel32!WaitForSingleObject+0x12
0022fb0c 778e2e32 00060848 0022fb5b 00000000 ole32!CSurrogateProcessActivator::WaitForSurrogateTimeout+0x55
0022fb24 00e413a4 0022fb40 00000000 00061d98 ole32!CoRegisterSurrogateEx+0x1e9
0022fcb0 00e41570 00e40000 00000000 00061d98 dllhost!WinMain+0xf2
0022fd40 7742d0e9 7ffde000 0022fd8c 77af19bb dllhost!_initterm_e+0x1a1
0022fd4c 77af19bb 7ffde000 dc2ccd29 00000000 kernel32!BaseThreadInitThunk+0xe
0022fd8c 77af198e 00e416e6 7ffde000 ffffffff ntdll!__RtlUserThreadStart+0x23
0022fda4 00000000 00e416e6 7ffde000 00000000 ntdll!_RtlUserThreadStart+0x1b

STACK_COMMAND:  .cxr 00000000 ; kb ; dt ntdll!LdrpLastDllInitializer BaseDllName ; dt ntdll!LdrpFailureData ; ~0s; .ecxr ; kb

FOLLOWUP_IP: 
dllhost!WinMain+f2
00e413a4 ff15a410e400    call    dword ptr [dllhost!_imp__CoUninitialize (00e410a4)]

SYMBOL_STACK_INDEX:  6
SYMBOL_NAME:  dllhost!WinMain+f2
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: dllhost
IMAGE_NAME:  dllhost.exe
DEBUG_FLR_IMAGE_TIMESTAMP:  4549b14e
FAILURE_BUCKET_ID:  WRONG_SYMBOLS_80000003_dllhost.exe!WinMain
BUCKET_ID:  APPLICATION_FAULT_WRONG_SYMBOLS_dllhost!WinMain+f2

Answer 1

Hai simboli per le DLL VB? I simboli sono importanti per ottenere il call-stack. Spero che tu abbia simboli corretti. È possibile utilizzare ld * e poi lme che dovrebbe farti elenco di simboli che non corrispondono all'interno windbg. Anche impostare il percorso di simboli per i simboli MS e così come per il codice personalizzato utilizzando _NT_SYMBOL_PATH

Uno dei l'opzione più semplice è quella di caricare il dump all'interno di DebugDiag che dovrebbe dare ragione del fallimento con call-stack. DebugDiag ha le estensioni del debugger per Complus.

E qui è un comando per stack di chiamate nativo per tutti i fili

~*ek

e questo interruttore per l'eccezione corrente

.ecxr

Answer 2

Debug Mon / WinDbg è il modo migliore per risolvere questo problema. si dovrebbe essere in grado di utilizzare l'elenco dei moduli in WinDbg, o il comando lm per elencare i moduli caricati. L'analisi dello stack dovrebbe allora dire che le DLL sono coinvolti. Questo dovrebbe essere possibile anche senza i simboli per il processo / dll.