Quando uma aplicação C# invoca uma biblioteca dinâmica (DLL) escrita em C++, a falha raramente reside na lógica de negócio de uma das linguagens isoladamente. O problema costuma ser o rompimento do contrato da Application Binary Interface (ABI). Erros como System.EntryPointNotFoundException ou AccessViolationException são sintomas de que o "acordo" de baixo nível entre o gerenciado (.NET) e o não gerenciado (Nativo) foi violado.

Para resolver esses problemas de forma sistemática, é necessário analisar o fluxo de dados e execução através de quatro camadas críticas de abstração. Cada camada atua como um filtro: se uma falha, as subsequentes tornam-se irrelevantes.

O Fluxo de Diagnóstico de Erros de ABI

As exceções lançadas pelo runtime do .NET podem ser mapeadas diretamente para camadas específicas da ABI. Seguir esta hierarquia reduz drasticamente o tempo de depuração em cenários de integração complexos:

Sintoma no C# → Camada de Ruptura → Causa Raiz → Ferramenta de Validação
│
├─ EntryPointNotFoundException → Camada de Visibilidade → Símbolo não exportado ou "Mangled" → dumpbin /exports
├─ SEHException (0xE06D7363) → Camada de Runtime → Incompatibilidade de CRT (ex: /MD vs /MT) → depends.exe / lucy.exe
├─ AccessViolationException → Layout de Dados → Desalinhamento de Struct (Padding) → offsetof() / Marshal.OffsetOf
└─ MarshalDirectiveException → Convenção de Chamada → Conflito entre __stdcall e __cdecl → objdump -t / Visual Studio Debugger

1. Camada de Visibilidade de Símbolos

Esta é a causa mais comum de falhas iniciais. O fato de uma função existir no código C++ não garante que ela esteja acessível para o P/Invoke do C#. No Windows, a exportação de símbolos exige uma configuração explícita.

O Problema do "Name Mangling": Por padrão, o compilador C++ decora os nomes das funções (ex: ExecuteTask vira ?ExecuteTask@@YAHH@Z) para suportar sobrecarga. O C# busca pelo nome exato, a menos que especificado de outra forma. O uso de extern "C" é obrigatório para evitar essa decoração.

Exemplo de implementação correta no C++:

// No arquivo .cpp para garantir a exportação física
extern "C" __declspec(dllexport) int __stdcall ProcessDataBuffer(unsigned char* buffer, int length) {
    // Lógica de processamento
    return 0;
}

Para validar se o símbolo foi realmente exportado e qual seu nome exato, utilize o utilitário dumpbin no Prompt de Comando do Desenvolvedor do Visual Studio:

dumpbin /exports sua_biblioteca.dll

Se o nome da função não aparecer na lista ou estiver acompanhado de caracteres especiais, o P/Invoke falhará antes mesmo de eniciar a execução.

2. Camada de Convenção de Chamada

A convenção de chamada define quem é responsável por limpar a pilha (stack) após a execução da função: o chamador (Caller) ou a função chamada (Callee). No ecossistema Windows/x86, o conflito mais comum é entre __cdecl (padrão C++) e __stdcall (padrão Win32 API e esperado por muitas declarações C#).

No C#, a declaração deve ser explícita para evitar corrupção de memória silenciosa:

[DllImport("sua_biblioteca.dll", CallingConvention = CallingConvention.StdCall)]
public static extern int ProcessDataBuffer(IntPtr buffer, int length);

Se houver uma divergência, você poderá enfrentar um StackImbalance. Em arquiteturas x64, esse problema é menos frequente devido à padronização da convenção de chamada, mas ainda é uma boa prática manter a consistência nas definições.

3. Camada de Layout e Alinhamento de Dados

Quando estruturas (structs) são passadas entre C# e C++, ambos os lados devem concordar exatamente sobre onde cada campo começa e termina na memória. O alinhamento de memória (Padding) pode variar entre compiladores ou configurações de projeto.

Se o C++ utiliza #pragma pack(push, 4) e o C# assume o alinhamento padrão de 8 bytes, os dados lidos pelo código nativo estarão deslocados, resultando em valores corrompidos ou falhas de segmentação.

Exemplo de sincronização de layout:

[StructLayout(LayoutKind.Sequential, Pack = 4)]
public struct DeviceConfig {
    public int DeviceId;
    public double SampleRate;
}

4. Camada de Dependências de Runtime

Muitas vezes, a DLL falha ao carregar porque suas próprias dependências não estão presentes no sistema de destino. Um erro comum é compilar a DLL C++ em modo "Debug" (que depende de msvcp140d.dll) e tentar executá-la em uma máquina que possui apenas o redistribuível de "Release".

Além disso, o conflito entre /MT (Static Runtime) e /MD (Dynamic Runtime) pode causar problemas se a memória for alocada em um heap e liberada em outro. Certifique-se de que a gerência de memória seja feita preferencialmente por quem alocou o recurso, ou utilize alocadores globais como o CoTaskMemAlloc.