1

Forgive me if this is a stupid question, I'm fairly new to writing services. I've written a service that runs a timer and the timer code runs some checks to ensure our systems are up and running. It's written in VB.Net, framework 1.1. I then install the service using "sc create". The service works beautifully on the XP Pro machine that I'm developing on. However, when I install the service on a Windows 2003 server 64 bit, the service fails with error 1053 immediately. I put some debugging in to write to a text file as the first line of code in the OnStart function but even that doesn't run, so there must be a problem in the program starting up. Finally in desperation I created a brand new Windows Service in a new VB project in Visual Studio 2003 and compiled an empty service that merely declares and sets the value of a string variable in the OnStart function as follows:

Dim strTmp As String
strTmp = "hello"

Even that failed on the W2K3 server, but works fine on the XP dev machine. The server has .Net Framework 1.1 installed and working, we use it in our CMS (written in ASP.Net 1.1). The service runs as the local system account. I tried enabling interaction with the desktop but that didn't help. I ran Process Monitor and there are no access denied events. I emptied the Application Event Log, still doesn't work. No other events to help me out in the logs. Definitely using the Release build of the application. Permissions on the exe file are full control for System and for Admins. Any ideas anyone? It must be something simple, but I'm damned if I can figure it out! Thanks in advance.

@DavidHi, many thanks for the suggestions. I don´t think the first point is my problem, partly because the MS article is about stopping or pausing the service, mine fails on starting; but also because the service does not timeout, there is no 30 second wait, it fails immediately. Secondly, when you say add an exception handler to the service startup, do you mean the OnStart sub? I tried adding a debug file write in there, but I'll try adding an event log instead. Regarding the systems checks, it can't be that because the brand new empty test service I created shows the same behaviour and that does not do anything at all. You last point could be the key. My dev environment IS 32bit. I'll do some research on the corflags thing, or perhaps I can build a 64bit dev environment. Many thanks again, you've given me some new things to think about at least!

Ok, have found a workaround. I was putting my exe file in System32. When I put it in a different folder, created by myself, the service ran, albeit briefly. I then had to move the ini file and the log files that it reads/writes to that folder too, rather than System32, and all seems to work nicely. God knows why it doesn't like running from System32 but at least it works now! Thanks for the help guys.

Ravindra Bagale
  • 17,226
  • 9
  • 43
  • 70
el_foz
  • 11
  • 4
  • In your project properties > Compile > Advanced Compile Options > Target CPU, do you have it set to x86, x64, or AnyCPU? – Steven Doggart Sep 19 '12 at 14:23
  • Don't think Framework 1.1 has any notion of 64-bit compilation...it was in the 32-bit world IIRC – David W Sep 19 '12 at 14:48
  • Can you retarget your service to Framework 2.0? – David W Sep 19 '12 at 14:51
  • @steven - thre don't seem to be any Advanced Compile or Target CPU options in this version of Visual Studio (2003). – el_foz Sep 20 '12 at 09:50
  • @david - not sure what you mean by retarget. Install .Net v2.0 and then recreate the project in VS2003 using that framework? – el_foz Sep 20 '12 at 09:52
  • Later versions of Visual Studio.let you specify the framework to target I would at least migrate to 2.0 as I don't think MS even supports 1.1 it anymore – David W Sep 20 '12 at 12:39

2 Answers2

0

The 1053 error is a timeout related to the service control manager waiting for the service to respond to your start request. There is a knowledgebase article that refers to managed service stop request issues specifically relating to Framework 1.1-based services, so it is not precisely describing your problem, but it may have relevance in your situation. The link is provided for your reference.

http://support.microsoft.com/kb/839174

The other suggestion I would make to further diagnose the issue is to determine whether the Start is failing due to a "hidden" exception occurring in your service's startup code; the start call would not see the exception and could make you think it was merely timing out.

I would suggest you add an exception handler to your service startup that does nothing more than log a message to the event log with the particulars of the exception if one is caught. That would at least give you an idea that something is going wrong specifically within the service, and give you more information than you have right now.

One last thought: Does the service check the systems you describe over a network connection? If so, LocalSystem won't have sufficient privileges to perform network access.

Good luck!

EDIT One other possibility:

Is your development environment/execuable 32-bit? You mention your server is 64-bit, so you may need to use the "corflags" tool that forces 32bit operation on your executable

corflags /32bit+ YourServiceExectubable.exe

The source for this information was the following SO post: 32-bit Windows services in 64-bit environment

**Unfortunately, it appears corflags is applicable only for 2.0 assemblies, and was designed for specifically this type of problem. **

Community
  • 1
  • 1
David W
  • 10,062
  • 34
  • 60
0

This looks very similar to this question which might help you out: Starting a windows service fails with error 1053

A couple of other things to look out for:

  • Make sure you don't have either of the following statements in your deployed service:

    System.Diagnostics.Debugger.Launch

    System.Diagnostics.Debugger.Break

  • You may need to run the service with an account other than Local System (depending upon the permissions required by your service).

Community
  • 1
  • 1
Rick O
  • 121
  • 5
  • no sign of those lines of code, however, permissions may be a crucial point as I think I just fixed it, details above... – el_foz Sep 19 '12 at 17:39