Tengo un problema con nuestro ejecutable. Estoy ejecutando este ejecutable C ++ de 32 bits en mi cuadro de desarrollo de Windows 7 de 64 bits que también tiene todas esas aplicaciones de Microsoft (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office) ... Y aún funciona bien.
Ahora obtuve la instalación del cliente del mismo programa y me pidieron que lo probara con una instalación limpia de Windows 7. Por lo tanto, obtuve un VMware de Windows 7 de 64 bits y lo actualicé a Windows 7 SP 1 (la misma versión que mi caja de desarrollador está ajustando). Pero mientras que en mi caja de desarrollador todo está bien, el programa no funciona con la caja de VMware (30 días de prueba).
El x86 Dependency Walker me dice que faltan los siguientes archivos DLL:
- 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
Busqué en Google esos archivos DLL API-MS-WIN -... y descubrí que en realidad ya deberían ser parte de Windows 7 (aunque algunos sitios afirman que pertenecen a Windows 8 y Windows Server 2012).
Ya probé las soluciones sugeridas que encontré, que son:
- ejecutando 'sfc / scannow'
- Instalar ejecutables de tiempo de ejecución de Visual Studio 2008 SP1
Pero eso no resolvió nada. :-(
Nota al margen: Mi cuadro de desarrollo tampoco los tiene, y parece que no los necesita. Por ejemplo, user32.dll en mi caja no se vincula con uno de esos, mientras que la instalación en VMware sí.
¿Alguna idea sobre cómo solucionar este problema? Traté de encontrar una descarga / corrección adecuada en las páginas de Microsoft, pero fallé.
Después de resolver mi problema, quería informar lo que descubrí, y no puedo publicar esto como respuesta porque la pregunta se ha cerrado.
En realidad, todos los archivos DLL reportados como perdidos por la herramienta Dependency Walker, es decir, aquellos
* API-MS-WIN-CORE-...
Los archivos tipo DLL no formaban parte del problema real.
En mi caso, faltaba el registro de tres archivos OCX y después de eso todo estuvo bien, PERO la herramienta Dependency Walker todavía enumeraba todos los mismos archivos DLL que antes, incluso cuando el programa se estaba ejecutando bien ahora.
La esencia de esto: como alguien dijo en otro lugar, la herramienta está un poco anticuada por ahora y no siempre funciona correctamente con un sistema operativo más nuevo. Por lo tanto, manténgase atento y no se engañe al perder 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... el problema probablemente yace completamente en otra parte.
Respuestas:
Este problema está relacionado con la falta del "paquete redistribuible" de Visual Studio. No es obvio cuál falta en función del recorrido de dependencia, pero probaría primero el que corresponda con su versión del compilador y veré si las cosas funcionan correctamente:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
Me encontré con este problema porque estoy usando los compiladores de Visual Studio, pero no el entorno completo de Visual Studio.
Atrévete a inyectar un nuevo enlace aquí: Las últimas descargas compatibles de Visual C ++ . Stein Åsmul, 29.11.2018 .
fuente
Acabo de resolver el mismo problema con C ++ Qt 5 y Windows 7 64 bits con MSCVC 2012.
Al principio pensé que era un problema de archivo DLL de MSVC / Windows, pero como dijo BorisP, el problema estaba en las dependencias de mi proyecto. La clave es " ¿Cómo saber las dependencias de su proyecto en Qt 5? ".
Como no encontré ninguna forma clara de saberlo ( Dependency Walker no me ayudó mucho ...), seguí luego el "procedimiento inverso" que no lleva más de 5 minutos y evito muchos dolores de cabeza con DLL dependencias de archivo:
Cuando tiene todos los archivos DLL en la misma carpeta, es más fácil encontrar cuáles de ellos no son válidos (XML, WebKit, ... lo que sea ...) y, en consecuencia, este método no lleva más de cinco minutos.
fuente
windeployqtherramienta para eso, ver por ejemplo stackoverflow.com/a/33292008/4023446windeployqtmenudo copia archivos innecesarios.Acabo de resolver el mismo problema.
Dependency Walker es engañoso en este caso y me hizo perder tiempo. Por lo tanto, la lista de archivos DLL "faltantes" de la primera publicación no es útil, y probablemente pueda ignorarla.
La solución es encontrar a qué referencias llama su proyecto y verificar si realmente están instaladas en el servidor.
@Ben Brammer, no es importante qué tres archivos .ocx faltan, porque faltan solo para el proyecto de Leo T Abraham. Su proyecto probablemente llama a otros archivos DLL.
En mi caso, no eran tres archivos .ocx, pero faltaba el archivo DLL del conector MySQL. Después de instalar MySQL Connector para .NET en el servidor, el problema desapareció.
En resumen, la solución es: verificar si todas las referencias de su proyecto están ahí.
fuente
Como se mencionó, DCOMP es parte de los redistribuibles VC ++ (implementando el tiempo de ejecución de OpenMP) y es el único componente que realmente falta. Todo lo demás son informes falsos.
Específicamente, API-MS-WIN-XXXX.DLL son conjuntos de API , esencialmente, un nivel adicional de llamada indirecta introducida gradualmente desde Windows 7. El desarrollo de Dependency Walker aparentemente se detuvo mucho antes de eso, y no puede manejar los conjuntos de API correctamente.
Entonces no hay nada de qué preocuparse allí. No te estás perdiendo nada más.
Una mejor alternativa para encontrar los archivos DLL realmente necesarios que faltan (si ese es realmente el problema) es ejecutar Process Monitor y retroceder desde la falla, buscando secuencias de sondas fallidas para un archivo DLL específico en toda la ruta del sistema.
fuente
También me encontré con este problema, pero la solución que parece ser un tema común aquí, y vi en otra parte de la web, es "[re] instalar el paquete redistribuible". Sin embargo, para mí eso no funciona, ya que surgió el problema al ejecutar el instalador de nuestro producto (que instala el paquete redistribuible) para probar nuestras nuevas y brillantes compilaciones de Visual Studio 2015.
El problema surgió porque los archivos DLL enumerados no se encuentran en la ruta de instalación de Visual Studio (por ejemplo, C: \ Archivos de programa (x86) \ Microsoft Visual Studio 14.0 \ VC \ redist) y, por lo tanto, no se agregaron a la instalación. Estos dlls api-ms-win- * se instalan en una ruta de instalación del SDK de Windows 10 como parte de la instalación de Visual Studio 2015 (por ejemplo, C: \ Archivos de programa (x86) \ Windows Kits \ 10 \ Redist).
La instalación en Windows 10 funcionó bien, pero la instalación en Windows 7 requirió agregar estos archivos DLL a la instalación de nuestro producto. Para obtener más información, consulte Actualización de Universal C Runtime en Windows que describe la adición de estas dependencias causadas por Visual Studio 2015 y proporciona descargas para varias plataformas de Windows; también vea Introducción a Universal CRT, que describe el rediseño de las bibliotecas CRT. De particular interés es el ítem 6 en la sección titulada Distribución de software que utiliza el CRT universal :
fuente
Esta contribución no responde realmente a la pregunta inicial, pero teniendo en cuenta la tasa de éxito de este hilo, supongo que hay bastantes personas que se ocupan del problema de que no se pueden encontrar las bibliotecas API-MS-WIN-CORE-.
Pude resolver un problema en el que mi aplicación se negaba a comenzar con el mensaje de error que API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL no se encuentra simplemente actualizando Visual Studio.
No creo que mi entorno de compilación (Windows 7 Pro SP1, Visual Studio Ultimate 2012) se haya estropeado por completo, funcionó bien para la mayoría de mis proyectos. Pero en algunas circunstancias muy específicas recibí el mensaje de error (ver más abajo).
Después de actualizar Visual Studio 11 desde la versión inicial del CD (olvidé buscar el número de versión) a la versión 11.0.61030.00 Actualización 4, también el proyecto roto se estaba ejecutando nuevamente.
fuente
Esto resolvió el problema para mí:
Desinstale el paquete redistribuible de Visual Studio 2010 si ya lo tiene instalado, y luego instale Microsoft Windows 7 SDK .
fuente
Resolví el problema. Cuando registré los archivos OCX, lo ejecuté con la ventana de comandos que se había ejecutado como administrador.
fuente
Para cualquiera que haya venido aquí, pero con un problema de Photoshop : mi solución fue desinstalar el MS VC ++ redistribuible primero x86 y 64 ambos. Luego instale uno apropiado para la versión y arquitectura de Windows (86 o 64).
fuente
La instalación de SQL Server Management Studio 2014 en un Windows 7 recién instalado resolvió este problema en nuestro cliente después de una batalla ridícula de dos días.
fuente
Yo tuve el mismo problema. Después de pasar horas buscando en la web, encontré una solución para mí.
Copié el archivo combase.dll (C: \ Windows \ System32) en la carpeta de lanzamiento y resolvió el problema.
fuente
Vine aquí con este problema, después de probar una nueva instalación OEM de Windows 7, actualizando a Windows 10.
Después de buscar en los foros de Microsoft y tal, encontré la siguiente solución que funcionó para mí:
fuente
Sugiero también verificar cuánta memoria se está utilizando actualmente.
Resulta que la incapacidad para encontrar estos archivos DLL fue el primer síntoma exhibido al intentar ejecutar un programa (ya sea ejecutar o depurar) en Visual Studio.
Después de más de media hora con mucho rascarse la cabeza, buscar en la web, ejecutar Process Monitor y Task Manager , y depende, un programa completamente diferente que se había estado ejecutando desde el principio de los tiempos informó que "la memoria es baja; intente detener algunos programas" o algo por el estilo. Después de matar a Firefox, Thunderbird, Process Monitor, y depende, todo volvió a funcionar.
fuente
Solo para confirmar las respuestas aquí, mi resolución fue copiar la DLL que no se estaba cargando Y el archivo ocx que lo acompañaba a la carpeta system32, que resolvió mi problema.
fuente