2010-10-06 4 views
2

J'ai acheté une bibliothèque tierce que j'utilise depuis mon application. Mon application fait référence à une petite DLL interop qui à son tour appelle une autre DLL (non CLI) pour faire son truc. Puisque cette bibliothèque communique avec le matériel, je dirais que cette DLL parle avec différents pilotes de périphériques.C# - Récupération d'une exception à partir d'Interop

Une signature de la méthode typique de la dll Interop ressemble à ceci:

[MethodImpl(MethodImplOptions.InternalCall, MethodCodeType=MethodCodeType.Runtime), DispId(0xc9)] 
public virtual extern void Send([MarshalAs(UnmanagedType.Struct)] ref object pVal); 

J'ai tous les appels à cette bibliothèque enveloppée dans une grande prise d'essai (Exception). Si quelque chose ne va pas avec l'envoi, je dois marquer comme échoué et passer à autre chose. Malheureusement, ma demande se fermera au hasard sans exception. Y a-t-il quelque chose que je puisse faire à ce sujet? Ces appels sont déjà en cours sur un thread distinct en utilisant Task.Factory.StartNew(), mais l'application entière se ferme simplement. En plus d'une tentative try locale, il y en a une autre entourée par l'appel de StartNew (j'ai un appel à .Wait() juste à des fins de débogage). Cette prise ne tire pas non plus.

À l'heure actuelle, je pense que la seule solution consiste à créer un programme distinct qui attend simplement que l'autre le ferme et le rouvre ensuite. Ce qui sonne horrible ...

+0

Envelopper le StartNew() avec un try-catch n'attrapera pas une exception qui se produit sur le thread. Pouvez-vous montrer le try-catch "local"? –

+0

Mais l'appel à .wait devrait. Droite? – colithium

+0

Le code autour de l'appel est juste un essai {...} catch (Exception) {...} – colithium

Répondre

0

Jetez un coup d'oeil à ce blog vous pourriez être en mesure d'obtenir un rapport d'accident et au moins voir quel appel échoue et le signaler à votre développeur tiers.

+0

Un article en particulier? Je ne reçois même pas un message de Windows que mon programme a cessé de répondre/a planté. Il s'en va tout seul en silence. Ce qui me fait penser que la DLL détecte une erreur et quitte le processus au lieu de suivre la route normale. – colithium

+0

Elle a changé son blog mais il y avait un guide sur la façon d'obtenir un vidage sur incident et ensuite l'analyser en utilisant windbg – rerun

Questions connexes