Win 7, 64 bit, dll problemas

Tengo un problema con nuestro ejecutable. Estoy ejecutando este ejecutable 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 sigue funcionando bien .

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

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 esos dlls API-MS-WIN -… y descubrí que ya deberían ser parte de Win-7 (aunque algunos sitios afirman que pertenecen al servidor Win-8 y Win 2012).

Ya probé las soluciones sugeridas que encontré, que son:

  • corriendo ‘sfc / scannow’
  • instalar los ejecutables de tiempo de ejecución de Visual Studio 2008 SP1

Pero eso no solucionó nada. 🙁

Nota al margen: Mi cuadro de desarrollo tampoco los tiene y parece que no los necesita. Por ejemplo, el archivo user32.dll en mi cuadro no enlaza con uno de esos, mientras que la instalación en VM ware sí.

¿Alguna idea sobre cómo solucionar este problema? Traté de encontrar una descarga / correcció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 publicarlo como respuesta porque la pregunta se ha cerrado.

En realidad, todas las DLL informadas faltadas por la herramienta de walker de dependencia, nameley aquellos

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

tipo DLL no eran 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 walter de dependencias aún enumeraba todas las mismas DLL que antes, incluso cuando el progtwig funcionaba 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 el sistema operativo más nuevo. Así que mantén un ojo abierto y no te confundas al faltar ‘API-MS-WIN-CORE-COM-L1-1-0.DLL’, … el problema probablemente se encuentre completamente en otro lado.

Este problema está relacionado con la pérdida del Visual Studio “paquete redistribuible”. No es obvio cuál falta en función de la caminata de dependencia, pero probaría primero la que corresponde con su versión de comstackción y veré si las cosas se ejecutan correctamente:

VS 2015

VS 2013

VS 2010

VS 2008

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

A mí 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 decía 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 manera clara de saberlo (Dependency Wolker no me ayudó mucho …), seguí el siguiente “procedimiento inverso” que no toma más de 5 minutos y evito muchos dolores de cabeza con las dependencias de Dlls :

  1. Comstack tu proyecto y lleva el archivo ejecutable a una carpeta vacía: myproject.exe
  2. Intenta ejecutarlo, recuperará un error (dlls faltantes …).
  3. Ahora copie todos los dlls de Qt (en mi caso estaban en C: \ Qt \ Qt5.1.1 \ 5.1.1 \ msvc2012_64_opengl \ bin) en esta carpeta.
  4. Intenta ejecutar de nuevo, probablemente funcione bien.
  5. Comience a eliminar progresivamente y pruebe cada vez que su ejecutable todavía funciona, tratando de dejar las DLL mínimas necesarias.

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 toma más de cinco minutos.

Acabo de resolver el mismo problema.

Dependencia Walker es engañoso en este caso y me hizo perder tiempo. Entonces, la lista de dlls “perdidos” de la primera publicación no es útil, probablemente puedas ignorarla.

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

@Ben Brammer, no es importante que 3 archivos .ocx falten porque solo faltan para el proyecto de Leo T Abraham. Tu proyecto probablemente llame a otros dlls.

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

Entonces, en una solución corta, verifique si todas las referencias de su proyecto están allí.

Aclamaciones

Como se mencionó, DCOMP es parte de los redistribuibles de VC ++ (que implementa el tiempo de ejecución de OpenMP) y es el único componente que realmente falta. El rest son informes falsos.

Específicamente, API-MS-WIN-XXXX.DLL son conjuntos de API . En esencia, un nivel adicional de llamadas indirectas se introdujo gradualmente desde Windows 7. El desarrollo de walter 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 allí. No te estás perdiendo nada más.

Una mejor alternativa para encontrar las DLL realmente necesarias que faltan (si ese es el problema) es ejecutar ProcessMonitor y dar un paso atrás desde la falla, buscando secuencias de sondeos fallidos para una DLL específica en toda la ruta del sistema.

También me encontré con este problema, pero la solución que parece ser un hilo común aquí, y vi en otro lugar en 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 relucientes comstackciones VS 2015.

El problema surgió porque los dlls enumerados no se encuentran en la ruta de instalación de Visual Studio (por ejemplo, C: \ Archivos de progtwig (x86) \ Microsoft Visual Studio 14.0 \ VC \ redist) y, por lo tanto, no se habían agregado a la instalación. Estos api-ms-win- * dlls se instalan en una ruta de instalación de Windows 10 SDK como parte de la instalación de Visual Studio 2015 (por ejemplo, C: \ Archivos de progtwig (x86) \ Windows Kits \ 10 \ Redist). La instalación en Windows 10 funcionaba bien, pero la instalación en Windows 7 requería agregar estos dlls 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 causadas 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 elemento 6 en la sección titulada Software de distribución que utiliza Universal CRT :

Actualizado el 11 de septiembre de 2015: se admite el despliegue de la aplicación local de Universal CRT. Para obtener los archivos binarios para la implementación local de la aplicación, instale el Kit de desarrollo de software de Windows (SDK) para Windows 10. Los archivos binarios se instalarán en C: \ Archivos de progtwig (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 es necesario es diferente en las diferentes versiones de Windows, por lo que debe incluir todos los archivos DLL para que su progtwig se ejecute en todas las versiones compatibles de Windows )

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

Esta contribución realmente no responde a la pregunta inicial, pero teniendo en cuenta la tasa de éxito de este hilo, supongo que hay bastantes personas que lidian con el problema que las bibliotecas API-MS-WIN-CORE no pueden ser encontradas.

Pude resolver un problema donde mi aplicación rechazó 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 construcción (Win7 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 a continuación).

Después de actualizar Visual Studio 11 desde la versión inicial del CD (me olvidé de 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.

¡Espero que esto haya ayudado a alguien!

Mensaje de error al inicio de la aplicación

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

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) en la carpeta real y lo resolví.

Instalación 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.

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

Vine aquí con este problema, después de probar una nueva instalación OEM de Windows 7, actualizando a Windows 10.

Después de algunas búsquedas en los foros de microsoft, encontré la siguiente solución que funcionó para mí:

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