J'essaie de construire un service Windows avec Mingw. Il a besoin d'exceptions sûres de fil, donc j'ai ajouté le drapeau de la liaison -mthreads . L'application fonctionne bien de la ligne de commande, mais lorsque j'essaie de la démarrer de services.msc , l'erreur 1054 ("Le service n'a pas répondu à la demande de démarrage ou de contrôle en temps opportun" ) est soulevé. Le service commence si je le construisez-le sans le drapeau -mthreads . Comment puis-je obtenir ce travail avec -mthreads ?
4 Réponses :
Je me demande si vous pouvez le déboguer quand il fonctionne comme service. Il doit y avoir quelque chose d'éponger votre programme lorsque l'hôte de service l'exécute. Peut-être essayer d'attacher un débogueur à svchost.exe, au moins vous pouvez voir quels modules sont chargés et peut-être quelle exception provoque l'accident.
Joindre un débogueur à Svchost.exe n'a pas aidé. Le service n'a pas la chance de commencer. L'erreur est lancée même avant cela.
Votre application est-elle même en train de commencer du tout? Mettez un appel à S'il ne comprend pas cela loin, nous commençons à vérifier l'évidence: est-ce une question de l'application qui ne trouve pas la DLL d'exécution? Il se pourrait que vous ayez le temps d'exécution régulier sur son chemin, mais il ne peut pas trouver la version MT. Cela pourrait expliquer le comportement que vous décrivez. Vous devrez peut-être avoir besoin de copier le temps d'exécution MT ou de mettre à jour le chemin en conséquence. de sortieDebugstring (ou équivalent) au début de votre fonction principale pour voir si elle obtient même cela aussi loin. (Grab dbgview de Sysinternals si vous ne l'avez pas déjà.)
L'application ne commence même pas. Mais il fonctionne de la ligne de commande. Donc, il ne peut pas être le problème avec les bibliothèques d'exécution.
Où est la version MT des bibliothèques d'exécution? Il devrait figurer dans le répertoire des applications. Peut-être que les bibliothèques d'exécution sont disponibles sur le chemin lors de l'exécution de votre utilisateur, mais pas comme le système. Utilisez DEPEND.EXE à suivre dans quelle dll vous dépendez-vous. Vous pouvez également essayer d'exécuter l'application comme un autre utilisateur.
Je soupçonne -mthreads apporte une dépendance sur une DLL et que la DLL n'est pas sur le chemin lorsqu'elle fonctionne comme service. Dans mon environnement Cygwin, si je compile un programme trivial avec "-Mno-cygwin -mthreads", je reçois une dépendance sur Mingwm10.dll, ce qui ne serait certainement pas sur le chemin lors de la course en tant que service. Si j'essaie de l'exécuter sans chemin de chemin, il se bloque car il commence à charger (et laisse une merde dans le journal des événements d'application).
Je fermerais votre EXE dans une dépendance Walker ( http://www.dependencywalker.com ) Pour voir ce que vous chargez à temps de chargement et vérifiez votre journal des événements Windows pour voir s'il y a des indices là-bas. Vous aurez probablement besoin de mettre une copie des DLL dont il a besoin à côté de l'exécutable.
Vous avez besoin de mingwm10.dll dans le répertoire de travail ou dans [Modifier: Système, pas par utilisateur], car les programmes C ++ compilés avec l'option -Mthread ont cette dépendance. Si vous êtes presque sûr que votre code ne sera jamais projeté par votre code ni de votre pile, utilisez -fno-excepte au lieu de -mthread pour résoudre la dépendance.