Home / server / Questions / 533007
In Process
tommed
Asked: 2013-08-23 08:51:11 +0800 CST

.NET App hanging on Windows 2012 on startup

  • 772

We have a customer that has supplied us with a Window 2012 Hyper-V server that has a Window 2012 Multipoint guest os which we run our .NET-based (v3.5) software products on.

Unfortunately there are a number of machines which our windows services will not start-up. Each of them writes to the log before anything else, eg:

<DllImport("Kernel32.dll", _
            SetLastError:=True, _
            CharSet:=CharSet.Unicode, _
            entrypoint:="OutputDebugString", _
            CallingConvention:=CallingConvention.StdCall)> _
Public Shared Sub OutputDebugString(ByVal str As String)
End Sub

Protected Overrides Sub OnStart(ByVal args() As String)
    OutputDebugString("Service is starting...")
    m_worker = New Thread(AddressOf serviceThread)
    m_worker.Start()
End Sub
'...

The problem is this debug string never makes it into Dbgview, nor does the program use any CPU (it always sits on 0% and the service will eventually timeout.

We have a switch that we can add to the service to be able to run it as a WinForms application to testing things like this, when I attempt to run it with this switch, the program takes about 2 minutes to reach the first line and output this debug string so no wonder the service didn't start!!

I switched on Fusion and it generates the fusion logs just fine and there don't seem to be any errors, but I'm lost as to why these .NET apps take so long to get to our code-base?

We have many other customers (though none are using Windows 2012) and this only happens on a number of machines. The dependent assembly count is no more than a dozen and the entire application is less than 4MB.

Could anyone suggest how to investigate this further..?

Event viewer seems empty with the exception of "The service did not respond to the start or control request in a timely fashion."..?

Guest spec is 4CPUs and 4GB RAM, hard disk has plenty of space.

UPDATE: Strangely the problem seems to go away when there is an internet connection supplied to the machine?? Now our software doesn't require this (as we assume this is running on a site with no access) but perhaps there are some licensing checks that needed to happen or a group policy that relies on a server that isn't present on our network? (They did give us a clone of a machine from their lab). Any ideas?

windows

1 Answers

  1. This is typically caused by the .Net Framework attempting to verify signatures on all of the assemblies you are loading. Microsoft has several KBs and blog posts on this subject, and the short answer is that you can disable it in machine.config or in the application's config file:

    <configuration>
    <runtime>
        <generatePublisherEvidence enabled="false"/>
    </runtime>
</configuration>

    The long answer is nicely explained by shawnfa:

    When the CLR loads an assembly which has an Authenticode signature, it will always try to verify that signature. This is in contrast to the Windows loader, which will verify the signature of a file only in specific instances, such as when the file is an ActiveX control. This verification can be quite time intensive, since it can require hitting the network several times to download up to date certificate revocation lists, and also to ensure that there is a full chain of valid certificates on the way to a trusted root. So, when an Authenticode signature is applied to an assembly it's not unheard of to see a several second delay while that assembly is being loaded.

    If you are on a restricted access network, each call to the CRL distribution point will have to timeout, potentially putting the delay above 2 minutes.

    In terms of debugging, you can typically troubleshoot this sort of hang by breaking into the code in a debugger and looking at the call stack. Something as simple as Process Explorer should be able to load symbols and show that you are waiting on a CRL.

    • 0