🚨 Como corrigi um bug no MSIX que fazia apps Flutter para Windows crasharem na Windows Store

Introdução

Se você desenvolve apps Flutter para desktop Windows e publica na Windows Store usando o pacote msix, talvez o seu app esteja correndo um sério risco de crashar logo ao abrir — e você pode nem ter percebido.

Foi exatamente esse cenário que encontrei: localmente, tudo funcionava perfeito. Mas, depois de empacotar e enviar para a Store, o app simplesmente fechava assim que era aberto.

O que estava acontecendo

Recentemente, versões mais novas do Sentry passaram a gerar, durante a compilação, um executável extra chamado: crashpad_handler.exe

Ele é usado para coleta de dados de crash e não deveria afetar a execução normal do seu app.
O problema é que o msix (em versões anteriores) tinha uma lógica muito simples para definir o executável principal do pacote: procurava o primeiro .exe na pasta de build e usava ele como ponto de entrada.

Resultado: se o seu app não começasse com “A” ou “B” no nome, a chance era enorme de o crashpad_handler.exe ser o primeiro na ordem alfabética — e era ele que a Windows Store tentava abrir.

Obviamente, ele não é o seu app… então o resultado era um crash instantâneo.

Como identifiquei no MSIX

Ao inspecionar o XML de manifesto do MSIX, encontrei algo assim:

<Application Id="MyApp" Executable="crashpad_handler.exe" EntryPoint="Windows.FullTrustApplication">
    ...
</Application>

Ou seja, o empacotamento estava literalmente apontando para o executável errado.

O que foi alterado no PR

Enviei um Pull Request para o msix que muda completamente a forma como o executável principal é escolhido.

Agora o fluxo é assim:

1. Primeiro, lê o nome do binário diretamente do CMakeLists.txt (onde o Flutter para Windows define por padrão o nome do app).
2. Se não encontrar, lê o campo name do pubspec.yaml.
3. Se ainda assim não encontrar, cai no método antigo de varrer os .exe na pasta — mas agora ignorando explicitamente o crashpad_handler.exe.

Antes e depois

Antes:

• Qualquer .exe podia ser escolhido como principal.
• Alta chance de escolher o errado (especialmente crashpad_handler.exe).

Depois:

• Binário correto identificado pelo nome definido no projeto.
• crashpad_handler.exe nunca mais é usado como executável principal.

Imagens

1️⃣ O problema – crashpad_handler.exe listado primeiro

2️⃣ A solução – definindo o BINARY_NAME no CMakeLists.txt

3️⃣ Manifesto MSIX com o EXE errado

Essa mudança garante que seu app Flutter para Windows publicado na Store sempre aponte para o executável certo, evitando crashes e protegendo suas avaliações.

Se você mantém um app Flutter para Windows e usa o msix, vale atualizar para uma versão que já inclua essa correção.