windows - para - Win 7, 64 bit, problemas dll

pack dll windows 7 64 bits (13)

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, probablemente puede ignorarla.

La solución es encontrar a qué referencias llama su proyecto y verificar si están realmente instaladas en el servidor.

@Ben Brammer, no es importante qué archivos .ocx faltan porque faltan solo para el proyecto de Leo T. Abraham. Tu proyecto probablemente llama a otros dlls.

En mi caso, no eran 3 archivos .ocx, pero faltaba el dll del conector MySQL. Después de instalar MySQL Connector para .Net en el servidor, el problema desapareció.

Entonces, en resumen, la solución es: compruebe si todas las referencias de su proyecto están allí.

Aclamaciones

Tengo un problema con nuestro ejecutable. Estoy ejecutando este ejecutable de C ++ de 32 bits en mi caja de desarrollo de Win-7 de 64 bits que también tiene todas esas aplicaciones MS (Visual Studio 2008 + 2010, TFS, SDK, MS Office) ... Y aún funciona bien .

Ahora obtuve la instalación de cliente del mismo programa y me pidieron que la probara con una instalación limpia de Win-7. Así conseguí el Win-7 64-bit VM Ware y lo actualicé a Win-7 SP 1 (la misma versión que mi caja de desarrollador está sintonizando). Pero mientras que en mi cuadro de desarrollador todo está bien, el programa no funciona con el cuadro VW Ware (30 días de prueba).

El caminante de dependencias x86 me dice que faltan las siguientes 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 para esas API-MS-WIN -... dlls y descubrí que en realidad ya deberían ser parte de Win-7 (algunos sitios que afirman que pertenecen al servidor Win-8 y Win 2012).

Ya probé los arreglos sugeridos que encontré, que son:

corriendo ''sfc / scannow''
instalando ejecutables en tiempo de ejecución de Visual Studio 2008 SP1

Pero eso no resolvió nada. :-(

Nota al margen: Mi caja de desarrollo tampoco los tiene, y parece que no los necesita. Por ejemplo, el user32.dll en mi caja no se vincula con uno de esos, mientras que la instalación en el VMware lo hace.

¿Alguna idea sobre cómo solucionar este problema? Intenté encontrar una descarga / solución adecuada en las páginas de MS, pero fallé.

Saludos, Thomas

Después de resolver mi problema, quise informar lo que descubrí y no puedo publicar esto como respuesta porque la pregunta se ha cerrado.

En realidad, todas las DLL informadas faltan por la herramienta de dependencia de seguimiento, es decir, aquellas

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

Los DLL de tipo no formaban parte del problema real.

En mi caso, faltaba el registro de 3 archivos OCX y, después de eso, todo estaba bien, pero la herramienta de seguimiento de dependencias seguía enumerando todas las mismas DLL que antes, incluso cuando el programa estaba funcionando bien ahora.

La esencia de esto es: como lo dijo alguien en otro lugar, la herramienta está un poco anticuada hasta ahora y no siempre funciona correctamente con los sistemas operativos más nuevos. Por lo tanto, mantén un ojo abierto y no te dejes engañar al faltar ''API-MS-WIN-CORE-COM-L1-1-0.DLL'', ... el problema probablemente se encuentre completamente en otra parte.

Como se mencionó, DCOMP es parte de los redistribuibles de VC ++ (implementando el tiempo de ejecución de OpenMP) y es el único componente realmente faltante. Todo lo demás son informes falsos.

Específicamente, API-MS-WIN-XXXX.DLL son conjuntos de API , esencialmente, un nivel adicional de direccionamiento de llamadas introducido gradualmente desde Windows 7. El desarrollo del andador de dependencias aparentemente se detuvo mucho antes de eso, y no puede manejar los conjuntos de API correctamente.

Así que no hay nada de qué preocuparse. No te estás perdiendo nada más.

Una mejor alternativa para encontrar los archivos DLL realmente necesarios que faltan (si ese es el problema) es ejecutar ProcessMonitor y retroceder desde el fallo, buscando secuencias de sondas fallidas para un archivo DLL específico en toda la ruta del sistema.

Esta contribución no responde realmente a la pregunta inicial, pero teniendo en cuenta la tasa de aciertos de este hilo, asumo que hay muchas personas que se enfrentan al problema de que no se pueden encontrar las bibliotecas API-MS-WIN-CORE.

Pude resolver un problema donde mi aplicación se negó a comenzar con el mensaje de error de que API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL no se encuentra simplemente al actualizar Visual Studio.

No creo que mi entorno de compilación (Win7 Pro SP1, Visual Studio Ultimate 2012) se haya estropeado por completo, funcionó bien en la mayoría de mis proyectos. Pero bajo 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 de CD inicial (olvidé buscar el número de versión) a la versión 11.0.61030.00 Actualización 4, también se ejecutó nuevamente el proyecto roto.

Espero que esto haya ayudado a alguien!

Este problema está relacionado con la falta del "paquete redistribuible" de Visual Studio. No es obvio cuál falta en función de la caminata de dependencia, pero primero probaría la que corresponde con la versión del compilador y vería si las cosas funcionan correctamente:

Me encontré con este problema porque estoy usando los compiladores de VS, pero no el entorno completo de VS.

Esto solucionó el problema para mí.
Desinstale el paquete redistribuible de VS 2010, si ya lo tiene instalado, instale Microsoft Windows 7 SDK

La instalación de MSSQL Management Studio 2014 en Windows 7 recién instalado resolvió este problema en nuestro cliente después de una batalla ridícula de 2 días.

Llegué aquí con este problema, después de intentar una nueva instalación de Windows 7 OEM, actualizándome a Windows 10.

Después de buscar en los foros de Microsoft y otros, encontré la siguiente solución que me funcionó:

Reemplace C:/Windows10Upgrade/wimgapi.dll con el de C:/Windows/System32/wimgapi.dll

Resolví el problema. Cuando registré los archivos OCX, lo ejecuté con la ventana de comandos que se había ejecutado como administrador.

Sugiera también verificar cuánta memoria se está utilizando actualmente. Resulta que la incapacidad para encontrar estas DLL fue el primer síntoma exhibido al intentar ejecutar un programa (ejecutar o depurar) en Visual Studio. Después de más de media hora con mucho rascarse la cabeza, buscar en la web, ejecutar procmon y Task Manager, y depende, un programa completamente diferente que se había estado ejecutando desde el principio del tiempo informó que "la memoria es baja; intente detener algunos programas" o algunos tal. Matar a Firefox, Thunderbird, procmon, depende, todo funcionó de nuevo.

También me encontré con este problema, pero la solución que parece ser un subproceso común aquí, y que vi en otras partes de la web, es "[re] instalar el paquete redistribuible". Sin embargo, para mí eso no funciona, ya que el problema surgió al ejecutar el instalador de nuestro producto (que instala el paquete redistribuible) para probar nuestras nuevas y brillantes versiones de VS 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 api-ms-win- * dlls 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 nuestra instalación del producto. Para obtener más información, consulte https://support.microsoft.com/en-us/kb/2999226 que describe la adición de estas dependencias causada por VS 2015 y proporciona descargas para varias plataformas de Windows; también vea https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/ que describe el rediseño de las bibliotecas CRT. De particular interés es el artículo 6 en la sección titulada Software de distribución que utiliza el CRT universal :

Actualizado el 11 de septiembre de 2015: se admite la implementación local de la aplicación de Universal CRT. Para obtener los binarios para la implementación local de la aplicación, instale el Kit de desarrollo de software (SDK) de Windows para Windows 10. Los binarios se instalarán en C: / Archivos de programa (x86) / Windows Kits / 10 / Redist / ucrt. Deberá copiar todos los archivos DLL con su aplicación (tenga en cuenta que el conjunto de archivos DLL necesarios es diferente en las diferentes versiones de Windows, por lo que debe incluir todos los archivos DLL para que su programa se ejecute en todas las versiones compatibles de Windows ).

Yo también, acabo de resolver el mismo problema con C ++ Qt5 y W7 64bits con MSCVC 2012.

Al principio pensé que era un problema de MSVC / Windows dll, 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 Qt5? ".

Como no encontré ninguna forma clara de saberlo (Dependency Wolker no me ayudó mucho ...), seguí el siguiente "procedimiento inverso" que no toma más de 5 minutos y evita muchos dolores de cabeza con las dependencias de Dll. :

Compile su proyecto y lleve el archivo ejecutable a una carpeta vacía: myproject.exe
Intente ejecutarlo, recuperará un error (faltan dlls ...).
Ahora, copie todos los dlls de Qt (en mi caso estaban en C: / Qt / Qt5.1.1 / 5.1.1 / msvc2012_64_opengl / bin) a esta carpeta.
Intenta ejecutar de nuevo, probablemente funcione bien.
Comience a eliminar progresivamente e intente cada vez que su ejecutable aún funcione, intentando dejar los archivos DLL mínimos necesarios.

Cuando tiene todas las DLL en la misma carpeta, es más fácil encontrar cuáles de ellas no son válidas (XML, webkit ... lo que sea ..), por lo tanto, este método no demora más de cinco minutos.

Yo tuve el mismo problema. Después de pasar horas buscando en la web, encontré una solución para mí. Puse el archivo: combase.dll (C: / windows / system32) juntos en la carpeta realese y resolví.

para cualquiera que haya venido aquí, pero con el problema de photoshop: mi solución fue desinstalar ms vc ++ redistributable first x86 y 64. Luego instale uno apropiado para la versión y arquitectura de Windows (86 o 64).