6
votes

Application en cours d'exécution sous test sort peu après que je joins avec VS2010 SP1 en X86

sur Windows 7 x64, lorsque je joins en mode X86 à une application libre-exécution assez complexe, il fonctionne pendant un certain temps, puis se ferme sur une reproduction.

MyApp.vshost.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).


6 commentaires

Vous trouverez peut-être plus d'informations dans votre visionneuse d'événements OS?


@Jason Williams: rien dans l'observateur d'événements. Bon essai


Tout accès sur les chemins UNC ou sur des emplacements protégés dans le code? Est-ce que fonctionnant comme un utilisateur privilégié annule le problème?


@Mike Miller: Exécution sur une boîte de devir, privilèges complets, accès local uniquement. Du code d'erreur, on dirait que quelque chose se dérobe ma pile. Prolly Bad P / invoquer quelque part.


Bonne chance et veuillez mettre à jour les résultats car je suis maintenant plus intéressé que lorsque le videur avait son propre épisode de voisins (rêve des videurs) - qui ont bercé.


Je suis capable d'inspecter l'État en prenant un processus de fonctionnement qui a appuyé sur une affirmation, puis ouvrant la mémoire de mémoire complète dans Visual Studio 2010 SP1. Je ne peux toujours pas continuer d'un point d'arrêt ou d'une affirmation.


3 Réponses :


1
votes

La signature interop est-elle correcte? essayez d'utiliser http://clrinterop.codeplex.com/relases/view/14120 pour générer et essayez à nouveau.


2 commentaires

Ai-je mentionné que ceci est une application très complexe? Nous avons 185 déclarations Dllimport.


Hier, je retiens les couches de mon application pour voir quelle composante l'a causée. J'ai découvert que la question ne figure pas avec p / invoke Signature, mais plutôt dans un module précompilé écrit dans géré C ++, ciblant .NET 4.0. Lorsque vous appelez dans Géré C ++, il n'y a pas de p / invoke requis. Ça marche juste. Ou pas, dans mon cas



4
votes

à partir du fichier d'en-tête SDK NTStatus.h Windows SDK NTStatus:

//
// MessageId: STATUS_STACK_BUFFER_OVERRUN
//
// MessageText:
//
// The system detected an overrun of a stack-based buffer in this application. This overrun 
// could potentially allow a malicious user to gain control of this application.
//
#define STATUS_STACK_BUFFER_OVERRUN      ((NTSTATUS)0xC0000409L)    // winnt


2 commentaires

Le comportement semble différent sur différentes plates-formes. Je vois gscookie sur le serveur 2008 R2 X64, mais aucun message de ce type sur Windows 7 x64.


J'ai accepté cette réponse car elle a déclaré que le code C / C ++ est le coupable probable, et c'est en fait, dans mon cas.



1
votes

On dirait que je devrais pouvoir le réduire en injectant des appels GC.Collect () dans mon code: la collection de déchets vérifie entre autres choses.

Carrisé Link1: http: // 7388. Info / Index.php / Article / Studio / 2010-10-17 / 354.html

brisé link2: http: // www.pubsub.com/investigating-a-gscookie-corruption_windows-net-troubleShooting-pinvoke-5wbehu80dzfrz5u5Davjae


6 commentaires

Je fonctionne actuellement avec Jinx et Impossible de forcer le chemin de code à échouer. Je suis toujours incapable de joindre à une application libre, car elle sort immédiatement.


En rétrospectivement, je pense que c'est l'une des bibliothèques non gérées que nous comptions. Une fois que cela est compilé, plus de problème.


Le lien 7388.info/index.php/article/ Studio / 2010-10-17 / 354.html Dans ce message produit actuellement un site temporairement indisponible Message P3NLHCLUST404.SHR.PROD.PHX3.SECURESERVER.NET/SharedContent/.../a>


@StevemyLroie J'ai regardé la machine à retour. Rien dans les archives.


Malgré ces deux liens étant maintenant cassés, ce commentaire m'a aidé à trouver un problème similaire (en effet avec un appel P / invoke). Je l'ai reçu chaque fois qu'une exception a été lancée, mais obligeant GC a permis d'identifier le bogue actuel. +1


Désolé pour les liens, content que cela ait aidé. Contrairement à l'univers, Internet se rétrécit