Windows Service freeze

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

Guest

I have a C# Windows Service (using legacy COM objects, serial port and
remoting) which will occassionally lock up. I'm able to detect the lockup by
having a System.Timers.Timer watching the main loop. When the service locks
up all I want to do is to terminate it programmatically so it can be
restarted by another watchdog service. No matter what I try it will not
terminate. I was trying to use ServiceProcess.ServiceController.Stop() and
Process.Kill() and nothing happens. It still shows on a list of processes.
Actually I cannot even kill it manually by any method and I have to reboot
the computer to restart it. It seems like OS somehow lost track of this
sevice. It locks up randomly sometimes every few hours and sometimes every 6
weeks. It only happens on one particular computer and I can't simulate it
anywhere else. No exception is ever generated. It runs on Windows 2000.
Thanks for any suggestions.
Kris.
 
Kris said:
I have a C# Windows Service (using legacy COM objects, serial port and
remoting) which will occassionally lock up. I'm able to detect the lockup
by
having a System.Timers.Timer watching the main loop. When the service
locks
up all I want to do is to terminate it programmatically so it can be
restarted by another watchdog service. No matter what I try it will not
terminate. I was trying to use ServiceProcess.ServiceController.Stop() and
Process.Kill() and nothing happens. It still shows on a list of processes.
Actually I cannot even kill it manually by any method and I have to reboot
the computer to restart it. It seems like OS somehow lost track of this
sevice. It locks up randomly sometimes every few hours and sometimes every
6
weeks. It only happens on one particular computer and I can't simulate it
anywhere else. No exception is ever generated. It runs on Windows 2000.
Thanks for any suggestions.
Kris.
Click to expand...

Only way to solve this is to attach a debugger when it locks up. A service
or any process that isn't scheduled any more cannot be stopped nor killed,
this can happen when it's locked waiting in kernel mode. I would suspect the
serial port stuff, and I suggest you create a minimal set-up to exercse the
Serial port code in a multi-threaded environment.
Another thing to watch for is the COM object, what kind of object is this?
What are it's apartment requirements? Was it designed to be used from a
service? Was it tested in a mult-threaded process? Most legacy COM objects
aren't designed/tested to be used in such environment, watch out.


Willy.
 
Thank you Willy,
It does not sound too encouraging. The serial port is a managed code from a
third party so I may replace it with .NET 2.0 component when it comes up. I
don’t know too much about the COM objects other than they are old dlls which
were used for years also by different windows services (written in C++). My
service only starts one main thread which uses the COM. I may modify the
service to keep track of its execution path and dump it to a log file after
it detects a lock up to at least identify who’s possibly the culprit. The
debugger will probably be not feasible – it happens only on this particular
customer’s computer and it needs to be restarted right away to avoid losing
any more real-time data. My service still shows as “Started†on services list
but I can’t stop it there either.
Regards,
Kris.
 
Kris,
The fact that your COM DLL's were used for years in other Service
applications is no guarantee they behave correctly, the CLR environment may
reveal many hidden issues that never showed up in non managed environments.
So please check-out the COM apartment requirements, to do this you can use
oleview.exe or the regedit.exe tools, look for the threadingmodel value, it
can have the values Apartment, Both, Free or Single.
If it's Both or fee you are safe, but if it's Single or Apartment you have
to change your worker thread's ApartmentState to STA.
The reason that it shows up as started is quite normal when the service is
hung, the SCM (Service Control Manager) has no way to communicate with a
hung Service, so it has no idea about it's actual state and shows you the
latest state he got.

Willy.
 
Willy,
Thank you very much again. I will continue my investigation. Your
suggestions were very helpful. Regards,
Kris.
 
Back
Top