J'ai installé plusieurs autres services Windows .Net personnalisés avec succès. Un nouveau que j'avais récemment écrit était très similaire aux autres et bien qu'il s'installe sans erreur - au démarrage avec le contrôleur de service, il n'a pas pu démarrer avec la boîte de dialogue d'erreur: Erreur système 2 ... le système ne peut pas trouver le fichier spécifié.
Après du temps et de la consternation, la seule chose à laquelle je pouvais penser qui était significativement différent à propos de ce service était que le chemin et le nom de l'exécutable étaient au moins 10 caractères plus longs que n'importe lequel de mes autres services. En raccourcissant le chemin d'accès et le nom .exe et en le réinstallant, le service s'est bien passé: pas d'erreur! Je peux seulement supposer que mon chemin d'accès ou service précédent ou le nom .exe était trop long.
En outre, il serait pertinent de mentionner que j'avais utilisé un code de "pilote de service" emprunté intégré à mon exe pour gérer l'installation/la désinstallation du service au contrôleur de service via des appels API Win. Il se peut qu'une limite de caractères ait été masquée dans ce module de pilote de service.
Je n'ai pas trouvé de documents liés à Windows pour confirmer s'il existe une limite de caractères liés au système à un chemin ou un nom de service que j'avais dépassé. Je vais creuser le pilote de service lorsque le temps le permet et voir si cela s'avère être le problème. En attendant, je salue toute idée.
J'ai expérimenté certains services de test et j'ai découvert que ce n'était pas la longueur d'une propriété qui a causé mon problème ("Erreur système 2 ... le système ne trouve pas le fichier spécifié"). Mon programme d'installation de service intégré utilise trois propriétés: ServiceName, ServiceTitle, ServiceDescription. Lors de l'installation, j'ai constaté qu'il écrit le chemin d'accès au service complet dans le registre, mais il ne prend pas seulement le nom exe (Assembly) réel, il utilise la propriété ServiceName pour créer le chemin! Mon problème était que le nom du service et le nom de l'assembly ne correspondaient pas, d'où le fichier introuvable. J'ai utilisé une requête de registre PowerShell pour exposer le chemin et j'ai finalement remarqué le décalage à partir de là. Lorsque j'ai remarqué le problème pour la première fois, je n'avais pas remarqué que lorsque j'ai raccourci le nom du service quel qu'il soit - que j'ai simplement utilisé le nom de l'assembly sans le .exe et c'est ce qui l'a réellement corrigé, pas simplement en le raccourcissant.
J'ai eu un problème similaire avec un service, où j'obtenais la même erreur.
Je suis allé à:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourServiceName\ImagePath
Mon "ImagePath" a été défini sur un lecteur virtuel appelé "W: \" qui existe sur "C: \".
J'ai remplacé ce chemin par l'emplacement réel du fichier sur le lecteur C: \, puis le service a démarré avec succès
Mon problème était que la création du service avec la commande Powershell a ajouté des supports tels que: <C:\Path\To\Service\Service.exe>
au registre.
Replacing < and > with " fixed it for me.
J'ai eu le même problème, rien n'a résolu cette erreur, puis j'ai résolu en pas en utilisant le c:\Windows\System32
chemin pour stocker l'exécutable du service!
Dans mon cas, j'ai ouvert l'invite de commande et navigué vers l'exe et l'ai installé à partir de là. Je n'ai donc pas entré le chemin complet. Une fois que j'ai utilisé le chemin complet, cela a fonctionné.
Ainsi, vous devez soit installer le service avec le chemin complet, soit ajouter le chemin du fichier exe au PATH dans les variables d'environnement système.
SC CREATE "Service-Name" binpath="D:\full-path-to-service\service.exe"
ou ajoutez D:\full-path-to-service\
à la variable PATH et utilisez
SC CREATE "Service-Name" binpath="service.exe"