.NET App pendurado no Windows 2012 na inicialização

2

Temos um cliente que nos forneceu um servidor Windows 2012 Hyper-V que possui um Windows 2012 Multipoint guest no qual executamos nossos produtos de software baseados em .NET (v3.5).

Infelizmente, há várias máquinas que nossos serviços do Windows não inicializam. Cada um deles escreve no log antes de qualquer outra coisa , por exemplo:

<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
'...

O problema é que essa string de depuração nunca faz isso no Dbgview, nem o programa usa qualquer CPU (sempre fica em 0% e o serviço terminará o tempo limite.

Temos um switch que podemos adicionar ao serviço para poder executá-lo como um aplicativo WinForms para testar coisas como essa, quando tento executá-lo com esse switch, o programa leva cerca de 2 minutos para chegar ao primeiro. linha e saída desta string de depuração, então não é de admirar que o serviço não tenha começado!

Eu liguei o Fusion e ele gera os logs de fusão muito bem e parece que não houve nenhum erro, mas estou perdido a respeito de por que esses aplicativos .NET demoram tanto para chegar à nossa base de código?

Temos muitos outros clientes (embora nenhum use o Windows 2012) e isso só acontece em várias máquinas. A contagem de assembly dependente não é mais do que uma dúzia e o aplicativo inteiro é menor que 4 MB.

Alguém poderia sugerir como investigar isso mais ...?

O visualizador de eventos parece vazio, com a exceção de "O serviço não respondeu à solicitação de início ou controle em tempo hábil".?

A especificação do convidado é 4CPUs e 4GB de RAM, o disco rígido tem muito espaço.

ATUALIZAÇÃO: Estranhamente o problema parece ir embora quando há uma conexão de internet fornecida à máquina ?? Agora, nosso software não exige isso (já que assumimos que isso está sendo executado em um site sem acesso), mas talvez haja algumas verificações de licenciamento necessárias ou uma política de grupo que dependa de um servidor que não esteja presente em nossa rede. ? (Eles nos deram um clone de uma máquina do laboratório deles). Alguma idéia?

    
por tommed 22.08.2013 / 18:51

1 resposta

0

Isso geralmente é causado pelo .Net Framework tentando verificar assinaturas em todos os assemblies que você está carregando. Microsoft várias KBs e blog posts sobre esse assunto, e a resposta curta é que você pode desativá-lo em machine.config ou na% do aplicativoconfig file:

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

A resposta longa é bem explicada por 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.

Se você estiver em uma rede de acesso restrito, cada chamada ao ponto de distribuição da CRL terá que expirar, possivelmente colocando o atraso acima de 2 minutos.

Em termos de depuração, você normalmente pode solucionar esse tipo de interrupção, invadindo o código em um depurador e observando a pilha de chamadas. Algo tão simples quanto o Process Explorer deve ser capaz de carregar símbolos e mostrar que você está esperando em uma CRL.

    
por 24.01.2014 / 05:41