locked
Falta API-MS-WIN-CORE-HEAP-L2-1-0.DLL? RRS feed

  • Pregunta

  • Cuando quiero abrir el juego Resident evil 2 remake, me sale el mensaje de "La aplicación no pudo iniciarse correctamente (0xc00007b). Haga click en aceptarla para cerrarla. Desgargué el Dependensy Walker y dice que el falta el archivo (API-MS-WIN-CORE-HEAP-L2-1-0.DLL. 
    Tengo windows 7 ultimate. Procesador Intel (R) Pentium (R), 8 gb ran, 1000 gb en disco rígido. Pude jugar perfectamente Resident evil 5, outlast, etc. No sé qué hacer. El archivo no está en Dll-files.com. No lo confuncan con api-ms-win-core-file-l1-0-1.dll por favor.
    Esto es porque tengo que cambiar el procesador por alguno más potente? O qué? 
    A mucha gente le anduvo ese juego wn windows 7. Qué puedo hacer?




    miércoles, 28 de agosto de 2019 22:09

Respuestas

  • Hello "martinavila57",

    This is the Spanish Windows Server Forum for LATAM, I recommend creating a new question in the English language Forum.

    https://social.technet.microsoft.com/Forums/en-US/home

    Regards.


    [Ignacio Barrios] MPN-MCT: 2019, MCTS: Windows Server 2008 R2, MCSA-MCSE: Window Server 2012 R2, Server Virtualization with Windows Server Hyper-V System Center & MCSA-MCSE: Windows Server 2016

    jueves, 29 de agosto de 2019 1:26
  • Contesto en español porque ese es el idioma del foro.

    Dependency Walker no está preparado para procesar las dependencias Api-ms-win-*.dll que el sistema resuelve a través de una tabla especial contenida en Apisetschema.dll, pues la última versión data de los tiempos de Windows Vista. Se necesita cierta experiencia para distinguir los errores ficticios de los reales. Si tuviera que aparecer alguna dependencia respecto de Api-ms-win-core-heap-l2-1-0.dll (L2, layer o capa 2), debería ser de tipo retardado, que se indica con un reloj de arena, o el ejecutable nunca funcionaría en Windows 7. No se debe confundir con Api-ms-win-core-heap-l1-1-0.dll (capa 1), que sí es una dependencia válida para Windows 7.

    Probablemente exista una DLL procedente de Windows 10 que se haya colocado de forma indebida y que además no coincida con la arquitectura de procesador del ejecutable del juego. Si el EXE es de arquitectura x64 de 64 bits, como parece ser por los requisitos, habrá intentado buscar la DLL en \Windows\System32; en cambio, un EXE x86 de 32 bits cargaría las DLL del sistema desde \Windows\SysWOW64.

    No descargues ningún archivo adicional. Olvídate por completo de dll-files.com y sitios web similares. Por favor, sigue las instrucciones de mi mensaje del 31 de mayo de 2015, y solo ese mensaje, en la conversación https://answers.microsoft.com/es-es/windows/forum/windows8_1-gaming/error-0xc000007b-windows-81-simple-language/52c0f961-1ba7-4144-b1c9-270e1875131c. Responde aquí, no allí, con los resultados obtenidos. Si el foro no te permite insertar imágenes por requerir verificación de usuario, súbelas a un servicio de almacenamiento como Dropbox, OneDrive o Google Drive, obtén un enlace y pégalo en la respuesta. Si tampoco deja poner enlaces, borra el prefijo https:// o inserta un espacio delante de .com, por ejemplo.



    jueves, 29 de agosto de 2019 1:39
  • ¿Qué has hecho exactamente? Mi propuesta era volver a usar Dependency Walker pero buscando información muy específica, con la única orientación del mensaje del 31 mayo de 2015. Si has hecho algo más por tu cuenta, no soy responsable.

    Por favor, carga en Dependency Walker el ejecutable que falla con el nuevo mensaje de error; ve a File, Save As, ponle un nombre al fichero de análisis con extensión .DWI; mándalo a Dropbox, OneDrive o Google Drive, preferiblemente comprimido; crea un vínculo de descarga; finalmente, pon el enlace en la respuesta.
    viernes, 30 de agosto de 2019 2:31
  • Hola. Hice lo que dijiste en el otro foro, y ahora me aparece otro error. Me sale el mensaje "No se encuentra el punto de entrada del procedimiento _W_Getdays en la biblioteca de vínculos dinámicos msvcrt.dll". Estoy muy perdido...
    jueves, 29 de agosto de 2019 21:10
  • Después de estudiar el archivo, llego a un diagnóstico: un revoltillo de bibliotecas que no deberían estar ahí. LA SOLUCIÓN PROPUESTA SOLAMENTE SE REFIERE A ESTA INSTALACIÓN PARTICULAR DE WINDOWS 7 Y NO PUEDE TRASLADARSE A OTROS SISTEMAS. CADA SITUACIÓN RELATIVA A PROBLEMAS DE DEPENDENCIAS DE DLL REQUIERE UNA INVESTIGACIÓN PROPIA Y UNA SOLUCIÓN DEDICADA. ABSTÉNGANSE OTROS USUARIOS DE APLICAR ESTE PROCEDIMIENTO, CON EL RIESGO DE DEJAR SU INSTALACIÓN DE WINDOWS COMPLETAMENTE INOPERABLE.

    Presta mucha atención a los nombres para no cometer equivocaciones. Procede con extrema cautela y sin prisas. Evita en cualquier caso operar sobre el directorio SysWOW64. Borra de \Windows\System32, y únicamente de allí, los siguientes archivos:

    • D3D12.DLL. Proviene de Windows 10 y por tanto es incompatible con Windows 7. El único método que admite Microsoft para usar Direct3D 12 en Windows 7, aun con restricciones, es un paquete NuGet especial que los desarrolladores deben integrar en sus productos. Además, han de llevar a cabo ciertos ajustes en su código de programación, por lo que no se trata simplemente de poner unas DLL y ya está, "magia". La sola eliminación de esta biblioteca resolvería de un plumazo los errores principales, pero hay más basura de la que hacerse cargo.
    • MSVCP110_WIN.DLL. Otro módulo proveniente de Windows 10 e incompatible con Windows 7. Este es el que provoca probablemente el error de _W_Getdays en MSVCRT.DLL, pues la versión de Windows 7 no exporta ese símbolo. Dependencia de D3D12.DLL. Existe también MSVCP110_CLR0400.DLL con un nombre similar y es un componente legítimo de .NET Framework 4.x, por lo que se debe conservar.
    • IESHIMS.DLL. No tiene relación con los errores experimentados, pero su supresión de System32 evitaría problemas futuros. Solamente debe estar en \Program Files\Internet Explorer, y el equivalente dentro de \Program Files (xxx) en las versiones de Windows que no son x86. Mucha gente confunde el aviso de archivo no encontrado en Dependency Walker con un problema real, cuando en realidad se trata de una dependencia retardada (reloj de arena) de IEFRAME.DLL que solo cobra sentido al ejecutar Internet Explorer.
    • API-MS-WIN-CORE-COM-L1-1-1.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-CORE-HEAP-L1-2-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7. Atención a la semejanza del nombre con otra DLL legítima como sería HEAP-L1-1-0.
    • API-MS-WIN-CORE-PSAPI-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-DX-D3DKMT-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.

    Además, he identificado otras DLL Api-ms-win-* y Ext-ms-win-* que no son de utilidad en Windows 7 y cuya sola presencia podría resultar problemática en el futuro. Varias de ellas se diferencian de bibliotecas genuinas del sistema solamente por los números. Se trata de dependencias adicionales de D3D12.DLL, raíz de todo mal:

    • API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
    • API-MS-WIN-CORE-DEBUG-L1-1-1.DLL (DEBUG-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-DELAYLOAD-L1-1-1.DLL (DELAYLOAD-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-ERRORHANDLING-L1-1-1.DLL (ERRORHANDLING-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-FILE-L1-2-1.DLL (las que terminan en FILE-L1-2-0 y FILE-L2-1-0 son legítimas en Windows 7 como satélites de UCRTBASE.DLL)
    • API-MS-WIN-CORE-LIBRARYLOADER-L1-2-0.DLL (LIBRARYLOADER-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-MEMORY-L1-1-2.DLL (MEMORY-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL (ojo con la similitud de nombres, pues PROCESSTHREADS-L1-1-0 y PROCESSTHREADS-L1-1-1 sí se deben conservar)
    • API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL
    • API-MS-WIN-CORE-SYSINFO-L1-2-1.DLL (SYSINFO-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-VERSION-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-WINDOW-L1-1-1.DLL
    • EXT-MS-WIN-RTCORE-NTUSER-SYSPARAMS-L1-1-0.DLL

    Por último, la dependencia retardada de la biblioteca API-MS-WIN-CORE-HEAP-L2-1-0.DLL inexistente procede del módulo D3D12.DLL, como cabía esperar.

    Vuelvo a insistir encarecidamente en evitar a toda costa los sitios web de descarga de ficheros DLL, tipo Dll-files.com y similares, y no actuar ciegamente ante los errores y los avisos que emita Dependency Walker.


    sábado, 31 de agosto de 2019 4:43
  • Después de estudiar el archivo, llego a un diagnóstico: un revoltillo de bibliotecas que no deberían estar ahí. LA SOLUCIÓN PROPUESTA SOLAMENTE SE REFIERE A ESTA INSTALACIÓN PARTICULAR DE WINDOWS 7 Y NO PUEDE TRASLADARSE A OTROS SISTEMAS. CADA SITUACIÓN RELATIVA A PROBLEMAS DE DEPENDENCIAS DE DLL REQUIERE UNA INVESTIGACIÓN PROPIA Y UNA SOLUCIÓN DEDICADA. ABSTÉNGANSE OTROS USUARIOS DE APLICAR ESTE PROCEDIMIENTO, CON EL RIESGO DE DEJAR SU INSTALACIÓN DE WINDOWS COMPLETAMENTE INOPERABLE.

    Presta mucha atención a los nombres para no cometer equivocaciones. Procede con extrema cautela y sin prisas. Evita en cualquier caso operar sobre el directorio SysWOW64. Borra de \Windows\System32, y únicamente de allí, los siguientes archivos:

    • D3D12.DLL. Proviene de Windows 10 y por tanto es incompatible con Windows 7. El único método que admite Microsoft para usar Direct3D 12 en Windows 7, aun con restricciones, es un paquete NuGet especial que los desarrolladores deben integrar en sus productos. Además, han de llevar a cabo ciertos ajustes en su código de programación, por lo que no se trata simplemente de poner unas DLL y ya está, "magia". La sola eliminación de esta biblioteca resolvería de un plumazo los errores principales, pero hay más basura de la que hacerse cargo.
    • MSVCP110_WIN.DLL. Otro módulo proveniente de Windows 10 e incompatible con Windows 7. Este es el que provoca probablemente el error de _W_Getdays en MSVCRT.DLL, pues la versión de Windows 7 no exporta ese símbolo. Dependencia de D3D12.DLL. Existe también MSVCP110_CLR0400.DLL con un nombre similar y es un componente legítimo de .NET Framework 4.x, por lo que se debe conservar.
    • IESHIMS.DLL. No tiene relación con los errores experimentados, pero su supresión de System32 evitaría problemas futuros. Solamente debe estar en \Program Files\Internet Explorer, y el equivalente dentro de \Program Files (xxx) en las versiones de Windows que no son x86. Mucha gente confunde el aviso de archivo no encontrado en Dependency Walker con un problema real, cuando en realidad se trata de una dependencia retardada (reloj de arena) de IEFRAME.DLL que solo cobra sentido al ejecutar Internet Explorer.
    • API-MS-WIN-CORE-COM-L1-1-1.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-CORE-HEAP-L1-2-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7. Atención a la semejanza del nombre con otra DLL legítima como sería HEAP-L1-1-0.
    • API-MS-WIN-CORE-PSAPI-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-DX-D3DKMT-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.

    Además, he identificado otras DLL Api-ms-win-* y Ext-ms-win-* que no son de utilidad en Windows 7 y cuya sola presencia podría resultar problemática en el futuro. Varias de ellas se diferencian de bibliotecas genuinas del sistema solamente por los números. Se trata de dependencias adicionales de D3D12.DLL, raíz de todo mal:

    • API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
    • API-MS-WIN-CORE-DEBUG-L1-1-1.DLL (DEBUG-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-DELAYLOAD-L1-1-1.DLL (DELAYLOAD-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-ERRORHANDLING-L1-1-1.DLL (ERRORHANDLING-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-FILE-L1-2-1.DLL (las que terminan en FILE-L1-2-0 y FILE-L2-1-0 son legítimas en Windows 7 como satélites de UCRTBASE.DLL)
    • API-MS-WIN-CORE-LIBRARYLOADER-L1-2-0.DLL (LIBRARYLOADER-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-MEMORY-L1-1-2.DLL (MEMORY-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL (ojo con la similitud de nombres, pues PROCESSTHREADS-L1-1-0 y PROCESSTHREADS-L1-1-1 sí se deben conservar)
    • API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL
    • API-MS-WIN-CORE-SYSINFO-L1-2-1.DLL (SYSINFO-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-VERSION-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-WINDOW-L1-1-1.DLL
    • EXT-MS-WIN-RTCORE-NTUSER-SYSPARAMS-L1-1-0.DLL

    Por último, la dependencia retardada de la biblioteca API-MS-WIN-CORE-HEAP-L2-1-0.DLL inexistente procede del módulo D3D12.DLL, como cabía esperar.

    Vuelvo a insistir encarecidamente en evitar a toda costa los sitios web de descarga de ficheros DLL, tipo Dll-files.com y similares, y no actuar ciegamente ante los errores y los avisos que emita Dependency Walker.


    Bueno lo hice paso a paso y eliminé cada uno de esos archivos. Funcionó y ya no aparecen los mensajes de errores, cosa genial. Aunque lo que pasa ahora es que se queda con la pantalla en negro y no inicia el juego. No sé si es por mi procesador, o porque ya tengo otros juegos instalados, no sé, porque ya probé descargar el crack y pegarlo en la carpeta de juego y pasa lo mismo. Pero eso debe tener una solución más sencilla de todos modos. Desde ya, te agradezco toda la ayuda que me brindaste y realmente sirvió, sos un genio bro jeje
    sábado, 31 de agosto de 2019 14:54

Todas las respuestas

  • Hello "martinavila57",

    This is the Spanish Windows Server Forum for LATAM, I recommend creating a new question in the English language Forum.

    https://social.technet.microsoft.com/Forums/en-US/home

    Regards.


    [Ignacio Barrios] MPN-MCT: 2019, MCTS: Windows Server 2008 R2, MCSA-MCSE: Window Server 2012 R2, Server Virtualization with Windows Server Hyper-V System Center & MCSA-MCSE: Windows Server 2016

    jueves, 29 de agosto de 2019 1:26
  • Contesto en español porque ese es el idioma del foro.

    Dependency Walker no está preparado para procesar las dependencias Api-ms-win-*.dll que el sistema resuelve a través de una tabla especial contenida en Apisetschema.dll, pues la última versión data de los tiempos de Windows Vista. Se necesita cierta experiencia para distinguir los errores ficticios de los reales. Si tuviera que aparecer alguna dependencia respecto de Api-ms-win-core-heap-l2-1-0.dll (L2, layer o capa 2), debería ser de tipo retardado, que se indica con un reloj de arena, o el ejecutable nunca funcionaría en Windows 7. No se debe confundir con Api-ms-win-core-heap-l1-1-0.dll (capa 1), que sí es una dependencia válida para Windows 7.

    Probablemente exista una DLL procedente de Windows 10 que se haya colocado de forma indebida y que además no coincida con la arquitectura de procesador del ejecutable del juego. Si el EXE es de arquitectura x64 de 64 bits, como parece ser por los requisitos, habrá intentado buscar la DLL en \Windows\System32; en cambio, un EXE x86 de 32 bits cargaría las DLL del sistema desde \Windows\SysWOW64.

    No descargues ningún archivo adicional. Olvídate por completo de dll-files.com y sitios web similares. Por favor, sigue las instrucciones de mi mensaje del 31 de mayo de 2015, y solo ese mensaje, en la conversación https://answers.microsoft.com/es-es/windows/forum/windows8_1-gaming/error-0xc000007b-windows-81-simple-language/52c0f961-1ba7-4144-b1c9-270e1875131c. Responde aquí, no allí, con los resultados obtenidos. Si el foro no te permite insertar imágenes por requerir verificación de usuario, súbelas a un servicio de almacenamiento como Dropbox, OneDrive o Google Drive, obtén un enlace y pégalo en la respuesta. Si tampoco deja poner enlaces, borra el prefijo https:// o inserta un espacio delante de .com, por ejemplo.



    jueves, 29 de agosto de 2019 1:39
  • Hola! Sí, me confundí porque vi una publicación del foro en inglés y pensé que era solo en ese idioma jajaj. Gracias, ya cambié todo a castellano.
    jueves, 29 de agosto de 2019 3:11
  • Hola! Gracias por la información genio, miré el link y mañana lo voy a probar paso a paso y te voy a avisar lo que pasó. Muchas gracias!
    jueves, 29 de agosto de 2019 3:13
  • Hola. Hice lo que dijiste en el otro foro, y ahora me aparece otro error. Me sale el mensaje "No se encuentra el punto de entrada del procedimiento _W_Getdays en la biblioteca de vínculos dinámicos msvcrt.dll". Estoy muy perdido...
    jueves, 29 de agosto de 2019 21:10
  • ¿Qué has hecho exactamente? Mi propuesta era volver a usar Dependency Walker pero buscando información muy específica, con la única orientación del mensaje del 31 mayo de 2015. Si has hecho algo más por tu cuenta, no soy responsable.

    Por favor, carga en Dependency Walker el ejecutable que falla con el nuevo mensaje de error; ve a File, Save As, ponle un nombre al fichero de análisis con extensión .DWI; mándalo a Dropbox, OneDrive o Google Drive, preferiblemente comprimido; crea un vínculo de descarga; finalmente, pon el enlace en la respuesta.
    viernes, 30 de agosto de 2019 2:31
  • ¿Qué has hecho exactamente? Mi propuesta era volver a usar Dependency Walker pero buscando información muy específica, con la única orientación del mensaje del 31 mayo de 2015. Si has hecho algo más por tu cuenta, no soy responsable.

    Por favor, carga en Dependency Walker el ejecutable que falla con el nuevo mensaje de error; ve a File, Save As, ponle un nombre al fichero de análisis con extensión .DWI; mándalo a Dropbox, OneDrive o Google Drive, preferiblemente comprimido; crea un vínculo de descarga; finalmente, pon el enlace en la respuesta.
    Listo. Lo abrí con Dependency Walker y me saltó lo mismo de core-heap-l2-1-0. Pero el error cuando lo inicio no es (0xc00007b). Te dejo el link acá:  https://drive.google.com/file/d/1QlqYI0sXSA7l1youBuaDxr-U2esTWerb/view?usp=sharing
    viernes, 30 de agosto de 2019 17:17
  • Después de estudiar el archivo, llego a un diagnóstico: un revoltillo de bibliotecas que no deberían estar ahí. LA SOLUCIÓN PROPUESTA SOLAMENTE SE REFIERE A ESTA INSTALACIÓN PARTICULAR DE WINDOWS 7 Y NO PUEDE TRASLADARSE A OTROS SISTEMAS. CADA SITUACIÓN RELATIVA A PROBLEMAS DE DEPENDENCIAS DE DLL REQUIERE UNA INVESTIGACIÓN PROPIA Y UNA SOLUCIÓN DEDICADA. ABSTÉNGANSE OTROS USUARIOS DE APLICAR ESTE PROCEDIMIENTO, CON EL RIESGO DE DEJAR SU INSTALACIÓN DE WINDOWS COMPLETAMENTE INOPERABLE.

    Presta mucha atención a los nombres para no cometer equivocaciones. Procede con extrema cautela y sin prisas. Evita en cualquier caso operar sobre el directorio SysWOW64. Borra de \Windows\System32, y únicamente de allí, los siguientes archivos:

    • D3D12.DLL. Proviene de Windows 10 y por tanto es incompatible con Windows 7. El único método que admite Microsoft para usar Direct3D 12 en Windows 7, aun con restricciones, es un paquete NuGet especial que los desarrolladores deben integrar en sus productos. Además, han de llevar a cabo ciertos ajustes en su código de programación, por lo que no se trata simplemente de poner unas DLL y ya está, "magia". La sola eliminación de esta biblioteca resolvería de un plumazo los errores principales, pero hay más basura de la que hacerse cargo.
    • MSVCP110_WIN.DLL. Otro módulo proveniente de Windows 10 e incompatible con Windows 7. Este es el que provoca probablemente el error de _W_Getdays en MSVCRT.DLL, pues la versión de Windows 7 no exporta ese símbolo. Dependencia de D3D12.DLL. Existe también MSVCP110_CLR0400.DLL con un nombre similar y es un componente legítimo de .NET Framework 4.x, por lo que se debe conservar.
    • IESHIMS.DLL. No tiene relación con los errores experimentados, pero su supresión de System32 evitaría problemas futuros. Solamente debe estar en \Program Files\Internet Explorer, y el equivalente dentro de \Program Files (xxx) en las versiones de Windows que no son x86. Mucha gente confunde el aviso de archivo no encontrado en Dependency Walker con un problema real, cuando en realidad se trata de una dependencia retardada (reloj de arena) de IEFRAME.DLL que solo cobra sentido al ejecutar Internet Explorer.
    • API-MS-WIN-CORE-COM-L1-1-1.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-CORE-HEAP-L1-2-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7. Atención a la semejanza del nombre con otra DLL legítima como sería HEAP-L1-1-0.
    • API-MS-WIN-CORE-PSAPI-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-DX-D3DKMT-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.

    Además, he identificado otras DLL Api-ms-win-* y Ext-ms-win-* que no son de utilidad en Windows 7 y cuya sola presencia podría resultar problemática en el futuro. Varias de ellas se diferencian de bibliotecas genuinas del sistema solamente por los números. Se trata de dependencias adicionales de D3D12.DLL, raíz de todo mal:

    • API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
    • API-MS-WIN-CORE-DEBUG-L1-1-1.DLL (DEBUG-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-DELAYLOAD-L1-1-1.DLL (DELAYLOAD-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-ERRORHANDLING-L1-1-1.DLL (ERRORHANDLING-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-FILE-L1-2-1.DLL (las que terminan en FILE-L1-2-0 y FILE-L2-1-0 son legítimas en Windows 7 como satélites de UCRTBASE.DLL)
    • API-MS-WIN-CORE-LIBRARYLOADER-L1-2-0.DLL (LIBRARYLOADER-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-MEMORY-L1-1-2.DLL (MEMORY-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL (ojo con la similitud de nombres, pues PROCESSTHREADS-L1-1-0 y PROCESSTHREADS-L1-1-1 sí se deben conservar)
    • API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL
    • API-MS-WIN-CORE-SYSINFO-L1-2-1.DLL (SYSINFO-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-VERSION-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-WINDOW-L1-1-1.DLL
    • EXT-MS-WIN-RTCORE-NTUSER-SYSPARAMS-L1-1-0.DLL

    Por último, la dependencia retardada de la biblioteca API-MS-WIN-CORE-HEAP-L2-1-0.DLL inexistente procede del módulo D3D12.DLL, como cabía esperar.

    Vuelvo a insistir encarecidamente en evitar a toda costa los sitios web de descarga de ficheros DLL, tipo Dll-files.com y similares, y no actuar ciegamente ante los errores y los avisos que emita Dependency Walker.


    sábado, 31 de agosto de 2019 4:43
  • Después de estudiar el archivo, llego a un diagnóstico: un revoltillo de bibliotecas que no deberían estar ahí. LA SOLUCIÓN PROPUESTA SOLAMENTE SE REFIERE A ESTA INSTALACIÓN PARTICULAR DE WINDOWS 7 Y NO PUEDE TRASLADARSE A OTROS SISTEMAS. CADA SITUACIÓN RELATIVA A PROBLEMAS DE DEPENDENCIAS DE DLL REQUIERE UNA INVESTIGACIÓN PROPIA Y UNA SOLUCIÓN DEDICADA. ABSTÉNGANSE OTROS USUARIOS DE APLICAR ESTE PROCEDIMIENTO, CON EL RIESGO DE DEJAR SU INSTALACIÓN DE WINDOWS COMPLETAMENTE INOPERABLE.

    Presta mucha atención a los nombres para no cometer equivocaciones. Procede con extrema cautela y sin prisas. Evita en cualquier caso operar sobre el directorio SysWOW64. Borra de \Windows\System32, y únicamente de allí, los siguientes archivos:

    • D3D12.DLL. Proviene de Windows 10 y por tanto es incompatible con Windows 7. El único método que admite Microsoft para usar Direct3D 12 en Windows 7, aun con restricciones, es un paquete NuGet especial que los desarrolladores deben integrar en sus productos. Además, han de llevar a cabo ciertos ajustes en su código de programación, por lo que no se trata simplemente de poner unas DLL y ya está, "magia". La sola eliminación de esta biblioteca resolvería de un plumazo los errores principales, pero hay más basura de la que hacerse cargo.
    • MSVCP110_WIN.DLL. Otro módulo proveniente de Windows 10 e incompatible con Windows 7. Este es el que provoca probablemente el error de _W_Getdays en MSVCRT.DLL, pues la versión de Windows 7 no exporta ese símbolo. Dependencia de D3D12.DLL. Existe también MSVCP110_CLR0400.DLL con un nombre similar y es un componente legítimo de .NET Framework 4.x, por lo que se debe conservar.
    • IESHIMS.DLL. No tiene relación con los errores experimentados, pero su supresión de System32 evitaría problemas futuros. Solamente debe estar en \Program Files\Internet Explorer, y el equivalente dentro de \Program Files (xxx) en las versiones de Windows que no son x86. Mucha gente confunde el aviso de archivo no encontrado en Dependency Walker con un problema real, cuando en realidad se trata de una dependencia retardada (reloj de arena) de IEFRAME.DLL que solo cobra sentido al ejecutar Internet Explorer.
    • API-MS-WIN-CORE-COM-L1-1-1.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-CORE-HEAP-L1-2-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7. Atención a la semejanza del nombre con otra DLL legítima como sería HEAP-L1-1-0.
    • API-MS-WIN-CORE-PSAPI-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.
    • API-MS-WIN-DX-D3DKMT-L1-1-0.DLL. Biblioteca de 32 bits en contexto x64, causa potencial de errores 0xC000007B. Dependencia de D3D12.DLL, no necesaria en Windows 7.

    Además, he identificado otras DLL Api-ms-win-* y Ext-ms-win-* que no son de utilidad en Windows 7 y cuya sola presencia podría resultar problemática en el futuro. Varias de ellas se diferencian de bibliotecas genuinas del sistema solamente por los números. Se trata de dependencias adicionales de D3D12.DLL, raíz de todo mal:

    • API-MS-WIN-CORE-APIQUERY-L1-1-0.DLL
    • API-MS-WIN-CORE-DEBUG-L1-1-1.DLL (DEBUG-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-DELAYLOAD-L1-1-1.DLL (DELAYLOAD-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-ERRORHANDLING-L1-1-1.DLL (ERRORHANDLING-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-FILE-L1-2-1.DLL (las que terminan en FILE-L1-2-0 y FILE-L2-1-0 son legítimas en Windows 7 como satélites de UCRTBASE.DLL)
    • API-MS-WIN-CORE-LIBRARYLOADER-L1-2-0.DLL (LIBRARYLOADER-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-MEMORY-L1-1-2.DLL (MEMORY-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL (ojo con la similitud de nombres, pues PROCESSTHREADS-L1-1-0 y PROCESSTHREADS-L1-1-1 sí se deben conservar)
    • API-MS-WIN-CORE-REGISTRY-L1-1-0.DLL
    • API-MS-WIN-CORE-SYSINFO-L1-2-1.DLL (SYSINFO-L1-1-0 es propia de Windows 7)
    • API-MS-WIN-CORE-VERSION-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-UICONTEXT-EXT-L1-1-0.DLL
    • EXT-MS-WIN-NTUSER-WINDOW-L1-1-1.DLL
    • EXT-MS-WIN-RTCORE-NTUSER-SYSPARAMS-L1-1-0.DLL

    Por último, la dependencia retardada de la biblioteca API-MS-WIN-CORE-HEAP-L2-1-0.DLL inexistente procede del módulo D3D12.DLL, como cabía esperar.

    Vuelvo a insistir encarecidamente en evitar a toda costa los sitios web de descarga de ficheros DLL, tipo Dll-files.com y similares, y no actuar ciegamente ante los errores y los avisos que emita Dependency Walker.


    Bueno lo hice paso a paso y eliminé cada uno de esos archivos. Funcionó y ya no aparecen los mensajes de errores, cosa genial. Aunque lo que pasa ahora es que se queda con la pantalla en negro y no inicia el juego. No sé si es por mi procesador, o porque ya tengo otros juegos instalados, no sé, porque ya probé descargar el crack y pegarlo en la carpeta de juego y pasa lo mismo. Pero eso debe tener una solución más sencilla de todos modos. Desde ya, te agradezco toda la ayuda que me brindaste y realmente sirvió, sos un genio bro jeje
    sábado, 31 de agosto de 2019 14:54