J'ai rencontré le même problème en utilisant la V2.2.0 de QGis et cela me tourmente depuis un certain temps, alors j'ai finalement pu faire des recherches et trouver ce que c'était.
Avant d'aller plus loin cependant, je tiens à exprimer que ce correctif pourrait ne pas fonctionner pour vous, il semble que ce soit l'une de ces erreurs, où les raisons de base du problème sont les mêmes, mais chaque cas a de petites nuances subtiles qui sont légèrement différent.
Dans mon cas, j'ai commencé avec l'excellent poste SO référencé dans la première réponse. Étant un développeur MS complet de pile par métier, j'avais le sentiment instinctif qu'il s'agissait d'une sorte de conflit RTL avec mscvrt plutôt qu'un problème QGis réel (en partie parce que j'ai également vu le même comportement dans d'autres applications)
Après avoir abordé le problème de chemin tel que décrit dans l'autre article et n'ayant pas réussi à obtenir une résolution, j'ai commencé à explorer davantage à l'aide de l'explorateur de processus, ce qui m'a amené à réaliser que QGis essayait en fait de charger deux copies distinctes de deux différents emplacements du fichier 'msvcr90.dll'
Après avoir réalisé cela, j'ai déplacé la copie de msvcr90.dll qui se trouvait dans mon dossier windows \ system32 vers un emplacement de sauvegarde bien loin de mon lecteur système principal et j'ai réexécuté QGis.
À ce stade, j'ai ensuite obtenu une erreur différente, une se plaignant qu'une DLL requise était manquante.
Remettre le fichier dans system32 et réessayer, a corrigé ce problème, mais a ramené l'erreur d'exécution C d'origine.
Après avoir déplacé la DLL msvcr90 vers son emplacement sûr, j'ai ensuite utilisé certains des outils Windows SDK / Developer pour suivre le graphique de dépendance des DLL chargées
Après avoir fait cela, un peu plus dans l'Explorateur de processus, m'a montré que QGis chargeait également 'msvcp100.dll' et 'msvcr100.dll' à partir de son propre dossier, et que l'une ou les deux de ces DLL avaient des dépendances statiques sur le ' Fichier msvcr90.dll qui se trouvait dans mon dossier system32.
Après une vérification rapide pour m'assurer que j'avais une installation standard à l'échelle du système des 3 DLL au bon endroit (le dossier windows winsxs), j'ai également déplacé ces 2 fichiers de QGis bin vers un emplacement de sauvegarde.
J'ai ensuite tiré QGis 2.0.2 et salut, tout a démarré et fonctionne sans aucun message d'erreur.
Maintenant un peu de théorie pour ceux qui sont intéressés
Pourquoi cela ne se manifeste-t-il principalement que sur les systèmes 64 bits?
Eh bien, cela a à voir avec la façon dont Windows gère la couche de compatibilité en un mot.
Vous voyez que «c: \ windows \ system32» n'est PAS comme vous le feriez croire à un dossier système 32 bits.
Pour tous ceux qui se souviennent des jours de gloire de Windows, quand tout ce dont vous aviez à vous soucier était Windows 95/98, tout était en 32 bits et la vie était belle.
Puis, lorsque des machines plus puissantes sont sorties et que nous avons commencé à obtenir des systèmes d'exploitation 64 bits, les choses ont commencé à devenir un peu délicates.
Les `` trucs '' 32 bits pouvaient facilement fonctionner sur 64 bits et n'utilisaient que la moitié de la bande passante, mais les `` trucs '' 64 bits ne pouvaient pas fonctionner sur 32 bits sans tout doubler dans un processus appelé `` Thunking '' (MS a également fait la même erreur lorsque passer de 16 Bit Win 3.11 à Win 95 aussi avec le pack de modules complémentaires malheureux Win32S - mais c'est une histoire pour une autre fois)
Dans leur sagesse infinie et pour maintenir la «compatibilité avec les anciens logiciels», MS au lieu de faire les choses de manière sensée et d'avoir un dossier «System64» ainsi qu'un dossier «System32» a décidé de faire les choses un peu en arrière.
Au lieu de cela, ce qu'ils ont décidé de faire était de mettre TOUS les composants 64 bits dans un dossier appelé `` system32 '', la raison derrière cela était que les applications 32 bits qui, lorsqu'elles se comportaient mal et avaient des chemins codés en dur, fonctionneraient toujours sur un 64 bits système, et chargerait et utiliserait des composants du système d'exploitation 64 bits sans le réaliser.
Pendant ce temps, tous les éléments 32 bits ont été placés dans un dossier appelé «SysWOW64», qui a été redirigé de manière transparente par les appels internes du noyau du système d'exploitation lorsqu'une application 32 bits authentique et bien comportée utilisant des appels légaux du système d'exploitation a demandé une DLL 32 bits réelle, pour servir ladite 32 réelle DLL de bits à partir d'une collection de fichiers 32 bits.
Cette redirection est connue sous le nom de «couche de compatibilité Windows 64 bits sur Windows X32» d'où le nom syswow64
Maintenant, tout va bien, quand cela fonctionne et ne se fait pas abuser.
Beacuse de cet abus (qui a duré pendant les années enfer de DLL de Win XP) MS a proposé une nouvelle méthode améliorée lors de la sortie de Windows Vista appelée `` Windows Side by Side Compatibility Layer '' (Ils aiment leurs couches de compatibilité, n'est-ce pas: - ))
Cela a vu l'introduction du dossier «winsxs», et l'idée était simple
Dans ce dossier, vous placez un `` lien dur '' (oui les gens, NTFS peut faire des liens durs et logiciels comme * nix), ce lien dur doit pointer vers la DLL appropriée requise pour le bon fonctionnement de ce logiciel sur cette plate-forme.
Dans notre cas, les runtimes Visual C ++ sont maintenant installés dans un dossier sans chemin et sont ensuite liés au dossier Winsxs, Windows regarde ensuite de manière transparente l'application appelant la DLL, détermine si elle est 32 ou 64 bits et redirige l'appel vers la DLL appropriée partout où elle peut être installée.
le dossier winsxs (si vous avez le courage de le voir) aura une entrée pour chaque runtime et / ou assemblage .net sur votre PC pour chaque plate-forme prise en charge par ce runtime, et pour la plupart, il fonctionne exceptionnellement bien la plupart du temps.
Autrement dit, jusqu'à ce qu'une application folle codée en dur pour rechercher system32 disparaisse et supprime une DLL 32 bits dans ce qu'il pense être le `` dossier système 32 bits '', écrasant généralement la version 64 bits dans le processus, puis créant le lien winsxs pour les deux versions de plate-forme du runtime Visual C ++, pointez sur une version 32 bits, au lieu d'une version 32/64 bits selon ce qui a été demandé.
Ajoutez à cela le fait que pour faciliter la compatibilité, les recherches basées sur le chemin ont TOUJOURS priorité sur les appels basés sur SysWOW et winsxs, puis avoir une DLL au mauvais endroit peut signifier tout un monde de douleur.
Dans le cas de msvcrt ?? il parvient en fait à `` Thunk '' la version 32 bits dans l'espace d'adressage 64 bits et à continuer à fonctionner (c'est pourquoi QGis ne se bloque pas réellement au démarrage), mais cela peut entraîner des problèmes plus tard (comme l'application aléatoire se bloque j'étais lors de l'exécution) car l'application pense à tort que le runtime peut gérer une valeur 64 bits.
De nombreuses autres applications peuvent cependant refuser de démarrer complètement, laissant à l'utilisateur un message d'erreur générique assez cryptique qui n'aide pas du tout à résoudre le problème.
Quoi qu'il en soit, je sais que c'est un peu un roman que j'ai écrit ici, mais comme il y a encore beaucoup de gens qui rencontrent ce problème, j'espère que vous êtes maintenant armé des connaissances dont vous avez besoin pour le résoudre.
rappelez-vous juste, ce n'est pas pour la feinte de cœur, votre gâchis avec les internes du système d'exploitation ici, alors assurez- vous de sauvegarder les choses avant de commencer à changer les choses.
Je ne saurais trop insister sur ce point, si vous faites une erreur, vous pouvez rendre votre système non amorçable. Certes, je n'ai pas encore vu cela se produire, surtout lorsque les DLL impliquées ne sont que la bibliothèque d'exécution C ++, mais le risque est toujours là si vous modifiez ou déplacez accidentellement les mauvais fichiers DLL.
