Hi, ich habe Windows 8.1 und mir einen Windows Service programmieren lassen. Dieser Service lädt von meiner Webseite alle 30 Sekunden einen Messwert. Wenn ich Ihn per doppelklick starte, öffnet sich ein dos-Fenster und ich sehe, wie die Daten heruntergeladen werden. Wenn ich nun diesen wieder schließe, per cmd in den entsprechenden Ordner wechsle und dort den Namen des Service gefolgt von install eingebe, so kann ich diesen dann im "Services" Fenster sehen und neustarten. Leider lädt er aber keine Daten herunter, sondern gibt nur folgende Zeile aus: 2015-10-30 15:44:55 No data. 2015-10-30 15:44:59 Failed to get value Unable to connect to the remote server 2015-10-30 15:44:59 No data. The Data-Files are empty. Beim Entwickler habe ich nachgefragt warum und weshalb das so sein kann und dieser zeigte mir nur, dass bei ihm alles wie gewünscht funktioniert - weiß aber auch keine Lösung. Kann sich hier wer vorstellen warum sowas so sein kann bzw. wie ich es anstelle, damit er auch im Hintergrund läuft?
Unter welchem Account läuft der Dienst. Normalerweise hat LocalService keinen Zugriff aufs Netzwerk. Starte diesen mit einem Useraccount.
Sorry für die dumm Frage, aber wie mache ich das? Ich rufe bis jetzt cmd als Administrator auf, ist das falsch?
sunshineh schrieb: > in den entsprechenden Ordner wechsle und dort gehts Dann ist wahrscheinlich der Pfad nicht bekannt? Auch mal Rechte genauer ansehen.
Wo gibt der Service seine Meldungen denn aus? Auf irgendeiner Konsole kann er nichts ausgeben. Wenn er das tut, läuft er nicht als Service. Stehen irgendwelche Meldungen zum Thema im Event Log? Die Selbstinstallation eines Service funktioniert nicht mehr so wie "früher", Deine Angaben deuten darauf hin, das hier genau dieses Problem vorliegt. "Bei mir gehts" als einzige Reaktion eines Entwicklers bedeutet exakt "ich habe da irgendwas zusammengeschrummelt, ohne es zu verstehen, also laß mich in Ruhe".
Also wenn ich mir die Properties des Services ansehe, so steht dort unter "Log On", "Local System account" aber der Haken bei "Allow services to interact with dektop" ist draußen.
sunshineh schrieb: > aber wie mache ich das? Administrative Tools Computer Management Services and Applications Services (DeinService) RightClick - Properties Der "Local System Account" kann natürlich auf's Netzwerk zugreifen, aber NICHT auf Netzwerklaufwerke. Und "Allow service to interact with desktop" erlaubt natürlich keine Konsolenausgaben.
Der Service schreibt eigentlich in ein txt. Nur wenn ich auf ihn Doppelklicke sehe ich die Konsole und das er Daten herunterlädt. Wie installiert ma den Service den richtig?
sunshineh schrieb: > Nur wenn ich auf ihn Doppelklicke sehe ich die Konsole und das er Daten herunterlädt. Du meinst, wenn Du ihn im Windows Explorer doppelklickst? Naja, dann läuft er NICHT als Service, sondern als normales Konsolenprogramm. > Wie installiert ma den Service den richtig? Mit dem zum Service mitgelieferten Installer.
Installer ist leider keiner dabei. Wenn die exe als Konsolenprogramm läuft, dann müsste sie ja auch als service laufen, oder? Ich bin eigentlich als Benutzer am pc angemeldet, sage aber bem cmd-Aufruf, als Administrator ausführen. woran kann ich bei einem Dienst erkennen, ob er ins Internet darf oder nicht?
sunshineh schrieb: > Installer ist leider keiner dabei. Lustig. Und was meint der Entwickler, wie Du ihn dann installieren sollst? > Wenn die exe als Konsolenprogramm läuft, dann müsste sie ja auch als > service laufen, oder? Nein. "Früher" konnte man einen Service so schreiben, das er sich quasi "selbst" installiert - aber spätestens seit Win7 geht das nicht mehr.
Dödel schrieb: > Unter welchem Account läuft der Dienst. Normalerweise hat LocalService > keinen Zugriff aufs Netzwerk. > Starte diesen mit einem Useraccount. das ist nicht richtig. Als LocalService hat er kein zugriff auf Freigaben, aber Sockets/Netzwerk geht ohne Probleme. Das kann also nicht das Problem sein.
Dauergast schrieb: > Nein. "Früher" konnte man einen Service so schreiben, das er sich quasi > "selbst" installiert - aber spätestens seit Win7 geht das nicht mehr. Natürlich geht das. Die Selbstinstallation erfordert Administratorrechte, und einen Kommandozeilenparameter zum Unterscheiden zwischen Aufruf durch SCM und Kommandozeile. Da hat sich nichts geändert, das geht auch auf 2012 Server R2 immer noch genau so.
Rufus Τ. F. schrieb: > das geht auch auf 2012 Server R2 immer noch genau so Du hast Recht ... funktioniert immer noch auf W8.1/64 und W10. Auf Kommentare im Source ist also auch kein Verlass mehr :(
Also nochmal zum Verständnis für mich. Der Service funktioniert an sich, dass sehe ich wenn ich es per Doppelklick auf die exe als Konsolenanwendung ausführe. Er kommt ganz normal ins Internet und ich muss ihn nirgends freischalten. Wenn ich ihn installiere gehe ich so vor. Ich starte cmd als Administrator, gehe in den entsprechenden Ordner und sage den exe Namen führt von install. Dann öffne ich Services.msc als User, nicht als Admin, gehe auf den Service und auf "Start", ich bekomme keine weitere Meldung einer Firewall oder ähnlichen, nur vom Programm die Info, dass er den Remote-Server nicht connecten kann. Für mich heißt dass doch, dass ich durch die Installation nicht auf die selben Sachen zugreifen kann, wie durch den Start als Konsolenanwendung. Avast und McAfee habe ich testweise deaktiviert, doch das hat nichts geholfen. Wie kann ich nun feststellen, warum der Dienst nicht läuft?
sunshineh schrieb: > Für mich heißt dass doch, dass ich durch die Installation nicht auf die > selben Sachen zugreifen kann, wie durch den Start als Konsolenanwendung. Dann starte den Dienst doch mal testhalber mit deinem eigenen Userkonto. Georg
sunshineh schrieb: > Der Service funktioniert an sich, dass sehe ich wenn ich es per > Doppelklick auf die exe als Konsolenanwendung ausführe. Er kommt ganz > normal ins Internet und ich muss ihn nirgends freischalten. Dann läuft das Ding aber nicht als Service ("Dienst"), sondern als stinknormales Programm. Und das tut es in dem Benutzerkonto, in dem Du gerade angemeldet bist. Wenn Du es als Dienst installierst, läuft es in einem anderen Benutzerkonto - das kannst Du im Dienstemanager auch einstellen (services.msc). Stell' da halt Dein Benutzerkonto ein (dazu musst Du Benutzernamen und Passwort angeben, und Dein Konto muss das Recht "Log on as a service" haben. https://technet.microsoft.com/de-de/library/cc794944(v=ws.10).aspx
Also, dass habe ich nun umgestellt. Nun erhalte ich die Meldung: Windows could not start the Service) on Local Computer. Error 1069: The service did not start due to a log-on failure.
sunshineh schrieb: > Also, dass habe ich nun umgestellt. Nun erhalte ich die Meldung: > > Windows could not start the Service) on Local Computer. > > Error 1069: The service did not start due to a log-on failure. Hast du denn dein Passwort korrekt eingegeben?
sunshineh schrieb: > Also, dass habe ich nun umgestellt. Nun erhalte ich die Meldung: > > Windows could not start the Service) on Local Computer. > > Error 1069: The service did not start due to a log-on failure. Hm. Diese Fehlermeldung deutet, nach etwas suchen im Internet, darauf hin, dass Du einen der genannten Schritte nicht, oder nicht korrekt ausgeführt hast. (Es gibt allerdings wahrscheinlich noch weitere Möglichkeiten). Prüfe bzw. wiederhole folgendes: > Stell' da halt Dein Benutzerkonto ein (dazu musst Du Benutzernamen > und Passwort angeben, und Dein Konto muss das Recht "Log on as a service" > haben.
Rufus Τ. F. schrieb: > Wenn Du es als Dienst installierst, läuft es in einem anderen > Benutzerkonto Es gibt hunderte Dienste auf dem PC, und fast alle Entwickler kriegen es hin, dass der Dienst auf das zugreifen kann was er braucht, ohne dass der Benutzer eingreifen muss. In diesem speziellen Fall scheint aber nicht nur der User/TO wenig Ahnung zu haben, sondern auch sein "Softwareentwickler". Georg
Ich habe gerade gesehen, dass die Hilfe-Seite ja für einen Windows Server gedacht ist. Ich habe hier aber nur einen normalen Windows 8.1 PC, auf dem ich den Dienst laufen lassen möchte. Das sollte doch auch funktionieren, oder?
Ja, die Installation und der Gebrauch von Services unterscheidet sich nicht zwischen den Server- und nicht-Server-Versionen von Windows. Die einzigen Windows-Versionen, die keine Services kannten, waren Windows 95 und seine Aufgüsse (98 & Me), aber jedes ernstgemeinte Windows seit 1993 kennt Services.
Hi, gerade habe ich meinen 360 Total Security Scan durchlaufen lassen. Er meldet mir die entsprechende exe mit EUR/QVM03.0.Maleware.Gen Muss ich mir hier Gedanken machen, dass der Entwickler mich betrügen wollte?
Naja, Werkzeugen mit Namen wie "360 Total Security" ist auch nicht zu trauen, es gibt durchaus "false positives". Mehrere Virenscanner gleichzeitig kannst Du hiermit https://www.virustotal.com/de/ ausprobieren. Wenn es da mehrere Treffer gibt, solltest Du mit dem "Entwickler" mal ein ernstes Wörtchen reden.
OK, ich habe nun die exe mit virustotal.com durchlaufen lassen und anscheinend ist sie sauber. Ich habe die exe nun auf einem anderen PC installiert und dort funktioniert alles einwandfrei. Habt ihr noch nen Tipp, was ich hier am Notebook machen kann bzw. was ich dem entwickler ausrichten kann? Ich hab keinen Plan was ich noch tun könnte und muss den Service hier zum Laufen bringen :-(
sunshineh schrieb: > Habt ihr noch nen Tipp, was ich hier am Notebook machen kann bzw. was > ich dem entwickler ausrichten kann? > Ich hab keinen Plan was ich noch tun könnte und muss den Service hier > zum Laufen bringen :-( das installieren klappt ja scheinbar, sonst würde er nicht in "Services" stehen. Lade dir mal https://technet.microsoft.com/de-de/sysinternals/bb896645.aspx runter. Setzte einen Filter auf den Name der exe und starten dann den Dienst.
@Peter II Danke, super Tipp! Das komische ist, dass der Prozess Monitor anzeigt, das der Service doch ins Internet kann. Dahinter steht doch SUCCESS. Kann ich hier nun irgendwie erkennen, warum der Service auf diesem Notebook keine Daten abruft, auf einem anderen aber schon?
Ich habe nun mit dem Process Monitor die Communication hier auf meinem Notebook und auch die dem anderen PC beobachtet. Bei dem anderen PC, bei dem der Dienst problemlos funktioniert, heißt es immer TCP Send und TCP Receive zu der externen IP-Adresse Bei mir hier lokal sieht wie im Anhang aus, er versucht einen TCP Reconnect zu 127.0.0.1:49701 -> 127.0.0.1:57482 Das sieht doch so aus als würde er die Anfrage an sich selbst senden, weil er nicht raus darf?? Wie komme ich nun an die Software, die diesen Dienst blockt? Kann ich dies auch irgendwie mit dem ProzessMonitor filtern?
sunshineh schrieb: > Wie komme ich nun an die Software, die diesen Dienst blockt? Kann ich > dies auch irgendwie mit dem ProzessMonitor filtern? war auf dem PC mal eine Firewall installiert (also nicht die von MS)? Norton hatte mal ein Problem, wenn man es entfernt hat blieben die regeln bestehen.
sunshineh schrieb: > Das sieht doch so aus als würde er die Anfrage an sich selbst senden, Ja. > weil er nicht raus darf?? Nö. Vermutlich weiß das Ding gar nicht, wohin es etwas senden soll.
Rufus Τ. F. schrieb: > Nö. Vermutlich weiß das Ding gar nicht, wohin es etwas senden soll. guter Einwand. Eventuell steht ja die Parameter für den Dienst in der Registry bei Current-User und da kommt der Dienst nicht ran.
OK, es kann schon sein, dass ich früher andere Antivirenprogramme bzw. Firewalls installiert hatte... Der Pfad wohin er soll steht eigentlich in einem *.exe.config File. Ich weiß aber nicht, ob dieser intern in die Registry geschrieben wird, habe aber gerade den Entwickler deshalb angeschrieben. //--- Mir ist noch etwas anderes aufgefallen, hat aber nichts direkt mit dem Problem zu tun. In der Services.msc habe ich keine Spalte mit der PID und kann diese auch nicht über View > Add/Remove Columns ergänzen. Kennt ihr das?
sunshineh schrieb: > In der Services.msc habe ich keine Spalte mit der PID und kann diese > auch nicht über View > Add/Remove Columns ergänzen. Verwechselt du das mit Unix/Linux? In Windows löschst du einen Prozess mit seinem Namen, nicht einer PID. Georg
sunshineh schrieb: > In der Services.msc habe ich keine Spalte mit der PID und kann diese > auch nicht über View > Add/Remove Columns ergänzen. Kennt ihr das? Verwechselst Du das vielleicht mit dem Taskmanager? Da wird bei den Diensten die PID angezeigt, im Dienste Fenster gibts die Spalte afaik nicht.
Als Workaround könnte man die .exe auch via Taskplaner bei Rechnerstart starten lassen.
Dauergast schrieb: > Nein. "Früher" konnte man einen Service so schreiben, das er sich quasi > "selbst" installiert - aber spätestens seit Win7 geht das nicht mehr. Natürlich geht das. Die Exe muß nur die entsprechende Manifest-Resource beherbergen, die klarstellt, dass sie Admin-Rechte benötigt und der User muss ggf. den UAE-Popup abnicken. Und dann geht alles im Prinzip ganz genau so, wie es schon immer ging, mindestens seit seligen NT3.5-Zeiten. Genau genommen hat sich am Sicherheitskonzept von WindowsNT nämlich seit unvordenklichen Zeiten rein garnix Nennenswertes mehr geändert. Der ganze auffällige, mit Vista eingeführte UAE-Quatsch (und mit Win7 wieder etwas weniger auffälig gewordene) ist nur übergestülpte Pseudosicherheit, die am Grundkonzept eigentlich absolut garnix geändert hat. Ungefähr so sinnvoll und hilfreich wie der per default nicht direkt "anmeldbare" root-account von Ubuntu oder andere, ähnlich idiotische "Sicherheits"-Einrichtungen anderer OS. Alles nur gleichermaßen hilflose Versuche, dem Hauptproblem irgendwie beizukommen: dem in mindestens 95% aller Fälle vollkommen unfähigen und unwissenden DAU vor dem Monitor, der einerseits das System möglichst umfassend benutzen können soll, sich dabei aber andererseits möglichst nicht gleichzeitig in die Scheisse reiten soll. Mein Fazit: Jeder dieser Ansätze ist letztlich gleichermaßen grandios gescheitert. Nutzerkompetenz läßt sich halt offensichtlich durch nix ersetzen, nur dadurch, eben diese zu schaffen. Und dazu hat wohl eigentlich keiner dieser idiotischen Ansätze irgendwie hilfreich beigetragen. Die Ubuntu-User kennen jetzt ihr Passwort sehr schnell auswendig (weil sie es für jeden Scheiß eintippen müssen) und die Wixdos-User können einen Button mehr anklicken als früher. Wow, welch ein grandioser "Gewinn" an Sicherheit...
Ja, das habe ich wirklich mit dem Taskmanager verwechselt! Vielen Dank! Der Entwickler hat mir nun geschrieben, dass das Programm die URL beim Start des Programms aus dem Config-File holt. Das hilft mir nur leider nicht weiter :-(
Hallo, wo sucht denn das Programm die Konfigdatei? Du schreibst das Programm aus der Dosbox gestartet zu haben - bist du da vorher in den Ordner gewechselt? Funktionert es auch wenn du das Programm aus einem anderen Ordner mit Angabe des Pfads startest? Was sagt der Prozessmonitor, sollte doch auch zu sehen sein. Sascha
Also ich gehe in den entsprechenden Ordner und klicke doppelt auf die exe-Datei, dann geht es. Das config-File liegt auch in diesem Ordner. Wenn ich den Doppelklick durchführe, bin ich ganz normal angemeldet, nicht als Administrator. Ich muss allerdings die Meldung von Windows noch bestätigen, dass ich diesem Dienst traue. Wenn ich den Dienst (also die gleiche exe) installiere, starte ich cmd als Administrator. Das Confi-File liegt aber auch in diesem Fall in dem Ordner der exe. Der Entwickler meinte nun: "Check your network settings - proxy etc. That's definitely your local configuration issue. If it doesn't help I will try to disable proxy programmatically just for needed requests" Was meint ihr dazu?
Laptop platt machen und neu aufsetzen anstatt noch tagelang hermumprobieren und virtuelle Windmühlen bekämpfen ....
Das Programm wird nicht auf seine Konfigurationsdatei zugreifen können. Lass' das Ding als Service laufen, schnapp' Dir den Process Explorer und lass' Dir die Eigenschaften des Prozesses anzeigen. Dort wird auch das Arbeitsverzeichnis angezeigt - in dem erwartet das Programm seine Konfigurationsdatei. Vernünftige Entwickler bauen in ihre Programme Log-Ausgaben ein, in denen sie unter anderem vermerken, ob ihre Programme auf Konfigurationsdateien zugreifen können.
Angehängte Dateien:
@Rufus: Das war es leider nicht. Ich sehe im Process Monitor, dass das Config-File ausgelesen wird :-( Den Laptop platt machen kann ich aktuell leider noch nicht, da ich noch ein paar Sachen hier brauche und noch nicht neuinstallieren kann. Für mich ist die IP-Geschichte unverständlich, wenn er doch das Config-File mit der Internetadresse ausliest.
sunshineh schrieb: > Ich sehe im Process Monitor, dass das Config-File ausgelesen wird Tatsächlich? Ich kann das da nicht erkennen. Im Verzeichnis c:\ep2\output wird nach Dateien gesucht, die provider_20151102*.csv heißen, aber gelesen wird davon auch keine. Es wird eine Logdatei beschrieben: c:\ep2\logs\2015-11-02.log Hast Du da mal 'reingesehen?
Schau Dir doch mal die Process Monitor Ausgabe auf dem PC auf dem es funktioniert an, wird da die gleiche Abfolge nur mit richtiger IP angezeigt?
Da ich noch keine Lösung gefunden habe, nutze ich das Programm als Konsolenprogramm. Allerdings habe ich nun das Problem, dass wenn ich auf ich auf das File zugreife, das periodische Herunterladen der Werte mit der Meldung "The process cannot access the file ... because it is beeing used by another process." Kann man mit Visual Studio das File so erstellen, dass ich es mit einem anderen Programm auslesen kann? Muss ich das File zuvor kopieren?
sunshineh schrieb: > Kann man mit Visual Studio das File so erstellen Du meinst, ein Programm so erstellen? Es gibt verschiedene Möglichkeiten, z.B. kann man nach der Taktik verfahren File öffnen - schreiben/lesen - sofort wieder schliessen, und wenn es nicht klappt nach x sec wieder probieren. Oder man öffnet die Datei in einem geeigneten sharing mode. In beiden Fällen muss man das aber in beiden Programmen richtig regeln, sowohl im Service als auch in dem Programm mit dem du zugreifen willst. Informiere dich über sharing modes. Georg
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.