Problème: le code .NET s'exécute depuis un répertoire, mais pas un autre, sur le même disque [fermé]

Question

Notre application est une application hybride Win32 hybride et une application gérée .NET 2.0. La partie Win32 est le principal exécutable qui, à un moment donné, charge et héberge le runtime .NET 2.0 et charge certains modules gérés pour ouvrir de nouvelles fenêtres Winforms.

Nous avons eu notre part de problèmes de type CASPOL, mais aujourd'hui, nous avons un problème très étrange et j'espère que quelqu'un pourra me donner des indications, des idées ou tout simplement quelque chose qui déclencherait une étincelle cela nous aiderait à résoudre ce problème.

Sur un serveur, accessible via Citrix, si les fichiers de l’application se trouvent dans un répertoire situé sur le bureau de l’utilisateur actuellement connecté, qui est un administrateur de serveur / domaine, le programme fonctionne correctement. Les fenêtres .NET s'ouvrent comme prévu.

Cependant, si nous déplaçons le répertoire à la racine du même disque, qui est un disque physique sur le serveur (donc, aucun mappage SAN ou autre élément susceptible de déclencher une commande CASPOL <à ma connaissance ) et que tout reste identique, le même utilisateur, la même configuration, etc. , l’application se bloque en silence lorsque nous essayons d’appeler les fenêtres .NET. Il se bloque en disparaissant, ce qui suggère que cela pourrait ressembler à un débordement de pile. Nous envisageons d’ajouter une journalisation à certaines parties de l’application pour peut-être comprendre ce qui se passe et où, mais je pose cette question ici aussi.

Jusqu'à présent, nous avons vérifié qu'il n'y avait aucune anomalie dans la liste d'accès de CASPOL, rien d'étrange dans le cache NGEN (je pensais qu'il y avait peut-être des images corrompues auparavant, si le propriétaire du serveur les avait utilisées), et non. bizarreries dans le GAC (nous n’utilisons pas le GAC pour les assemblées).

Résumé:

• Si le programme est exécuté à partir du répertoire U: \ Documents and Settings \ USERNAME \ Desktop \, cela fonctionne
• S'il est exécuté à partir du répertoire U: \, il ne le fait pas
• U: est un disque physique sur le serveur
• Aucune anomalie apparente dans les caches NGEN ou GAC
• Le bon runtime .NET est installé, les bons fichiers pour notre application ont été installés (et fonctionnent correctement si exécutés à partir du bureau)

Quelqu'un avec quelque chose qui pourrait aider?

Modifier: Problème redemandé ici avec des informations différentes / autres et" résolu ".

Answer 1

Mon premier essai serait d’exécuter le moniteur de processus à partir de MS-Sysinternals, et de regarder quels appels / résultats sont différents pour ces deux occasions. Peut-être que cela vous donnerait quelques pistes de travail (des résultats différents pour le même appel, des erreurs dans le bon fonctionnement qui ne sont pas dans le bon ...)

Vous pouvez télécharger le moniteur de processus à partir de MS: http://technet.microsoft.com/en-us/sysinternals/bb896645. aspx

Answer 2

J’avais précisément un problème de ce type il ya quelque temps. Après avoir tiré beaucoup de cheveux, j'ai trouvé le problème.

Faites très attention lorsque vous utilisez Process.Start () ou de tels appels, car, en fonction de la méthode de démarrage, il peut utiliser divers dossiers comme environnement de travail (chemin actuel, environnement système, etc.).

Answer 3

Ma première pensée est que vous devez vous assurer qu'aucun chemin relatif / absolu n'est défini dans le programme pour les références aux assemblys, fichiers, etc., ce qui pose problème lorsque vous déplacez le répertoire racine de l'application.

Answer 4

Est-il possible que cela soit lié aux privilèges de l'utilisateur? Exécutez-le à partir de LUA Buglight à vérifier. Même s'il n'est pas directement lié, cet outil peut donner des indications utiles.