Windows 7, 64 bits, problemas com DLL

Estou com um problema com o nosso executável. Estou executando este executável C ++ de 32 bits na caixa de desenvolvimento do Windows 7 de 64 bits que também possui todos os aplicativos da Microsoft (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office) ... E ainda está funcionando perfeitamente.

Agora, obtive a instalação do cliente do mesmo programa e fui solicitado a testá-lo com uma instalação limpa do Windows 7. Portanto, adquiri um VMware do Windows 7 de 64 bits e o atualizei para o Windows 7 SP 1 (a mesma versão que minha caixa do desenvolvedor está ajustando). Mas enquanto estiver na minha caixa do desenvolvedor, tudo está bem, o programa não funciona com a caixa do VMware (30 dias de teste).

O x86 Dependency Walker está me dizendo que os seguintes arquivos DLL estão ausentes:

• API-MS-WIN-CORE-COM-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
• API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
• API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
• DCOMP.DLL
• GPSVC.DLL
• IESHIMS.DLL

Pesquisei esses arquivos DLL do API-MS-WIN -... e descobri que eles já deveriam fazer parte do Windows 7 (embora alguns sites afirmem pertencer ao Windows 8 e Windows Server 2012).

Eu já tentei as correções sugeridas que encontrei, que são:

• executando 'sfc / scannow'
• instalando executáveis ​​de tempo de execução do Visual Studio 2008 SP1

Mas isso não resolveu nada. :-(

Nota lateral: Minha caixa de desenvolvimento também não os possui e parece não precisar deles. Por exemplo, o user32.dll na minha caixa não se vincula a um deles, enquanto a instalação no VMware o faz.

Alguma idéia de como corrigir esse problema? Tentei encontrar um download / correção adequado nas páginas da Microsoft, mas falhei.

Depois de resolver meu problema, eu queria relatar o que descobri e não posso postar isso como resposta porque a pergunta foi encerrada.

Na verdade, todos os arquivos DLL relatados como ausentes pela ferramenta Dependency Walker, ou seja, aqueles

* API-MS-WIN-CORE-...

arquivos DLL do tipo não faziam parte do problema real.

No meu caso, o registro de três arquivos OCX estava ausente e, depois disso, tudo estava bem, mas a ferramenta Dependency Walker ainda listava todos os mesmos arquivos DLL de antes, mesmo quando o programa estava funcionando bem agora.

O essencial: como alguém já afirmou, a ferramenta está um pouco datada e nem sempre funciona corretamente com um sistema operacional mais recente. Portanto, fique de olho e não se engane pela falta de 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... o problema provavelmente está inteiramente em outro lugar.

Esse problema está relacionado à falta do "pacote redistribuível" do Visual Studio. Não é óbvio qual deles está faltando com base na caminhada de dependência, mas eu tentaria o que corresponde à sua versão do compilador primeiro e ver se as coisas funcionam corretamente:

Visual Studio 2015

Visual Studio 2013

Visual Studio 2010

Visual Studio 2008

Corri para esse problema porque estou usando os compiladores do Visual Studio, mas não o ambiente completo do Visual Studio.

Vai ousar injetar um novo link aqui: Os mais recentes downloads suportados do Visual C ++ . Stein Åsmul, 29.11.2018 .

Acabei de resolver o mesmo problema com o C ++ Qt 5 e o Windows 7 64 bits com o MSCVC 2012.

No começo, eu pensava que era um problema de arquivo DLL do MSVC / Windows, mas como o BorisP disse, o problema estava nas dependências do meu projeto. A chave é " Como conhecer as dependências do seu projeto no Qt 5? ".

Como não encontrei uma maneira clara de conhecê-lo (o Dependency Walker não me ajudou muito ...), segui o "procedimento inverso" que leva não mais de 5 minutos e evito muitas dores de cabeça com a DLL dependências de arquivo:

1. Compile seu projeto e leve o arquivo executável para uma pasta vazia: myproject.exe
2. Tente executá-lo, ele recuperará um erro (faltando arquivos DLL ...).
3. Agora, copie todos os arquivos DLL do Qt (no meu caso, eles estavam em C: \ Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012_64_opengl \ bin) para esta pasta.
4. Tente executar novamente, provavelmente funcionará bem.
5. Comece a excluir progressivamente e tente sempre que seu executável ainda funcionar, tentando deixar os arquivos DLL mínimos necessários.

Quando você tem todos os arquivos DLL na mesma pasta, é mais fácil descobrir quais deles não são válidos (XML, WebKit, ... seja o que for ..) e, consequentemente, esse método não leva mais de cinco minutos.

Acabei de resolver o mesmo problema.

Dependência Walker é enganosa neste caso e me levou a perder tempo. Portanto, a lista de arquivos DLL "ausentes" da primeira postagem não é útil e você provavelmente pode ignorá-lo.

A solução é descobrir quais referências seu projeto está chamando e verificar se elas estão realmente instaladas no servidor.

@ Ben Brammer, não é importante quais os três arquivos .ocx que estão faltando, porque estão faltando apenas para o projeto de Leo T Abraham. Seu projeto provavelmente chama outros arquivos DLL.

No meu caso, não eram três arquivos .ocx, mas o arquivo DLL do conector MySQL ausente. Após a instalação do MySQL Connector for .NET no servidor, o problema desapareceu.

Portanto, em resumo, a solução é: verifique se todas as referências do seu projeto estão lá.

Como mencionado, o DCOMP faz parte dos redistribuíveis do VC ++ (implementando o tempo de execução OpenMP) e é o único componente realmente ausente. Todo o resto são relatos falsos.

Especificamente, API-MS-WIN-XXXX.DLL são conjuntos de APIs - essencialmente, um nível extra de indireção de chamadas introduzido gradualmente desde o Windows 7. O desenvolvimento do Dependency Walker aparentemente parou muito antes disso e não pode lidar com os conjuntos de APIs corretamente.

Portanto, não há nada com o que se preocupar. Você não está perdendo mais nada.

Uma alternativa melhor para encontrar os arquivos DLL realmente necessários que estão faltando (se esse é realmente o problema) é executar o Process Monitor e retroceder a partir da falha, procurando sequências de probes com falha para um arquivo DLL específico em todo o caminho do sistema.

Também encontrei esse problema, mas a solução que parece ser um tópico comum aqui, e vi em outros lugares da Web, é "[re] instalar o pacote redistribuível". No entanto, para mim isso não funciona, pois surgiu o problema ao executar o instalador do nosso produto (que instala o pacote redistribuível) para testar nossas novas e brilhantes versões do Visual Studio 2015.

O problema surgiu porque os arquivos DLL listados não estão localizados no caminho de instalação do Visual Studio (por exemplo, C: \ Arquivos de Programas (x86) \ Microsoft Visual Studio 14.0 \ VC \ redist) e, portanto, não foram adicionados à instalação. Essas api-ms-win- * dlls são instaladas em um caminho de instalação do Windows 10 SDK como parte da instalação do Visual Studio 2015 (por exemplo, C: \ Arquivos de Programas (x86) \ Windows Kits \ 10 \ Redist).

A instalação no Windows 10 funcionou bem, mas a instalação no Windows 7 exigiu a adição desses arquivos DLL à instalação do produto. Para obter mais informações, consulte Atualização para o Universal C Runtime no Windows, que descreve a adição dessas dependências causadas pelo Visual Studio 2015 e fornece downloads para várias plataformas Windows; veja também Introdução ao Universal CRT, que descreve o redesenho das bibliotecas CRT. De particular interesse é o item 6 na seção intitulada Distribuindo software que usa o Universal CRT :

Atualizado em 11 de setembro de 2015: A implantação local do aplicativo do Universal CRT é suportada. Para obter os binários para implantação local do aplicativo, instale o SDK (Windows Software Development Kit) para Windows 10. Os binários serão instalados em C: \ Arquivos de Programas (x86) \ Windows Kits \ 10 \ Redist \ ucrt. Você precisará copiar todas as DLLs com seu aplicativo (observe que o conjunto de arquivos DLL é necessário é diferente em diferentes versões do Windows, portanto, você deve incluir todos os arquivos DLL para que seu programa seja executado em todas as versões suportadas do Windows).

Essa contribuição não responde realmente à pergunta inicial, mas, levando em consideração a taxa de acertos desse segmento, presumo que existem poucas pessoas lidando com o problema que as bibliotecas API-MS-WIN-CORE não podem ser encontradas.

Consegui resolver um problema em que meu aplicativo se recusou a iniciar com a mensagem de erro que API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL não foi encontrada, basta atualizar o Visual Studio.

Eu não acho que meu ambiente de criação (Windows 7 Pro SP1, Visual Studio Ultimate 2012) tenha sido completamente confuso, funcionou bem na maioria dos meus projetos. Mas, em algumas circunstâncias muito específicas, recebi a mensagem de erro (veja abaixo).

Depois de atualizar o Visual Studio 11 da versão inicial do CD (esqueci de procurar o número da versão) para a versão 11.0.61030.00 Atualização 4 também o projeto quebrado estava em execução novamente.

Isso resolveu o problema para mim:

Desinstale o pacote redistribuível do Visual Studio 2010 se você já o tiver instalado e instale o Microsoft Windows 7 SDK .

Eu resolvi o problema. Quando registrei os arquivos OCX, executei-os com a janela de comando que havia sido executada como administrador.

Para quem veio aqui, mas com um problema do Photoshop : minha solução foi desinstalar o MS VC ++ redistribuível primeiro x86 e 64, ambos. Em seguida, instale um apropriado para a versão e a arquitetura do Windows (86 ou 64).

A instalação do SQL Server Management Studio 2014 em um Windows 7 recém-instalado resolveu esse problema em nosso cliente após uma batalha ridícula de dois dias.

Eu tive o mesmo problema. Depois de passar horas pesquisando na web, encontrei uma solução para mim.

Copiei o arquivo combase.dll (C: \ Windows \ System32) para a pasta de lançamento e resolvi o problema.

Eu vim aqui com esse problema, depois de tentar uma nova instalação do Windows 7 OEM, atualizando para o Windows 10.

Após algumas pesquisas nos fóruns da Microsoft, encontrei a seguinte solução que funcionou para mim:

Substitua C:\Windows10Upgrade\wimgapi.dllpor um deC:\Windows\System32\wimgapi.dll

Sugiro também verificar a quantidade de memória atualmente sendo usada.

Acontece que a incapacidade de encontrar esses arquivos DLL foi o primeiro sintoma exibido ao tentar executar um programa (executar ou depurar) no Visual Studio.

Depois de mais de meia hora com muito esforço, pesquisando na web, executando o Process Monitor e o Gerenciador de tarefas , e depende, um programa completamente diferente que estava sendo executado desde o início dos tempos relatava que "a memória está baixa; tente interromper alguns programas" ou algo assim. Depois de matar o Firefox, Thunderbird, Process Monitor e depende, tudo funcionou novamente.

Apenas para confirmar as respostas aqui, minha resolução foi copiar a DLL que não estava carregando E o arquivo ocx que a acompanhava na pasta system32, que resolveu meu problema.