Service startet nicht

[himitsu]

Tachchen,

wir hängen hier seit einer Weile an einem Problem fest.

Es wurde mit Delphi XE über TService ein Service erstellt,
welcher sich aber urplötzlich nicht mehr starten läßt.

Am eigenen Quellcode kann es nicht liegen, da ich es auch schon über ein älteres Repository versucht hab, welches mal lief.

Was ich bis jetzt rausbekommen hab ist, daß TService.OnCreate noch erfolgreich durchläuft, aus Application.CreateForm kommt er auch noch raus und im Application.Run hängt es dann irgendwo ... TService.OnExecute wird nicht mehr aufgerufen.
Es hängt also scheinbar irgendwo innerhalb von TService und die Windows-Ereignisanzeigen sagen kein Wort, außer, was auch als Meldung kommt.

Zitat:

Fehler 1053: Der Dienst antwortete nicht rechtzeitig auf die Start- oder Steuerungsanforderung.

Das Ganze ist ein Windows Server 2008 R2 SP1 64 Bit.
Zwischen dem letzen bekannten Funktionieren unseres Services und dem erkannten Problem, wurden keine Windowsupdates eingespielt.
Aber auf anderen Systemen/Rechnern läuft es problemlos. :wall:



Hat da jemand eine Rat/Tipp?





Den Service zu Debuggen brachte keine Erkenntnisse, da es, auf Grund der Architektur, nicht ging.
- Service starten (mit Sleep drin, aber leider schießt die Diensteverwaltung den dann recht schnell ab)
- Delphi als Admin starten und dann zum Prozess verbinden
- nur klappt das mit dem Admin nicht, da delphi dann Adminkonto läuft und dort meine Einstellungen und benutzerbezogenen SUBST-Laufwerke nicht vorhanden sind

[Klaus01]

Hallo,

ist irgendetwas in den Windows Eventlogs zu finden?

Grüße
Klaus

[himitsu]

Wie gesagt, dort steht absolut nix.

Außer sowas wie,

Zitat:

Der Dienst "ProdatSRVXE" wurde unerwartet beendet.

Zitat:

Der Versuch des Dienststeuerungs-Managers, nach dem unerwarteten Beenden des Dienstes "ProdatSRVXE" Korrekturmaßnahmen (Neustart des Diensts) durchzuführen, ist fehlgeschlagen

Welches dadurch entsteht, daß wir den Prozess dann nur noch per Task-Manager abschießen können und dann versucht wird diesen neu zu starten.

[mkinzler]

Da bleibt euch wohl nur übrig. Weitere Logfunktionalität in den Dienst zu implementieren

[CCRDude]

Service debuggen braucht kein Sleep :)

Delphi IDE -> Menü Run -> Parameters -> Host application: "net", Parameters: "start MeinServiceName" (jeweils ohne die Anführungszeichen).

Das Laufwerksargument zählt (vermutlich) nicht - ein Service läuft i.d.R. sowieso nochmal unter einem ganz anderen Account (LocalSystem) und hat daher die ge-subst-eten Laufwerke auch nicht!

Eine Ausnahme wäre ein Service, der speziell unter deinem Account läuft. Aber wou dann noch ein Service?

Wenn's nur um's Delphi selber geht - ich starte mir immer den TotalCommander ebenfalls elevated, klicke einmal alle Netzwerklaufwerke oben durch, um die gleichen Verbindung, die ich ohne Elevation habe, herzustellen (bis dahin sind sie zwar bekannt, aber nicht geöffnet, und ein direkter Zugriff auf Dateien dort schlüge fehl), fertig. Einmal pro Rechnerneustart halt, lässt sich sicher auch automatisieren, war ich bisher nur zu faul zu ;)

[himitsu]

Wir haben Eurekalog drin (auch versuchsweise mal nicht)
und ich hab nun schon zu nahezu jedem Befehl einen Logeintrag (pumpe es seit Tagen nur noch voll damit).
Mehr Logs gehn nicht, da das Programm sonst nirgenwo mehr vorbei kommt.

Zitat:

Das Laufwerksargument zählt (vermutlich) nicht - ein Service läuft i.d.R. sowieso nochmal unter einem ganz anderen Account (LocalSystem) und hat daher die ge-subst-eten Laufwerke auch nicht!

Das bezog sich auf mein Delphi und die Quellcodes, ohne welche ein Debuggen etwas schwer wird.

Zitat:

Delphi IDE -> Menü Run -> Parameters -> Host application: "net", Parameters: "start MeinServiceName" (jeweils ohne die Anführungszeichen).

Ich versuch's mal.

Zitat:

Einmal pro Rechnerneustart halt, lässt sich sicher auch automatisieren, war ich bisher nur zu faul zu

Ist ein Terminal-Server und jeder Benutzer hat siene eigenen Pfade/Laufwerke.

Wenn ich was über's UAC mit Adminrechten gestartet hab (bin ja nur "Benutzer"), dann sehen die Programme die einstellungen des Admin-akkount, also dessen Benutzernamen und dieser Name wird dann zum verbinden der Laufwerke verwendet.

[himitsu]

Zitat:

Delphi IDE -> Menü Run -> Parameters -> Host application: "net", Parameters: "start MeinServiceName" (jeweils ohne die Anführungszeichen).

Über NET START im Debugger gestartet funktioniert nicht.

Application.Run; beendet sich dann immer sofort und startet erst garnicht.
Das passierte auch schon, als ich damals versuchte den Prozess (die Service.exe) direkt im Delphi zu debuggen.

Irgendwie erkennt TService anscheinend, daß es nicht als "Dienst" im SYSTEM-Konto läuft und startet dann garnicht erst.

Aus diesem Grund hatte ich damals sowas gemacht, um es Debuggen zu können.

Delphi-Quellcode:

procedure TProdatSRVXEService.ServiceCreate(Sender: TObject);
var
  Started: Boolean;
  Temp:    TForm;
begin
  LogEvent('DataServer-Create');
  LoadConfiguration;

  if Trim(SvcMgr.Application.Title) = '' then
    SvcMgr.Application.Title := ExtractFileName(Forms.Application.ExeName);
  if IsDebuggerPresent or FindCmdLineSwitch('DEBUG') then begin
    Forms.Application.MainFormOnTaskBar := False; // geht leider doch nicht ohne Form
    Forms.Application.CreateForm(TForm, Temp);    // Form zum Beenden und für Eintrag in Taskbar
    Temp.Caption      := 'Debug-Mode: ' + SvcMgr.Application.Title;
    Temp.OnCloseQuery := DebugServiceClose;
    Temp.Visible      := True;
    { SvcMgr.Application.Run; }
    {}if FindCmdLineSwitch('INSTALL', ['-', '/'], True) then
    {}  TServiceApplicationHack(Application).RegisterServices(True, FindCmdLineSwitch('SILENT', ['-', '/'], True))
    {}else if FindCmdLineSwitch('UNINSTALL', ['-', '/'], True) then
    {}  TServiceApplicationHack(Application).RegisterServices(False, FindCmdLineSwitch('SILENT', ['-', '/'], True))
    {}else begin
    {}  Started := True;
    {}  ServiceStart(Self, Started);
    {}  if Started then
    {}    while not (Terminated or StopService) do begin
    {}      Forms.Application.ProcessMessages;
    {}      Sleep(20);
    {}    end;
    {}  Forms.Application.Terminate;
    {}end;
  end;
end;

procedure TProdatSRVXEService.DebugServiceClose(Sender: TObject; var CanClose: Boolean);
begin
  StopService := True;
end;

Diese "Hack" läuft, wobei Application.Ran umgangen wird, welches ja erzeit nicht geht und beim Debuggen auch nie funktionierte.
Allerdings läuft er so als Anwendung und nicht als Dienst.

PS: Diesen Codeteil hatte ich gerade natürlich auskommentiert.

[CCRDude]

Zitat:

Zitat von himitsu (Beitrag 1106723)

Über NET START im Debugger gestartet funktioniert nicht.

Hmmm... liegt das Kompilat denn auf einem lokalen Laufwerk? Also nicht im Netz oder einem gesubsteten Laufwerk?

Bei mir funktioniert es nämlich (mit Delphi XE) sehr zuverlässig, habe damit gerade in den letzten 8 Wochen etliches debugged. Erinnere mich grob daran, daß der Service natürlich schon installiert sein muss, und der ImagePath stimmen muss (ich habe für Debug und Release getrennte Pfade, d.h. ein installiertes Release würde Debug "unmöglich" machen - dann springt er halt auch mit F7 gar nicht erst in den Code). Das sind meine zwei Hauptfehler beim Testen gewesen.

Zitat:

Zitat von himitsu (Beitrag 1106723)

Irgendwie erkennt TService anscheinend, daß es nicht als "Dienst" im SYSTEM-Konto läuft und startet dann garnicht erst.

Aber damit TService etwas tun kann, muss der Code ja schon ausgeführt werden. Dann hilft es eventuell, halt direkt mit F7 statt Breakpoints ins Debuggen zu starten und ganz von Anfang durchzusteppen.

Allerdings kann ich wie gesagt meine Services, die mit ObjectName=LocalSystem sowohl in Delphi konfiguriert als auch im System eingetragen sind, zu debuggen.

Wie das mit Delphi 2010 ist, weiß ich leider nicht, nur daß es unter Delphi 2006 (hatte ich davor) nicht so einfach klappte.

Jetzt mit IDA Pro (oder einem anderen Debugger Deiner Wahl) auch noch das "net" zu debuggen, um zu sehen, ob und wie er in Dein Kompilat springt, wäre vermutlich etwas übertrieben, würde mir sonst nur als letzte Lösung einfallen.

[himitsu]

EXE direkt im Debugger gestartet liegt auf einem SUBST-Laufwerk.
Der installierte Service aber auf einer normalen Partition.

Also starten tut es erstmal, aber .Run beendet sich eben immer gleich wieder.

[mkinzler]

Und wenn du die Exe mal testweise auf ein lokales Laufwerk packst?

[CCRDude]

Wenn Du schreibst, daß .Run sich eben immer gleich wieder beendet, heißt das also, daß Du in den Debugger kommst? Links hast Du blaue Punkte neben den Codezeilen und irgendwo stehst Du an einem Breakpoint in Deinem Code?

Dann kompilier im Zweifel mit Debug-DCUs (im die RTL mitdebuggen zu können), und wenn er aus .Run sofort wieder rausspringt, stepst Du halt mit F7 rein, und hast außerdem Breakpoints auf allen Deinen Events im TService.

[Daniela.S]

Vielleicht kannst mit MadExcept mehr herausfinden?
Map Datei mit allen Debug Infos dazu und Code Info erhöhen...

Debuggen geht dann zwar nicht, aber sollte helfen zu sehen wo er genau hängt


Tante Edit, Link http://madshi.net/

[himitsu]

Als Service und auch beim Debuggen (über dieses NET START) liegt alles auf einem lokalen Laufwerk.
Außer die Quellcodes, aber die findet Delphi ja.

zu MadExcept EurekaLog und Co:
Wie gesagt, es stürtz nichts ab, es gibt keine Exceptions ... es bleibt ganz einfach hängen.

[mkinzler]

Aber halt auf einem gemappten Laufwerk.

[Daniela.S]

Bei MadExcept gibt es die Einstellung "check for frozen main thread -> freeze timeout (sec)"

Einen Versuch wäre es wert...

[himitsu]

Zitat:

Zitat von mkinzler (Beitrag 1106748)

Aber halt auf einem gemappten Laufwerk.

Nee, gerade das ist eines der Laufwerke, welche "original" sind. :lol:

[p80286]

Zitat:

Zitat von himitsu (Beitrag 1106746)

Wie gesagt, es stürtz nichts ab, es gibt keine Exceptions ... es bleibt ganz einfach hängen.

Dafür gibt es meist nur einen Gründ
a) Irgendeine Datei oder was auch immer ist nicht vorhanden und er sucht und sucht......
b) Eine Benutzereingabe wird erwartet, aber wenn der Benutzer nichts sieht.............
c) Endlosschleife.

Und wenn's auf anderen Maschinen läuft, wo sind die Unterschiede?

Gruß
K-H

[QuickAndDirty]

Wir haben solche Probleme auch manchmal...
bis her lag es meistens an
-Rechten...selbst der Admin hatte nicht genug rechte für bestimmte temp Dateien oder ähnliches...wegen bekloppter Gruppenrichtlinien...
Der Fehler passiert dann schon in der initialization der unit...bäh
-unvorhergesehene Fehler mit Showmessage o.ä. ...z.B. Units die implizit eingebunden werden und mit Showmessage Fehler ausgeben....bähh
-komische Einstellungen in den Einstellungsdateien...z.b. Pfade mit Netzwerklaufwerken oder Subst-gemappte-Laufwerke!

hast du den Timeout für deinen Dienst mal rauf gesetzt ? Vielleicht braucht er wirklich länger.

[p80286]

Zitat:

Zitat von QuickAndDirty (Beitrag 1106775)

hast du den Timeout für deinen Dienst mal rauf gesetzt ? Vielleicht braucht er wirklich länger.

Wenn er bis zum .Run kommt?
Die Ausgangsmeldung würde dafür sprechen.

Gruß
K-H

[himitsu]

Die Lösung:

Anscheinend hat es vermutlich irgendwas an der Diensteverwaltung unseres Terminalservers zerschossen.

Im Endefekt haben wir jetzt einfach nur den Dienst umbenannt und plötzlich geht alles wieder. :wall:

[p80286]

*Schulterzucken*
So isses halt

Gruß
K-H

[QuickAndDirty]

Das hatte ich auch mal bei einem Kunden....
Der Admin hat natürlich jede Verantwortung von sich gewiesen...Außerdem ist ja nicht SEIN Server Schuld wenn UNSER Dienst nicht unter dem Namen arbeitet.....

Wer hat die Bugsuche bei euch bezahlt?


UND
*frust ablassen und morgen löschen...oder gebannt werden*

Am Freitag habe ich ein Problem Gelöst...Dienst hängt sich auf und lässt sich nicht mehr beenden....danach habe ich 2 Wochen gesucht...
Kunde setzte eine treiber DLL ein ...die tunnelt einen echten Treiber von außen in das System per IP....und....sie wirft "::MessageBox" wenn die IP-Verbindung scheiße ist.....

"::MessageBox" in einer DLL die von einem Dienst benutzt wird........

Der Admin meinte zu mir nur..."Die macht keine MessageBox, die müsste ich doch sonnst sehen" *facepalm*
...obwohl das dingen 32K zeichen openssource text ist, jeder das sehen kann das die DLL das macht und ich es nachvollziehen konnte...weil ich die auch einsetze...

Wer bezahlt das ich das Programm unnötigerweise 2 Wochen lang mit kleinstschrittigen Logausgaben voll gepackt hab? genau niemand. Wer ist dafür verantwortlich das der Dienst nicht lief??? Wir natürlich und nicht der Typ der auf die glorreiche Idee gekommen ist eine Opensource Notlösung als Treiber DLL zu installieren die MessageBoxen schmeißt wenn das Netzwerk nicht schnell genug reagiert. Und wieso ist kein Admins jemals selbst auf die Idee gekommen irgendetwas von dem was er tut oder wofür er verantwortlich ist, in zweifel zu ziehen und zu überprüfen?
Ganz einfach, weil sie es nicht müssen !!!

[himitsu]

och, war ja "nur" unserer eugener nagelneuer Server.

kleinschritig ist gut ... alleine beim Start entstehen gleich mal 70 KB an Logs :lol:

PS: geil ist ja, daß EurekaLog das Application.OnException kapput macht und man selber auch noch gerne darauf reagieren möchte.

[Cici]

Hallo,
ich habe das gleiche Problem wie der Themenstarter <E1053:>
habe aber keine Lösung.

Versuche auch einen Service mit Delphi XE2 zu erstellen.
Im meiner Verzweifelung habe ich mich an Beispielen gehalten die bei anderen Usern bereits liefen.

Den Service installiere ich mit:
sc create "TEST" start= auto binpath= "c:\x\Servicetest.exe"
sc description "TEST" "TEST Dienst"

Starten mit:
sc start "TEST"

Der Prozess erscheint in der Win-Prozessliste und das wars dann.

Das Starten mit dem Dienstmanger ergibt Error:1053.

Es wird nicht einmal die Logdatei angelegt.
Also "oncreate" wird nicht ausgeführt.

Hier der Code:

Code:

unit ServMain;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.SvcMgr, Vcl.Dialogs,
  Vcl.ExtCtrls;

type
  TService4 = class(TService)
    procedure ServiceStart(Sender: TService; var Started: Boolean);
    procedure ServiceStop(Sender: TService; var Stopped: Boolean);
    procedure ServiceCreate(Sender: TObject);
    procedure ServiceExecute(Sender: TService);
    procedure ServiceDestroy(Sender: TObject);
    procedure ServiceBeforeInstall(Sender: TService);
    procedure ServiceAfterUninstall(Sender: TService);
  private
    { Private-Deklarationen }
    LogFile: TStringList;
  public
    function GetServiceController: TServiceController; override;
    { Public-Deklarationen }
  end;
const LogFileName = 'Service_log.txt';
var
  Service4: TService4;

implementation

{%CLASSGROUP 'System.Classes.TPersistent'}

{$R *.DFM}

procedure ServiceController(CtrlCode: DWord); stdcall;
begin
  Service4.Controller(CtrlCode);
end;

function TService4.GetServiceController: TServiceController;
begin
  Result := ServiceController;
end;

procedure TService4.ServiceAfterUninstall(Sender: TService);
begin
   LogFile.Add(DateTimeToStr(Now)+' OnAfterInstall');
  LogFile.SaveToFile(LogFileName);
end;

procedure TService4.ServiceBeforeInstall(Sender: TService);
begin
  LogFile.Add(DateTimeToStr(Now)+' OnBeforeInstall');
  LogFile.SaveToFile(LogFileName);
end;

procedure TService4.ServiceCreate(Sender: TObject);
begin
  LogFile:=TStringList.Create;
  LogFile.Add(DateTimeToStr(Now)+' OnCreate');
  LogFile.SaveToFile(LogFileName);
end;

procedure TService4.ServiceDestroy(Sender: TObject);
begin
  LogFile.Free;
end;

procedure TService4.ServiceExecute(Sender: TService);
begin
  while not Terminated do
  begin
    LogFile.Add(DateTimeToStr(Now)+' OnExecute');
    LogFile.SaveToFile(LogFileName);
    ServiceThread.ProcessRequests(False);
    Sleep(1000);
  end;
end;

procedure TService4.ServiceStart(Sender: TService; var Started: Boolean);
begin
  LogFile.Add(DateTimeToStr(Now)+' Service gestartet');
  LogFile.SaveToFile(LogFileName);
end;

procedure TService4.ServiceStop(Sender: TService; var Stopped: Boolean);
begin
  LogFile.Add(DateTimeToStr(Now)+' Service gestoppt');
  LogFile.SaveToFile(LogFileName);
end;

end.

...und...

Code:

program Servicetest;

uses
  Vcl.SvcMgr,
  ServMain in 'ServMain.pas' {Service4: TService};

{$R *.RES}

begin
  // Für Windows 2003 Server muss StartServiceCtrlDispatcher vor
  // CoRegisterClassObject aufgerufen werden, das indirekt von
  // Application.Initialize aufgerufen werden kann. TServiceApplication.DelayInitialize
  // ermöglicht, dass Application.Initialize von TService.Main (nach
  // StartServiceCtrlDispatcher) aufgerufen werden kann.
  //
  // Eine verzögerte Initialisierung des Application-Objekts kann sich auf
  // Ereignisse auswirken, die dann vor der Initialisierung ausgelöst werden,
  // wie z.B. TService.OnCreate. Dies wird nur empfohlen, wenn ServiceApplication
  // ein Klassenobjekt bei OLE registriert und für die Verwendung mit
  // Windows 2003 Server vorgesehen ist.
  //
  // Application.DelayInitialize := True;
  //
  if not Application.DelayInitialize or Application.Installing then
    Application.Initialize;
  Application.CreateForm(TService4, Service4);
  Application.Run;
end.

Bin ich blind?

[angos]

Hi,

hast du die anderen Beiträge hier schon gelesen? Das riecht ein bisschen nach fehlenden Rechten, die Datei anlegen zu dürfen.

Gruß

[Bummi]

Wo soll den "LogFileName" entstehen, ich habe nur den Dateinamen gefunden.
Wenn Du im Constructor ein Sleep(10000) einbaust hast Du genügend Zeit Dich in Delphi über Start/Mit Prozess verbinden mit dem Debugger darufzustürzen.

[Cici]

Erstmal Danke für Eure Antworten.

Das mit dem Logfile habe ich gemacht, da Showmessage nur interativ funktioniert.
Wenn ich das mit Logfile weglasse, geht es auch nicht.
Bis oncreate komme ich erst gar nicht.
Am Anfang habe ich es nur mit "Beep" versucht.

Mit dem Debugger habe ich es auch versucht, sehe aber im "Prozess verbinden Dialog" meinen Prozess nicht.
(Auch nicht mit dem häckchen "Systemprozesse anzeigen").
Anscheinend werden alle Systemprozesse hier nicht angezeigt (z.B. Sidebar &Co auch nicht)
(Delphi XE2 Prof Upd.4)

[Cici]

ach ja
wenn ich es mit dem Parameter Bla.exe /INSTALL versuche bekomme ich nach 30 sek. EOSError Code 5

[Bummi]

Du musst Delphi hierfür "Als Administrator" ausführen (Win Vista / 7 rechter Mausklick)

[Cici]

Zitat:

Zitat von Bummi (Beitrag 1170909)

Du musst Delphi hierfür "Als Administrator" ausführen (Win Vista / 7 rechter Mausklick)

Guter TIP - wäre ich nicht drauf gekommen, da ich als Admin angemeldet bin.

[Cici]

Zitat:

Zitat von Bummi (Beitrag 1170909)

Du musst Delphi hierfür "Als Administrator" ausführen (Win Vista / 7 rechter Mausklick)

Debug geht, bringt mich aber nicht weiter.
Lande im CPU Fenster bei "NTKernel.dll".
Nach einigen "F7" wird das "Programm" ausgeführt - das wars - nix weiter.
Ich komme nicht an "meinen Code" ran.
Das Problem muss wohl irgenwo "weiter vorne" liegen.

Der Prozess muss manuell gekillt werden.

[Bummi]

kommentier mal versuchsweise den Code in ServiceExecute aus ...

[Cici]

Zitat:

Zitat von Bummi (Beitrag 1170920)

kommentier mal versuchsweise den Code in ServiceExecute aus ...

Kein Effekt.
Oncreate müßte vor Execute ausgeführt werden.

Auch eine Variante ohne alle anderen events ausser ein Beep in "oncreate" verändert nichts.

Code:

unit ServMain;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.SvcMgr, Vcl.Dialogs,
  Vcl.ExtCtrls;

type
  TService4 = class(TService)
    procedure ServiceCreate(Sender: TObject);
    procedure ServiceExecute(Sender: TService);
  private
    { Private-Deklarationen }
  public
    function GetServiceController: TServiceController; override;
    { Public-Deklarationen }
  end;
var
  Service4: TService4;

implementation

{%CLASSGROUP 'Vcl.Controls.TControl'}

{$R *.DFM}

procedure ServiceController(CtrlCode: DWord); stdcall;
begin
  Service4.Controller(CtrlCode);
end;

function TService4.GetServiceController: TServiceController;
begin
  Result := ServiceController;
end;

procedure TService4.ServiceCreate(Sender: TObject);
begin
  Beep
end;

procedure TService4.ServiceExecute(Sender: TService);
begin
  Beep; sleep(100); Beep;
end;

initialization
 Sleep(10000);
end.

[Cici]

Das ganze unter D2005 probiert.
Selber effekt
Der Service lässt sich nicht installieren.
Das müsste doch wenigsten beepen - oder?

Code:

program Servicetest;

uses
  SvcMgr,
  Unit6 in 'Unit6.pas' {Service6: TService};

{$R *.RES}

begin
  Application.Initialize;
  Application.CreateForm(TService6, Service6);
  Application.Run;
end.

...und...

Code:

unit Unit6;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, SvcMgr, Dialogs;

type
  TService6 = class(TService)
    procedure ServiceCreate(Sender: TObject);
    procedure ServiceExecute(Sender: TService);
  private
    {$R *.DFM}
  public
    function GetServiceController: TServiceController; override;
    { Public-Deklarationen }
  end;

var
  Service6: TService6;

implementation

{$R *.DFM}

procedure ServiceController(CtrlCode: DWord); stdcall;
begin
  Service6.Controller(CtrlCode);
end;

function TService6.GetServiceController: TServiceController;
begin
  Result := ServiceController;
end;

procedure TService6.ServiceExecute(Sender: TService);
begin
  Beep;
end;

procedure TService6.ServiceCreate(Sender: TObject);
begin
  Beep;
end;

end.

[CCRDude]

Solange der Service unter dem SYSTEM-Account und nicht unter Deinem Account läuft, darf er vermutlich gar nicht beepen. Microsofts (z.B. Logo-) Richtlinien schreiben nämlich vor, dass nur der User der aktiven Session Soundausgabe vornehmen darf. Zu finden in den Logo Requirements unter dem Stichwort Fast User Switching; das ist hier zwar nicht dasselbe, aber es geht auch um unterschiedliche Konten, daher nehme ich mal an, dass MS hier konsequent gewesen sein könnte.

Zum Problem selber kann ich leider auf die Schnelle nichts sagen, der Tipp mit dem Debuggen kam ja schon zur Genüge. Im Zweifel kannst Du noch sicherstellen, dass Du die Debug-DCUs verwendest, dann solltest Du den Crash-Punkt auch lokalisieren können, wenn er in der RTL liegt. Oder evtl. mit madExcept (oder Heureka und wie dei Alternativen heißen) arbeiten, um nen Callstack zum Zeitpunkt des Fehlers zu bekommen.

[Cici]

Lösung gefunden!
Der Code war in Ordnung.
Es lag an der Art der Installation.
Wenn die ServiceApp mit dem Parameter /INSATLL installiert wird geht es.
Wenn die ServiceApp mit SC.EXE installiert klappt es wie beschrieben nicht.

Dies war die Batch Datei, die mit "run as Admin" aufgerufen wurde.
sc create "ISMAS_TEST" start= auto binpath= "c:\x\Servicetest.exe"
sc description "ISMAS_TEST" "TEST Dienst"

Wo ist Unterschied?