.Net (C#) Service Fails To Start

[BravesCharm]

Still sounds like you might have a dependencies issue. Are you using
any other Windows services like MSMQ?

 

[Ken Allen]

Still sounds like you might have a dependencies issue. Are you using
any other Windows services like MSMQ?

No. One of the services does nothing but start the service thread, which
then instantiates the 'master' end of a pipe for communication from
other services (older code). The only code in the main() routine is
there to determine whether to instantiate the code as a service or as a
console application.

I have even placed debug code in the main() routine -- to produce Event
Log entries or to write to a disk file -- and if the service loads this
works fine, and if it fails no output whatsoever is produced. This leads
me to conclude that the main() routine is throwing some sort of
exception or the system initialization for the executable is failing,
but I can find no proof of this anywhere.

Oddly enough, if I modify the main() routine to contain any code that
performs file I/O, the problem seems to be far more difficult to
reproduce -- recently we have not been able to reproduce it at all. Even
simply having a line of code that reads as follows will seem to cause to
the problem to disappear: "Assembly.GetExecutingAssembly().Location;" (I
currently follow this line with another line that strips off the name of
the assembly in preparation for using the string to check for and even
read from another file in the same directory as the assembly itself).

I have two (2) services written in .Net and some older ones written in
C++, and the C++ services always atart, even when the .Net written
services do not. I can say that it is always a case of both of the .Net
services starting or neither of them starting, but I have not seen a
case where one of them starts and the other fails. This may be a side
effect of my experimienting with the one that is loaded first, so I
cannot be certain what this means.

-ken

 

[ThiloL]

is it possible that the .NET CLR isn't loaded entirely in this early
phase of the workstation startup? or something like that?

thilo.

 

[Willy Denoyette [MVP]]

is it possible that the .NET CLR isn't loaded entirely in this early
phase of the workstation startup? or something like that?

thilo.

Hold on, the CLR isn't loaded as a service or a self containing process,
it's loaded in the application process space, it's just a run-time ( a bunch
of DLL's) like there are others like the VB6 runtime.

Willy.

 

[Willy Denoyette [MVP]]

No. One of the services does nothing but start the service thread, which
then instantiates the 'master' end of a pipe for communication from other
services (older code). The only code in the main() routine is there to
determine whether to instantiate the code as a service or as a console
application.

I have even placed debug code in the main() routine -- to produce Event
Log entries or to write to a disk file -- and if the service loads this
works fine, and if it fails no output whatsoever is produced. This leads
me to conclude that the main() routine is throwing some sort of exception
or the system initialization for the executable is failing, but I can find
no proof of this anywhere.

My bet is that the (service) process didn't get started and obviously your
Main entry never called.
As I told you in another reply, the SCM creates the process for your
"service" by calling CreateProcessAs(..), things can go wrong when calling
this API, but the SCM should log an event when it fails.
One of the things that mostly fail is the creation of a logon session
(implicitely called by CreateProcessAs()) for the Service to run in, the
logon session is created using the identity as specified at service install
time. If the identity specified refers to a domain account and no DC is
reachable, the creation of the service process will fail (with an system and
security event logged).

So please apply Logon auditing using the Local Security Policy editor and
check your eventlog for Logon failures. Note that your service must depend
on Eventlog and RPCSS for this to work.

Willy.

 

[Ken Allen]

OK, we have finally located the source of the problem in our shop!

Our first clues came when we examined the size of the binaries that
worked and the ones that did not - those that failed were almost 6000
bytes larger! We initially suspected the build environment, but testing
on another system that was configured with all of the latest revisions
of the tools produced the same large files.

Then we noticed that files build manually were smaller than those built
by our automated build process, and then it came to light - the binaries
that failed were being digitally signed! It seems the signing tool adds
some information to the binary image, and this messes up the .Net
assemblies. It does not mess them up enough that they do not work, but
enough that they will not always work when invoked during the boot process!

We have removed the digital signing of the .Net assemblies in our
automated build process and the problem appears to have disappeared, for
us at least.

-ken

 

[Roland Riess]

Hi Ken,

I just happened to read this thread as I experienced the same problem a
couple of weeks ago. Up to now I did not find a solution so I am very
interested in yours. My problem is that I never intended to have a
digital signature and that I even do not know where it can be
de/-activated. I'd appreciate very much if you could give me a hint,
where I can change this in my project because it might solve my problem,
too.

How can I define any dependencies at compile time? The
ServiceInstaller permits me to define a list of services
to depend on

Up to now I did not find where I can do that. If you could also give me
a hint on that !?

Thanks alot
Regards
Roland

 

[BravesCharm]

Why not make a dump file using adplus -crash and than view the dump in
Windbg with SOS(Son Of Strike)?

 

[BravesCharm]

nevermind, adplus cannot get a crash dump a startup app.

 

[Thilo Langbein]

my service runs as "LocalSystem".

therefore "CreateProcessAs" is not the problem; I think.

the logon-event for "LocalSystem" in the eventlog - if the service
starts - is ok.

what else could I check?