Windows 7, 64 bits, problèmes de DLL


268

J'ai un problème avec notre exécutable. J'exécute cet exécutable C ++ 32 bits sur ma boîte de développement Windows 7 64 bits qui contient également toutes ces applications Microsoft (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office) ... Et il fonctionne toujours très bien.

Maintenant, j'ai obtenu l'installation client du même programme et on m'a demandé de le tester avec une installation propre de Windows 7. J'ai donc obtenu un VMware Windows 7 64 bits et l'ai mis à jour vers Windows 7 SP 1 (la même version que ma boîte de développeur est en train de régler). Mais alors que sur ma boîte de développeur tout va bien, le programme ne fonctionne pas avec la boîte VMware (essai de 30 jours).

Le x86 Dependency Walker me dit que les fichiers DLL suivants sont manquants:

  • 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

J'ai recherché ces fichiers DLL API-MS-WIN -... sur Google et j'ai constaté qu'ils devraient en fait déjà faire partie de Windows 7 (certains sites prétendant cependant appartenir à Windows 8 et Windows Server 2012).

J'ai déjà essayé les correctifs suggérés que j'ai trouvés, qui sont:

  • exécution de 'sfc / scannow'
  • installation des exécutables d'exécution de Visual Studio 2008 SP1

Mais cela n'a rien résolu. :-(

Note latérale: ma boîte de développement ne les a pas non plus et ne semble pas en avoir besoin. Par exemple, le user32.dll sur ma boîte n'est pas lié à l'un d'eux, contrairement à l'installation sur le VMware.

Une idée sur la façon de résoudre ce problème? J'ai essayé de trouver un téléchargement / correctif approprié sur les pages Microsoft, mais j'ai échoué.


Après avoir résolu mon problème, je voulais rapporter ce que j'ai découvert et je ne peux pas poster ceci comme réponse car la question a été fermée.

En fait, tous les fichiers DLL signalés manquants par l'outil Dependency Walker, à savoir ceux

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

les fichiers DLL de type ne faisaient pas partie du problème réel.

Dans mon cas, l'enregistrement de trois fichiers OCX était manquant et après cela, tout allait bien, mais l'outil Dependency Walker répertoriait toujours tous les mêmes fichiers DLL qu'avant même lorsque le programme fonctionnait bien maintenant.

L'essentiel: comme quelqu'un l'a dit ailleurs, l'outil est un peu daté et ne fonctionne pas toujours correctement avec un système d'exploitation plus récent. Gardez donc l'œil ouvert et ne vous trompez pas en manquant 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... le problème réside probablement entièrement ailleurs.


1
DirectComposition n'est pas disponible sur Windows 7 pour autant que je sache (DCOMP.DLL).
Brian

156
Que diriez-vous de rouvrir cela? Ma recherche sur Google m'a amené à cette question à peine 20 heures après sa fermeture pour être "peu susceptible d'aider les futurs visiteurs" ...
Christian Severin

27
quels 3 fichiers ocx avez-vous dû enregistrer, et surtout, comment avez-vous compris cela? Je suis coincé là-dessus depuis quelques jours maintenant
Ben Brammer

2
Salut à tous. Je pense que j'ai cloué celui-ci (voir ci-dessous), mais en remarque, vous pouvez ignorer en toute sécurité l'échec de la liaison avec IESHIMS.DLL et GPSVC.DLL. Il apparaît dans pratiquement tout ce que je compile dans Win7 et semble n'avoir aucune conséquence sur la fonction. Cette expérience provient maintenant d'environ 30+ binaires. soupir je déteste-déteste-déteste faire des dev pour windows pour des raisons comme ça.
meawoppl

3
Les modifications du noyau de Windows 7 qui ont conduit à des DLL api-ms-win- * sont expliquées assez bien ici nirsoft.net/articles/windows_7_kernel_architecture_changes.html - je pense que DependencyWalker ne peut tout simplement pas gérer ces changements - alors ne vous inquiétez pas trop. De MS: msdn.microsoft.com/en-us/library/hh802935%28v=vs.85%29.aspx
x29a

Réponses:


63

Ce problème est lié à l'absence du «package redistribuable» de Visual Studio. Il n'est pas évident de savoir lequel est manquant en fonction de la marche des dépendances, mais j'essaierais d'abord celle qui correspond à la version de votre compilateur et voir si les choses fonctionnent correctement:

Visual Studio 2015

Visual Studio 2013

Visual Studio 2010

Visual Studio 2008

J'ai rencontré ce problème car j'utilise les compilateurs Visual Studio, mais pas l'environnement Visual Studio complet.


Aller à oser injecter un nouveau lien ici: Les derniers téléchargements Visual C ++ pris en charge . Stein Åsmul, 29.11.2018 .



1
En outre, il semble que cela puisse être dû à l'installation des packages redistribuables sur certaines versions de Win 7. Merci m $.
meawoppl

Moi aussi, j'ai eu des problèmes avec cela et je pense qu'il existe plusieurs façons de le résoudre. Dans mon cas, j'ai remarqué que la compilation avec la configuration de débogage empêchait ma DLL de s'enregistrer. Cependant, quand j'ai changé ma configuration pour la libérer, j'ai pu avoir un enregistrement propre. Mon environnement est VS 2012. Et j'ai copié les fichiers redist appropriés (version x64) dans le même dossier que ma dll de com.
Jim Kennedy

NB certains des nouveaux SDK / DDK gagnent également avec certains d'entre eux!
meawoppl

1
VS2015 vcredist _ *. Exe installe ces DLL, mais pas d'autres méthodes, comme les MSM fournis avec VS. vcredist inclut ces DLL et vous aurez besoin de la plate-forme minimale requise. (Notez que j'ai dû installer Windows 7 SP1 deux fois pour qu'il prenne effet - WU
ment

19

Je viens de résoudre le même problème avec C ++ Qt 5 et Windows 7 64 bits avec MSCVC 2012.

Au début, je pensais que c'était un problème de fichier DLL MSVC / Windows, mais comme BorisP l'a dit, le problème était dans les dépendances de mon projet. La clé est " Comment connaître les dépendances de votre projet dans Qt 5? ".

Comme je n'ai pas trouvé de moyen clair de le savoir ( Dependency Walker ne m'a pas beaucoup aidé ...), j'ai suivi ensuite la "procédure inverse" qui ne prend pas plus de 5 minutes et évite beaucoup de maux de tête avec DLL dépendances de fichiers:

  1. Compilez votre projet et placez le fichier exécutable dans un dossier vide: myproject.exe
  2. Essayez de l'exécuter, il récupérera une erreur (fichiers DLL manquants ...).
  3. Maintenant, copiez tous les fichiers DLL de Qt (dans mon cas, ils étaient dans C: \ Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012_64_opengl \ bin) dans ce dossier.
  4. Essayez d'exécuter à nouveau, cela fonctionnera probablement très bien.
  5. Commencez à supprimer progressivement et essayez à chaque fois que votre exécutable fonctionne toujours, en essayant de laisser le minimum de fichiers DLL nécessaires.

Lorsque vous avez tous les fichiers DLL dans le même dossier, il est plus facile de trouver ceux qui ne sont pas valides (XML, WebKit, ... peu importe ..), et par conséquent, cette méthode ne prend pas plus de cinq minutes.


Si les DLL manquantes sont des assemblys GAC, cette méthode vous aidera à identifier les DLL manquantes (les messages d'erreur devraient vous indiquer sur quel assemblage il n'a pas pu se charger), puis vous devrez déterminer sur quelle boîte à outils ou framework installer sur la machine pour les mettre dans le GAC (ou inclure avec votre distribution).
rcabr

2
cela ne fonctionnera que pour les dépendances de DLL directes chargées au démarrage. si votre programme ou vos dlls chargeront certaines dlls de façon retardée ou dynamique, vous ne les trouverez pas avec votre approche.
A. Binzxxxxxx

Notez également que le faire de cette façon rend votre application sensible à l'ordre de la variable PATH, chargeant les versions du système dans certains cas et celles des dossiers locaux dans d'autres. M $ appelle cela un problème de sécurité, mais franchement, c'est de leur faute pour avoir utilisé le CWD dans les charges: support.microsoft.com/en-us/kb/2389418
meawoppl

3
Cela ne devrait pas être fait manuellement. Il existe un windeployqtoutil pour cela, voir par exemple stackoverflow.com/a/33292008/4023446
Orest Hera

1
@OrestHera windeployqtcopie souvent des fichiers inutiles.

16

Je viens de résoudre le même problème.

La dépendance Walker est trompeuse dans ce cas et m'a fait perdre du temps. Ainsi, la liste des fichiers DLL "manquants" du premier message n'est pas utile, et vous pouvez probablement l'ignorer.

La solution consiste à trouver les références que votre projet appelle et à vérifier si elles sont réellement installées sur le serveur.

@Ben Brammer, peu importe les trois fichiers .ocx manquants, car ils ne sont manquants que pour le projet de Leo T Abraham. Votre projet appelle probablement d'autres fichiers DLL.

Dans mon cas, il ne s'agissait pas de trois fichiers .ocx, mais d'un fichier DLL de connecteur MySQL manquant. Après l'installation de MySQL Connector pour .NET sur le serveur, le problème a disparu.

Donc, en bref, la solution est: vérifiez si toutes les références de votre projet sont là.


12

Comme mentionné, DCOMP fait partie des redistribuables VC ++ (implémentant le runtime OpenMP) et est le seul composant vraiment manquant. Tous les autres sont de faux rapports.

Plus précisément, les API-MS-WIN-XXXX.DLL sont des ensembles d'API - essentiellement, un niveau supplémentaire d'indirection d'appel introduit progressivement depuis Windows 7. Le développement de Dependency Walker semble s'être arrêté bien avant cela, et il ne peut pas gérer correctement les ensembles d'API.

Il n'y a donc rien à craindre. Vous ne manquez plus rien.

Une meilleure alternative pour trouver les fichiers DLL vraiment nécessaires qui sont manquants (si tel est effectivement le problème) consiste à exécuter Process Monitor et à reculer à partir de l'échec, en recherchant des séquences de sondes ayant échoué pour un fichier DLL spécifique dans tout le chemin du système.


+1 pour ProcessMonitor. C'est un téléchargement gratuit de Microsoft. Attachez-vous au processus matlab et vous pouvez voir tout ce qui se passe, y compris les charges dll
Janus

6

J'ai également rencontré ce problème, mais la solution qui semble être un fil conducteur ici, et que j'ai vue ailleurs sur le Web, est "[ré] installer le package redistribuable". Cependant, cela ne fonctionne pas pour moi, car le problème est survenu lors de l'exécution du programme d'installation de notre produit (qui installe le package redistribuable) pour tester nos nouvelles versions brillantes de Visual Studio 2015.

Le problème est survenu car les fichiers DLL répertoriés ne se trouvent pas dans le chemin d'installation de Visual Studio (par exemple, C: \ Program Files (x86) \ Microsoft Visual Studio 14.0 \ VC \ redist) et n'ont donc pas été ajoutés à l'installation. Ces dll api-ms-win- * sont installées sur un chemin d'installation du SDK Windows 10 dans le cadre de l'installation de Visual Studio 2015 (par exemple C: \ Program Files (x86) \ Windows Kits \ 10 \ Redist).

L'installation sur Windows 10 a bien fonctionné, mais l'installation sur Windows 7 a nécessité l'ajout de ces fichiers DLL à l'installation de notre produit. Pour plus d'informations, consultez Mise à jour pour Universal C Runtime dans Windows qui décrit l'ajout de ces dépendances causées par Visual Studio 2015 et fournit des téléchargements pour diverses plates-formes Windows; voir également Présentation de l'Universal CRT qui décrit la refonte des bibliothèques CRT. Le point 6 de la section intitulée Logiciel de distribution qui utilise le CRT universel est particulièrement intéressant :

Mise à jour le 11 septembre 2015: le déploiement App-local de l'Universal CRT est pris en charge. Pour obtenir les fichiers binaires pour le déploiement local de l'application, installez le Kit de développement logiciel (SDK) Windows pour Windows 10. Les fichiers binaires seront installés dans C: \ Program Files (x86) \ Windows Kits \ 10 \ Redist \ ucrt. Vous devrez copier toutes les DLL avec votre application (notez que l'ensemble des fichiers DLL est nécessaire est différent sur les différentes versions de Windows, vous devez donc inclure tous les fichiers DLL pour que votre programme s'exécute sur toutes les versions prises en charge de Windows).


5

Cette contribution ne répond pas vraiment à la question initiale, mais en tenant compte du taux de réussite de ce thread, je suppose qu'il y a pas mal de gens qui traitent le problème que les bibliothèques API-MS-WIN-CORE- ne peuvent pas être trouvées.

J'ai pu résoudre un problème où mon application refusait de démarrer avec le message d'erreur que API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL n'est pas trouvé en mettant simplement à jour Visual Studio.

Je ne pense pas que mon environnement de construction (Windows 7 Pro SP1, Visual Studio Ultimate 2012) était complètement foiré, cela a bien fonctionné pour la plupart de mes projets. Mais dans certaines circonstances très spécifiques, j'ai reçu le message d'erreur (voir ci-dessous).

Après la mise à jour de Visual Studio 11 de la version CD initiale (j'ai oublié de rechercher le numéro de version) vers la version 11.0.61030.00 Update 4, le projet cassé était à nouveau en cours d'exécution.

Message d'erreur au démarrage de l'application


Le lien est (effectivement) rompu ( "Nous sommes désolés, ce téléchargement n'est plus disponible." ).
Peter Mortensen

@PeterMortensen J'ai trouvé ce lien vers la mise à jour 5 , mais je ne sais pas si la solution de contournement suggérée s'applique toujours. La mise à jour 4 n'est plus disponible. Voici une liste des mises à jour pour VS2012 . La date de fin du produit signalée est 10/2023.
normanius

3

Cela a résolu le problème pour moi:

Désinstallez le package redistribuable Visual Studio 2010 si vous l'avez déjà installé, puis installez le Kit de développement logiciel (SDK) Microsoft Windows 7 .


1
Les notes d'installation vous suggèrent de désinstaller les packages de redistribution car ils contiennent des versions redondantes des DLL ci-dessus et provoqueront une confusion de liaison dynamique pour le code et d'autres formes d'herp-derp Win7. Pourquoi ne le fera-t-il pas pour vous pendant l'installation, nous pouvons le déposer en toute sécurité en tant que #iwishihadarealpackagemanager.
meawoppl

1
travaillé pour moi aussi. tant d'heures passées dessus, intalling .net directx, mais la réinstallation de msvc ++ a fonctionné
NoWomenNoCry

2

J'ai résolu le problème. Lorsque j'ai enregistré les fichiers OCX, je l'ai exécuté avec la fenêtre de commande qui avait été exécutée en tant qu'administrateur.


1

Pour tous ceux qui sont venus ici, mais avec un problème avec Photoshop : ma solution était de désinstaller le MS VC ++ redistribuable d'abord x86 et 64 à la fois. Installez ensuite une version appropriée à la version et à l'architecture de Windows (86 ou 64).


0

L'installation de SQL Server Management Studio 2014 sur un Windows 7 fraîchement installé a résolu ce problème chez notre client après une bataille ridicule de deux jours.


3
de nombreuses autres réponses existent, et ce serait peut-être mieux comme commentaire
Paul Bastide

0

J'ai eu le même problème. Après avoir passé des heures à chercher sur le Web, j'ai trouvé une solution pour moi.

J'ai copié le fichier combase.dll (C: \ Windows \ System32) dans le dossier de publication et cela a résolu le problème.


2
Installer des DLL aléatoires sur votre chemin est une MAUVAISE IDÉE.
meawoppl

0

Je suis venu ici avec ce problème, après avoir essayé une nouvelle installation OEM de Windows 7, une mise à niveau vers Windows 10.

Après quelques recherches sur les forums Microsoft et autres, j'ai trouvé la solution suivante qui a fonctionné pour moi:

Remplacez C:\Windows10Upgrade\wimgapi.dllpar celui deC:\Windows\System32\wimgapi.dll


Installer des DLL aléatoires sur votre chemin est une MAUVAISE IDÉE.
meawoppl

Bien sûr que oui, mais quand il s'agit d'une toute nouvelle installation, qu'y a-t-il à casser? : D
djsmiley2kStaysInside

0

Je suggère également de vérifier la quantité de mémoire actuellement utilisée.

Il s'avère que l'incapacité à trouver ces fichiers DLL a été le premier symptôme présenté lors de la tentative d'exécution d'un programme (exécuter ou déboguer) dans Visual Studio.

Après plus d'une demi-heure avec beaucoup de grattage de tête, la recherche sur le Web, l'exécution de Process Monitor et du Gestionnaire des tâches , et cela dépend, un programme complètement différent qui fonctionnait depuis le début des temps a rapporté que "la mémoire est faible; essayez d'arrêter certains programmes" ou certains tels. Après avoir tué Firefox, Thunderbird, Process Monitor et ça dépend, tout a de nouveau fonctionné.


0

Juste pour confirmer les réponses ici, ma résolution était de copier la DLL qui ne se chargeait pas ET le fichier ocx qui l'accompagnait dans le dossier system32, qui a résolu mon problème.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.