Service Problem - service on local computer started and then stopp

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I have created Windows Services before using C# and have had no problems.
Not to mention, the one I currently am having problems with worked great for
the first 3 days. Then I added some more SQL code and went to test it again
and now whenever I start the Service up I get the following error message...

The <xxx> service on local computer started and then stopped...

I tried a few things like removing the new code and such without any
success. I even wound up creating a brand new Project as a Windows Service
and all this one does at the moment is wait for a timer to elapse in 10
seconds and then it will write an entry to the log file. I also have it
logging at OnStart and OnStop. None of the logging happens.

Since there is really no code other than event log stuff in the new project,
I have to assume it is some other something that is halting my service. this
is really killing my time and any solution would be Greatly appreciated.

Further information:

I just took the slimed down version of the Windows Service to another
machine. Did the InstallUtil and started it. It started and did the logging
as expected. I then manually stopped it and all went as it should.

Nothing my event logs seems to point to anything that is of any use. The
application log has nothing in it when I attempt to start it. The System has
two events (7035 - Successfully sent a start control) then right after that
is (7036 - entered the stopped state.)

I tried to run it in Safe Mode but it would not let me start that service in
Safe Mode.

PLEASE help
 
You didn't mention anything about exception handling in your service. As a
service has no visible user interface, having the service at least write log
entries when something goes awry is a good idea. Using try/catch, and
handling exceptions well is virtually imperative.

If you have Visual Studio.Net, you can also attach to the Service process to
debug it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition
 
Kevin, I will try a try-catch block, but as I mentioned, all I am doing is an
EventLog.Write method in the OnStart, OnStop and the timers elapsed event.
But perhaps there is something going wrong there and will try it.

As for debugging the service, that only works if you can get the service
started. Lucky me, I can't even get that far.

I just tried it on yet another machine and it works like a champ.

Ugh, more help needed I am afraid. I will post after I do the above.
--
Thanx,
Grigs


Kevin Spencer said:
You didn't mention anything about exception handling in your service. As a
service has no visible user interface, having the service at least write log
entries when something goes awry is a good idea. Using try/catch, and
handling exceptions well is virtually imperative.

If you have Visual Studio.Net, you can also attach to the Service process to
debug it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
If you push something hard enough,
it will fall over.
- Fudd's First Law of Opposition
Click to expand...
 
This behaviour is typical for when an exception is thrown on startup. Maybe
there's something wrong with the EventLog.Write call?

Like Kevin said, Try/Catch is a good idea.

--
Robert Jeppesen
Durius
http://www.durius.com/
Grigs said:
Kevin, I will try a try-catch block, but as I mentioned, all I am doing is
an
EventLog.Write method in the OnStart, OnStop and the timers elapsed event.
But perhaps there is something going wrong there and will try it.

As for debugging the service, that only works if you can get the service
started. Lucky me, I can't even get that far.

I just tried it on yet another machine and it works like a champ.

Ugh, more help needed I am afraid. I will post after I do the above.
Click to expand...
 
Robert said:
This behaviour is typical for when an exception is thrown on startup. Maybe
there's something wrong with the EventLog.Write call?

Like Kevin said, Try/Catch is a good idea.
Click to expand...
But the real problem in this situation is what do you do in your catch
block - normal thing for me would be to write to the event log...

I generally write my services inside DLLs. Expose one class with
start/stop/pause/continue methods. Then my service EXE is just a very
thin wrapper on top of that. Advantage is, I can write a windows forms
EXE which is also a thin wrapper and has buttons for the service
methods. That way, I can get in and debug right from the first line of
real code. I think others have other approaches to this "how to debug
service start" problem.

Damien
 
This is how I write my services too. I usually have both a console app and a
winforms app for running the service as well.

A tip for Grigs is to do this as well. Handle logging as an event that
client apps (Console, Winform, Service) can handle however they wish. This
way, in say, a console app, you can output to console instead of the event
log.

Having it setup this way also helps you quickly find out if your problem has
to do with the fact that its running as a service or not.
 
Sounds like something to look into from Damien and Robert and I most
definately will. Do you have a link on how to do that?

Yes, I thought more about the try-catch suggestion but yes, the EventLog is
never happening so I may go another route and write it to a file or something.

I will try that when I get into work today.
 
Well I figured out what the problem was. Oddly enough, the debugger wasn't
coming until more recently (don't believe I changed anything.) I did look at
the message that was coming up in the debugger and it was that the Log File
was full.

I simply changed it from the default of overwrite every 7 days to overwrite
as needed (and changed it to 1024) and EVERYTHING WORKS AGAIN.

Uuugh, what a stupid default setting. At least since problems can occur
when it's full.

Thank you all for your suggestions - if you have a link to how to do it your
way from Robert or Damien, that would be kewl.
 
Grigs,

I can't believe you ran into this old .Net Framework bug? Please tell me you
aren't running v2.0, that would mean that they still haven't fixed this! I
struggled for ages with this bug in .Net 1 Beta in a project. I could have
told you about this problem, but I didn't think it was still around.

About how to do it "our" way, simply move all of your application specific
code into a separate dll. Implement the same Start/Stop (optionally
Pause/Continue) in your dll. In your service, you reference your new dll and
call up an instance of that and pass the Start/Stop methods into it.

Real brief:

// Your new dll:
public delegate void Logger(String msg, int LogLevel);
public class MyServerDll
{
public event Logger logger;

private void Log(String msg, int LogLevel)
{
if(logger!=null)
logger(msg, LogLevel);
}
public void Start()
{
}
public void Stop()
{
}
}

Your new Service (ripped out tons of stuff for brevity, but you get the
picture)

public class MyService : System.ServiceProcess.ServiceBase
{
private MyServerDll myserver;

protected override void OnStart(string[] args)
{
myserver = new MyServerDll();
myserver.logger += new Logger(Log);
myserver.Start();
}

private void Log(String msg, int LogLevel)
{
EventLog.WriteEntry(msg);
}

protected override void OnStop()
{
myserver.Stop();
}
}

Now, whenever you call Log() in your server dll, the eventlog will be
written to.
The beauty of this is that you can just as easily run this from a WinForm or
Console app, providing separate log methods, so that if you run it from a
Console app for instance, you'd do something like:
private void Log(String msg, int LogLevel)
{
Console.WriteLine(msg);
}

HTH
 
Back
Top