Informações de arquivo de log

Você pode criar arquivos de log que registrem ações para as seguintes operações:

• Interoperar com código nativo.

• Carregamento de programas.

• Rede.

Para obter informações sobre as chaves do registro que controlam o registro e como gerar arquivos de registrar registrar registrar em log, consulte Como: Criar arquivos de log.

Este tópico descreve a gravação das informações nos arquivos de log para registro de interoperabilidade e de carregamento.

Arquivos de log interop

A saída para log de interoperabilidade consiste nas assinaturas das chamadas da função interop quando elas ocorrerem em tempo de execução, com quaisquer mensagens de erro.

A versão do .NET Compact estrutura 3.5 inclui suporte a registrar registrar registrar em log de interoperabilidade avançado, que é descrito no "Profundidade marshaling" seção mais adiante neste tópico.

Assinaturas de função

As assinaturas para tanto chamadas gerenciada a nativa quanto nativa a gerenciada são registradas, e inclui os seguintes tipos de chamadas:

• Chamada de invocação de plataforma.

• Chamadas COM vtable e Dispatch.

• Retornos de chamada delegados.

O registrar registrar registrar em log de interoperabilidade pode ajudá-lo a solucionar problemas quando você chamar ou retornar de uma telefonar de função interop, tais sistema autônomo quando um parâmetro não for inicializado sistema autônomo esperado ou quando o programa termina inesperadamente.

A saída para uma entrada de assinatura de função consiste de três linhas para cada chamada interop.A primeira linha fornece sinalizadores que identifiquem o tipo de telefonar de função feita e inclui um ou mais dos seguintes elementos:

• [pinvokeimpl]
  Identifica um gerenciado - para-nativo telefonar que utiliza o DllImportAttribute atributo.

• [Ctor]
  Identifica um construtor para uma classe assembly interop, gerado pelo Tipo Biblioteca Importer (Tlbimp.exe).

• [preservesig]
  Pressupõe que o gerenciado e nativo funções têm a mesma assinatura, com nenhuma tradução de HRESULT a exceção aplicada pelo tempo de execução.

• [delegate]
  Indica que a função é um retorno de chamada delegado nativo a gerenciado.O delegado atua como um ponteiro de função no código nativo.

A segunda linha do arquivo de log interop representa a assinatura gerenciada.Para chamadas de função nativa a gerenciada, esta linha identifica a função gerenciada que chama o código nativo.Para chamadas de função nativa a gerenciada, esta linha identifica a função gerenciada que está sendo chamada a partir de código nativo.

A terceira linha representa a assinatura nativa, como esperada pelo runtime.Esta linha identifica os tipos de dados para cada parâmetro e fornece informações sobre como os dados de objeto gerenciado estão empacotados.O tempo de execução assume que a que os tipos corretos estão especificados pelo DllImportAttribute atributo ou em COM definição de assinatura da interface. Falha ao especificar os tipos corretos é um erro comum que pode causar um comportamento inesperado, porque a função será executada com valores de parâmetro incorreto.

Cada tipo tem um tipo padrão de empacotamento.Observe que o comportamento de marshaling de um tipo gerenciado pode ser diferente para chamadas COM e DllImportAttribute ou delegado chamadas de retorno de chamada. Você pode usar o MarshalAsAttribute atributo para especificar um tipo de marshaling diferente do padrão. Você também deve usar o ref palavra-chave para identificar qualquer parâmetro que representa um ponteiro para um tipo de valor ou um ponteiro para um ponteiro para um tipo de referência.

A tabela a seguir mostra o log interop de uma invocação de plataforma.

A tabela a seguir mostra o log interop de um retorno de chamada delegado.

A tabela a seguir mostra o registrar registrar registrar em log interop de telefonar de função nativa a gerenciada COM, onde o tempo de execução retorna uma falha HRESULT se ocorrer uma exceção gerenciada.

Profundidade de marshaling

O .NET Compact estrutura versão 3.5 também oferece suporte a profundidade de marshaling para o registrar registrar registrar em log interop.No marshaling de profundidade, as informações são registradas sobre empacotadas como objetos que estão contidos em estruturas ou em tipos de referência.

Mostra a saída de log seguir um exemplo de uma plataforma de invocação de telefonar que utiliza objetos empacotados contidos em uma estrutura.A primeira linha da profunda marshaling seção especifica o motivo pelo qual o empacotador profunda foi chamado.Neste exemplo, ele foi chamado para calcular o dimensionar da estrutura.O log mostra o tipo de dados e o dimensionar em bytes, de cada objeto.Os valores de índice (por exemplo, 0004) representam o byte desloca para as variáveis especificadas.

DEEP MARSHAL: Get size
struct interoplogging.MyStruct
{
0000: Int32 myVar as Int32 (4 bytes)
0004: Int32 myVar2 as Int32 (4 bytes)
0008: String myString as WCHAR[10] (20 bytes)
}
DEEP MARSHAL: Total size = 28 bytes

[pinvokeimpl][preservesig]
void  interoplogging.Form1::MyAPI(interoplogging.MyStruct );
void MyAPI(MyStruct (NONBLIT_VALUETYPE_VAL) );

DEEP MARSHAL: Managed -> Native
struct interoplogging.MyStruct
{
0000: Int32 myVar as Int32 (4 bytes)
0004: Int32 myVar2 as Int32 (4 bytes)
0008: String myString as WCHAR[10] (20 bytes)
}
DEEP MARSHAL: Total size = 28 bytes

Mensagens de erro

Algumas situações e exceções podem causar mensagens a serem registradas no arquivo de log.Essas mensagens podem ser especialmente útil quando você estiver investigando problemas que envolvem interoperação com componentes nativos e DLLs para os quais o código-fonte nativo não está disponível.Você pode usar mensagens de erro para ajudar nas seguintes questões:

• Chamada de função nativa a gerenciada.

• Chamadas de interface de tempo de execução COM.Um erro HRESULT pode ser retornado para código nativo quando uma função de interface COM implementada pelo tempo de execução é chamada.Existem várias interfaces implementadas em tempo de execução (incluindo IUnknown, IDispatch, IConnectionPointContainer, IEnumConnectionPoints, e IConnectionPoint) que pode chamar código nativo usando um objeto gerenciado empacotado sistema autônomo uma interface COM. Quando uma telefonar de função retorna um erro ao código nativo em uma dessas interfaces, o tempo de execução imprime uma mensagem de erro apropriada que inclui o HRESULT e informações adicionais relevantes.

• Código nativo que espera para usar a funcionalidade sem suporte, sistema autônomo IDispatch::GetTypeInfo.

• Interfaces não implementadas.Código nativo poderá receber uma mensagem de erro E_NOINTERFACE de IUnknown::QueryInterface onde ele espera o objeto COM gerenciado para implementou uma interface adicional. Nesse caso, o GUID da interface não implementada também é fornecido.

• Exceções gerenciadas.Isso podem ocorrer dentro do gerenciado função telefonar e fazer com que ela retorne prematuramente.Quando você faz uma telefonar COM, o tempo de execução converte a exceção em uma falha HRESULT valor, que retorna ao código nativo.No entanto, se um retorno de telefonar delegado ou telefonar de COM não espera um HRESULT valor retornado, poderá ser feita se tornará ciente de que o erro e você poderá ver um comportamento inesperado sistema autônomo resultado.O log interop conterá uma mensagem de erro quando ocorre uma exceção durante uma nativo - para - gerenciado telefonar de função interop.Esta mensagem ajudará a identificar gerenciado funções que precisam de lógica de manipulação de erros adicional para funcionar bem com código nativo.Os seguintes fatores podem causar uma exceção gerenciada:

  • Usar tipos em sua definição de interface COM ou DllImportAttribute assinatura que não são suportados pelo .NET Compact estrutura causará uma exceção ocorra durante o processo de compilação JIT. Existem freqüentemente opções alternativas que são aceitáveis, tal sistema autônomo usar um IntPtr.

  • Quando tanto o objeto atual não puder ser forçado para o tipo especificado na assinatura quanto os dados do objeto não puderem ser convertidos para o tipo solicitado, uma exceção é lançada em tempo de execução quando a função é chamada.Isso geralmente ocorre quando você converter um objeto nativo em um objeto gerenciado.

  • Determinando o que causa uma exceção quando você cria um tempo de execução callable wrapper (RCW) ou um COM callable wrapper (CCW) é difícil.O arquivo de log interop pode ajudar a determinar a causa desses problemas quando uma mensagem de erro detalhada não é fornecida com a exceção gerenciada.

Diferenças com o .NET Framework

Existem diferenças entre a implementação do .NET Compact estrutura da interoperabilidade COM e que o .NET estrutura completo.O .NET Compact Framework não oferece o suporte a seguir:

• Criação de um CCW contém uma interface sem um GUID especificado.

• Criando um RCW para uma classe que herda de uma classe assembly interop.

• Criação de um CCW contém uma interface não genérico com um método genérico.

RCWs são frequentemente limpos após a finalização, mas você também pode usar o ReleaseComObject ou FinalReleaseComObject método para liberar o RCW associado com um objeto. Se você estiver usando essas opções avançadas gerenciar o tempo de vida dos objetos do e tentar usar o objeto após foi liberada para tornar um nativo COM telefonar, uma exceção é lançada e o arquivo de log contém uma mensagem de erro sobre a causa da exceção.

Arquivos de log loader

Arquivos de log loader consistem em duas seções: um cabeçalho e um corpo.O cabeçalho do arquivo de log contém os seguintes dados:

• Nome do executável principal do aplicativo.

• ID de processo sistema autônomo atribuído pelo sistema operacional.

• Data e hora que o arquivo de log foi criado.

• Versão do .NET Compact estrutura usada para executar o aplicativo.

• Informações sobre a plataforma na qual o seu aplicativo está sendo executado.

O corpo do arquivo de log inclui informações de diagnóstico sobre cada assembly quando ele é carregado pelo seu aplicativo.Essas informações podem ajudar a você encontrar erros encontrados pelo carregador de classe sistema autônomo seu aplicativo é iniciado.

O corpo do arquivo de log contém os seguintes dados:

• Estado de coerção, que indica se o aplicativo foi executado no modo de compatibilidade com versões anteriores.

• Rastreamento para cada carregamento assembly, incluindo a partir de onde o assembly foi carregado e qual versão foi carregada.

• Nível de confiança atribuído a cada módulo quando ele é carregado.

• Quaisquer arquivos de configuração associados ao seu aplicativo.

• Falha ao localizar métodos, tipos, assemblies e módulos.

• Falha ao localizar uma DLL nativa ou uma função de uma invocação de plataforma chamadas.

A tabela a seguir mostra um exemplo de um arquivo de log loader.Os números de linha são aproximados.

As duas últimas entradas (carregamento e carregado) são registradas para cada módulo.Elas identificam os assemblies e suas localizações.Os erros ao carregar um módulo são indicados no log loader.

Exemplos de erros

Os dois exemplos nesta seção mostram como você pode usar o arquivo de log loader para determinar quando erros são encontrados.

Este exemplo a seguir mostra as entradas de log são gravadas quando o carregador não encontra um assembly.

Loading module [\Program Files\VW\Golf.dll]
Attempt to load [\Program Files\VW\Golf.dll] has failed (err 0x80001000).
Loading module [\Program Files\VW\Golf.exe]
Attempt to load [\Program Files\VW\Golf.exe] has failed (err 0x80001000).
Failed to load [Golf, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null]

O exemplo a seguir mostra as entradas de log são gravadas quando o carregador não encontra um tipo específico.

Missing Type. Type [Cars.Jetta], Assembly [Cars].
Missing Type. Class [Cars.Jetta], Assembly [Cars, Version=5.0.0.0, 
Culture=neutral, PublicKeyToken=null].

Consulte também

Tarefas

Como: Criar arquivos de log

Como: Configurar o tempo de execução versão

Conceitos

Tópicos "como" do .NET compact estrutura

Outros recursos

Interoperabilidade no .NET Compact Framework

Desempenho e o diagnóstico no .NET Compact estrutura