web-dev-qa-db-fra.com

Programme et débogueur quitter sans indication de problème

OK, pas tout à fait un Heisenbug mais de nature similaire.

Je développe une application WPF. Lors du débogage, la logique atteint un certain point, puis l'application se ferme sans raison. Le débogueur VS n'attrape rien et la seule indication d'un problème est la suivante dans la fenêtre de sortie:

Le programme '[6228] SomeApp.vshost.exe: Managed (v4.0.30319)' s'est terminé avec le code 1073741855 (0x4000001f).

Lorsque vous déboguez la version finale, ou que vous exécutez la version de débogage à partir du débogueur (en fait, tous les combos qui n'exécutent pas la version de débogage dans le débogueur), tout fonctionne correctement. 

J'essaie d'attraper les exceptions non gérées avec le code suivant:

        AppDomain
            .CurrentDomain
            .UnhandledException +=
            (sender, e) =>
            {
                Debug.WriteLine("Unhandled Exception " + e.ExceptionObject);
            };
        Application
            .Current
            .DispatcherUnhandledException +=
            (sender1, e1) =>
            {
                Debug.WriteLine("DispatcherUnhandledException " + e1.Exception);
            };

... mais je n'attrape rien.

J'envisage de bricoler l'application avec des instructions de sortie de débogage, mais elle est hautement asynchrone, donc lire ceci sera à la fois difficile et fastidieux. 

Alors dis-moi, si tu peux ... comment puis-je commencer à comprendre que la WTF se déroule?

c#.netvisual-studiodebuggingheisenbug
23
spender

Selon le fichier ntstatus.h, 0x4000001f (STATUS_WX86_BREAKPOINT) est un code d'état d'exception utilisé par le sous-système d'émulation Win32 x86. Cela (je suppose) signifie que vous avez atteint un point d'arrêt qui n'est pas exploitable. Vous devez activer le débogage du code non géré.

31
Vladimir

À l'aide de Visual Studio 2012 (version 11.0.50727.1 RTMREL), la seule solution que j'ai trouvée était d'aller dans Projet -> Propriétés -> Déboguer et désactiver "Activer le processus d'hébergement Visual Studio".

L'option "Activer le débogage de code natif" n'a pas aidé même si toutes les exceptions étaient définies sur break-when-levées.

Fait intéressant, ce problème n'a commencé à se produire que lorsque j'ai mis à niveau la version bêta de VS2012 vers la version officielle VS2012. 

13
Ron

J'ai la même situation avec Visual Studio 2013. Comme Ron Cette sauvegarde ma journée: Projet -> Propriétés -> Déboguer et désactiver "Activer le processus d'hébergement Visual Studio".

Merci

6
PachecoDt

Le redémarrage a résolu le problème pour moi. 

J'ai rencontré le problème qui tentait de déboguer via NUnit via le lanceur de tests de Resharper et d'essayer de suivre séparément un processus W3WP.exe.

1
Peter Seale

J'avais le même comportement avec FonstSize = "auto" (je ne sais pas pourquoi):

<TextBlock Text="{Binding DisplayText}" FontSize="auto"/>

Correction: <TextBlock Text="{Binding DisplayText}" />

Sortie d'erreur supplémentaire:

LS stop assert - tserrInternalError, fichier F:\dd\wpf\src\native\ums\shared\inci\tsoverflow.h, ligne 66 

Une exception non gérée du type 'System.Exception' s'est produite dans PresentationCore.dll Informations complémentaires: Vom Textformatierungsmodul kann aufgrund des fichiers de texte au format texte: "LsInternalError".

0
FrankM

Je rencontrais le même problème. dans mon cas, j'ai remarqué que j'avais une propriété avec getter et setters. Mon erreur a été de retourner la propriété elle-même au lieu de l'attribut qui lui est lié, ce qui a forcé le débogueur à passer à une boucle infinie, après avoir résolu le problème, le problème a été résolu. Je recevais le même code d'erreur sans info supplémentaire- 

0
Siamak Rahimi