Me encontré con el mismo problema usando V2.2.0 de QGis y me ha estado atormentando por un tiempo, así que finalmente pude investigar esto y descubrir qué era.
Sin embargo, antes de continuar, quiero expresar que esta solución podría no funcionar para usted , parece que este es uno de esos errores, donde las razones básicas del problema son las mismas, pero cada caso tiene pequeños matices sutiles que son ligeramente diferente.
En mi caso, comencé con la excelente publicación SO mencionada en la primera respuesta. Al ser un desarrollador de MS de pila completa por oficio, tuve la sensación de que era algún tipo de conflicto RTL con mscvrt en lugar de un problema real de QGis (en parte porque también he visto el mismo comportamiento en otras aplicaciones también)
Después de abordar el problema de la ruta como se describe en la otra publicación, y al no obtener una resolución, comencé a explorar más usando el explorador de procesos, y esto me llevó a darme cuenta de que QGis estaba intentando cargar dos copias separadas de dos diferentes ubicaciones del archivo 'msvcr90.dll'
Después de darme cuenta de esto, moví la copia de msvcr90.dll que estaba en mi carpeta windows \ system32 a una ubicación de copia de seguridad lejos de mi unidad principal del sistema, y volví a ejecutar QGis.
En este punto, recibí un error diferente, uno quejándose de que faltaba una DLL requerida.
Al volver a colocar el archivo en system32 e intentarlo nuevamente, se solucionó esto, pero se recuperó el error de tiempo de ejecución original de C.
Después de mover el archivo dll msvcr90 a su ubicación segura, utilicé algunas de las herramientas SDK / Developer de Windows para rastrear el gráfico de dependencia de las DLL cargadas
Después de hacer esto, un poco más de hurgar en el explorador de procesos, me mostró que QGis también estaba cargando 'msvcp100.dll' y 'msvcr100.dll' desde su propia carpeta, y que uno o ambos de estos archivos DLL tenían dependencias estáticas en el ' msvcr90.dll 'que estaba en mi carpeta system32.
Después de una verificación rápida para asegurarme de que tenía una instalación estándar de todo el sistema de las 3 DLL en el lugar correcto (la carpeta Windows winsxs) también moví esos 2 archivos desde QGis bin a una ubicación de copia de seguridad.
Luego disparé QGis 2.0.2 de nuevo y bueno, todo comenzó y funciona sin ningún mensaje de error.
Ahora un poco de teoría para los interesados.
¿Por qué esto solo se manifiesta principalmente en sistemas de 64 bits?
Bueno, tiene que ver con la forma en que Windows administra la capa de compatibilidad en pocas palabras.
Verá que 'c: \ windows \ system32' NO es como lo haría creer en una carpeta del sistema de 32 bits.
Para cualquiera que recuerde los días de gloria de Windows, cuando todo lo que tenía que preocuparse era Windows 95/98, todo era de 32 bits y la vida era buena.
Luego, cuando aparecieron máquinas más potentes y comenzamos a obtener sistemas operativos de 64 bits, las cosas comenzaron a ponerse un poco complicadas.
Las 'cosas' de 32 bits podrían ejecutarse fácilmente en 64 bits y solo usarían la mitad del ancho de banda, pero las 'cosas' de 64 bits no podrían ejecutarse en 32 bits sin duplicar todo en un proceso llamado 'Thunking' (MS también cometió el mismo error cuando pasando de 16 Bit Win 3.11 a Win 95 también con el desafortunado paquete de complementos Win32S, pero esa es una historia para otro momento)
En su sabiduría infinita y para mantener 'Compatibilidad con software antiguo', MS en lugar de hacer las cosas de la manera más sensata y tener una carpeta 'System64' y una carpeta 'System32' decidió hacer las cosas un poco al revés.
En cambio, lo que decidieron hacer fue poner TODOS los componentes de 64 bits en una carpeta llamada 'system32', la razón detrás de esto era que las aplicaciones de 32 bits que se comportaban mal y tenían rutas codificadas, todavía se ejecutarían en un 64bit sistema, y cargaría y usaría componentes del sistema operativo de 64 bits sin darse cuenta realmente.
Mientras tanto, todo el material de 32 bits se colocó en una carpeta llamada 'SysWOW64', que fue redirigida de forma transparente por llamadas internas del kernel del sistema operativo cuando una aplicación de 32 bits genuina y bien comportada que usa llamadas legales del sistema operativo solicitó una DLL real de 32 bits, para servir a dicho 32 real DLL de una colección de archivos de 32 bits.
Esta redirección se conoce como 'Capa de compatibilidad de Windows de 64 bits en Windows X32', de ahí el nombre syswow64
Ahora todo esto está bien, cuando funciona y no se abusa de él.
Debido a este abuso (que duró durante los años infernales de DLL de Win XP), MS presentó un nuevo método mejorado cuando se lanzó Windows Vista llamado 'Capa de compatibilidad lado a lado de Windows' (les encantan sus capas de compatibilidad, ¿no es cierto: - ))
Esto vio la introducción de la carpeta 'winsxs', y la idea era simple
En esta carpeta coloca un 'Enlace duro' (Sí, amigos, NTFS puede hacer enlaces duros y blandos al igual que * nix can), este Enlace duro debería apuntar a la DLL apropiada requerida para el correcto funcionamiento de ese software en esa plataforma.
En nuestro caso, los tiempos de ejecución visuales de c ++ ahora se instalan en una carpeta no modificada y luego se vinculan a la carpeta winsxs, Windows luego mira de forma transparente la aplicación que llama a la DLL, descubre si es de 32 o 64 bits y redirige la llamada al DLL apropiado donde sea que se pueda instalar.
la carpeta winsxs (si es lo suficientemente valiente como para verla) tendrá una entrada para cada tiempo de ejecución y / o ensamblaje .net en su PC para cada plataforma compatible con ese tiempo de ejecución, y en su mayor parte funciona excepcionalmente bien la mayor parte del tiempo.
Es decir, hasta que una aplicación lunática que está codificada para buscar system32 va y suelta un dll de 32 bits en lo que cree que es la 'carpeta del sistema de 32 bits', generalmente sobrescribe la versión de 64 bits en el proceso y luego crea el enlace winsxs para ambas versiones de plataforma del tiempo de ejecución visual de C ++, elija una versión de 32 bits, en lugar de una versión de 32/64 bits, dependiendo de lo que se solicite.
Combine esto con el hecho de que nuevamente para ayudar a la compatibilidad, las búsquedas basadas en rutas SIEMPRE tienen prioridad sobre las llamadas basadas en SysWOW y winsxs, y luego tener ese dll en el lugar equivocado puede significar todo un mundo de dolor.
En el caso de msvcrt ?? en realidad se las arregla para 'Thunk' la versión de 32 bits en el espacio de direcciones de 64 bits y sigue trabajando (Es por eso que QGis en realidad no se bloquea al inicio), pero esto puede conducir a problemas más adelante (como la aplicación aleatoria se bloquea obtener mientras se ejecuta) debido a que la aplicación pensó erróneamente que el tiempo de ejecución puede manejar un valor de 64 bits.
Sin embargo, muchas otras aplicaciones pueden negarse a iniciarse por completo, dejando al usuario un mensaje de error bastante críptico y genérico que no ayuda a solucionar el problema.
De todos modos, sé que es una novela que he escrito aquí, pero dado que todavía hay muchas personas que se encuentran con este problema, espero que ahora estén armados con el conocimiento que necesitan para solucionarlo.
solo recuerde, esto no es para la finta del corazón, su desorden con los componentes internos del sistema operativo aquí, así que ASEGÚRESE de hacer una copia de seguridad de las cosas antes de comenzar a cambiar las cosas.
No puedo enfatizar esto lo suficiente, si comete un error, existe la posibilidad de que su sistema no se pueda arrancar. Es cierto que todavía tengo que ver que esto suceda, especialmente cuando las DLL involucradas son solo la biblioteca de tiempo de ejecución de C ++, pero el riesgo sigue ahí si cambia o mueve accidentalmente los archivos DLL incorrectos.
