2010-12-16 3 views
0

Je développe une application dans LabView sous Windows. Il y a une semaine, une machine de test (un ToughBook, pas moins) gèlait complètement tous les deux jours: pas de curseur de souris, l'horloge de la barre des tâches était gelée. Donc, hier, il était à la retraite. Mais maintenant, je l'ai vu sur une autre machine, également un ordinateur portable.Le curseur de la souris se fige dans Windows LabView

Il s'agit d'un mode de défaillance assez rare pour les PC. Je ne connais pas grand chose à propos de Windows, mais je m'attendrais à ce que cela indique que le logiciel a cessé de tourner aussi complètement et soudainement que le noyau n'a pas pu paniquer.

Est-ce une évaluation précise? Où puis-je commencer à déboguer ce problème? Qu'est-ce qui contrôle le curseur dans l'architecture de Windows - est-ce tout le mode noyau ou y a-t-il un serveur de fenêtre qui pourrait être étranglé par quelque chose? Un pilote matériel tiers instable provoquerait-il cela, plutôt qu'un écran bleu?

EDIT: Je devrais ajouter que les gels ne se produisent pas nécessairement pendant que le code est en cours d'exécution.

+2

woohoo une question de labview! Eh bien ... au moins, il y est écrit "LabVIEW". Sérieusement, je pense que serverfault ou superutilisateur pourrait être un meilleur forum pour cela. – SiegeX

+0

@Siege: Peut-être ... En fait, j'ai posé une autre question liée à LabView il y a quelques heures mais je ne l'ai pas taguée en tant que telle. Quoi qu'il en soit, j'espère que le côté architectural de cette question recevra une réponse avant d'être déplacé sur l'autre site. – Potatoswatter

Répondre

2

Je considérerais certainement le matériel et/ou les pilotes comme une possibilité - peut-être pourriez-vous dire de quel matériel il s'agit?

Vous pouvez tester cela en ajoutant un «mode de débogage» pour chaque composant matériel auquel votre code LabVIEW s'adresse, où vous utiliseriez, par ex. une structure de cas pour ignorer les appels d'E/S réels et renvoyer des données factices au reste de l'application. Assurez-vous qu'il s'agit d'une quantité de données similaire à celle du périphérique réel. Vous trouverez cela beaucoup plus facile si vous avez modularisé votre code en sous-VI avec des fonctions clairement définies! Si la désactivation des appels d'E/S sur un matériel particulier bloque le gel, cela pourrait indiquer que le problème provient de ce matériel ou de son pilote.

+0

C'est une bonne idée. Malheureusement, le code n'est pas si bien factorisé. Le dongle de communication MCU est une partie de NI et devrait être bien qualifié, mais je suppose que c'est un suspect. Aussi comme je viens de le noter ci-dessus, les plantages ne sont pas nécessairement pendant que n'importe quel VI est en cours d'exécution. – Potatoswatter

1

Difficile de dire quel est le problème. Sur la base des symptômes, je vérifierais s'il y a une fuite de mémoire possible (voir si votre utilisation de la mémoire de l'application LabVIEW augmente au fil du temps en utilisant "Windows Task Manager").

+0

Aucune fuite de mémoire. Nous vérifions cela régulièrement. De plus, les machines ne ralentissaient pas avant de s'arrêter. – Potatoswatter

Questions connexes