Ich habe das gleiche Problem mit V2.2.0 von QGis festgestellt und es hat mich eine Weile geplagt, also habe ich mich endlich darum gekümmert, dies zu untersuchen und herauszufinden, was es war.
Bevor ich jedoch weiter gehe, möchte ich zum Ausdruck bringen, dass dieses Update möglicherweise nicht für Sie funktioniert. Es scheint, dass dies einer dieser Fehler ist, bei denen die Hauptgründe für das Problem dieselben sind, aber jeder Fall subtile kleine Nuancen aufweist, die geringfügig sind anders.
In meinem Fall habe ich mit dem ausgezeichneten SO-Beitrag begonnen, auf den in der ersten Antwort verwiesen wird. Als Full-Stack-MS-Entwickler von Beruf hatte ich das Gefühl, dass es sich eher um einen RTL-Konflikt mit mscvrt als um ein tatsächliches QGis-Problem handelt (teilweise, weil ich das gleiche Verhalten auch in anderen Apps gesehen habe).
Nachdem ich mich dem Pfadproblem wie im anderen Beitrag beschrieben genähert hatte und keine Lösung gefunden hatte, begann ich, mehr mit dem Prozess-Explorer zu untersuchen. Dies führte mich auf den Weg zu der Erkenntnis, dass QGis tatsächlich versuchte, zwei separate Kopien von zwei zu laden verschiedene Speicherorte der Datei 'msvcr90.dll'
Nachdem ich dies erkannt hatte, verschob ich die Kopie von msvcr90.dll, die sich in meinem Ordner Windows \ system32 befand, an einen Sicherungsspeicherort weit entfernt von meinem Hauptsystemlaufwerk und führte QGis erneut aus.
Zu diesem Zeitpunkt erhielt ich dann einen anderen Fehler, der sich darüber beschwerte, dass eine erforderliche DLL fehlte.
Das Zurücksetzen der Datei in system32 und das erneute Versuchen haben dies behoben, aber den ursprünglichen C-Laufzeitfehler zurückgebracht.
Nachdem ich die msvcr90-DLL wieder an ihren sicheren Speicherort verschoben hatte, verwendete ich einige der Windows SDK / Developer-Tools, um das Abhängigkeitsdiagramm der geladenen DLLs zu verfolgen
Nachdem ich dies getan hatte, zeigte mir ein wenig mehr im Prozess-Explorer, dass QGis auch 'msvcp100.dll' und 'msvcr100.dll' aus seinem eigenen Ordner lud und dass eine oder beide dieser DLLs statische Abhängigkeiten von ' msvcr90.dll 'Datei, die sich in meinem system32-Ordner befand.
Nach einer kurzen Überprüfung, um sicherzustellen, dass ich eine systemweite Standardinstallation aller 3 DLLs am richtigen Ort hatte (Der Windows Winsxs-Ordner), habe ich diese 2 Dateien auch aus dem QGis-Bin an einen Sicherungsspeicherort verschoben.
Ich habe dann QGis 2.0.2 gesichert und hey Presto, alles wurde gestartet und funktioniert ohne Fehlermeldungen.
Nun ein bisschen Theorie für Interessierte
Warum manifestiert sich dies nur in erster Linie auf 64-Bit-Systemen?
Nun, es hat damit zu tun, wie Windows die Kompatibilitätsebene auf den Punkt bringt.
Sie sehen, dass 'c: \ windows \ system32' NICHT so ist, wie Sie glauben würden, ein 32-Bit-Systemordner.
Für alle, die sich an die Windows-Ruhmestage erinnern, als alles, worüber Sie sich Sorgen machen mussten, Windows 95/98 war, war alles 32-Bit und das Leben war gut.
Dann, als leistungsstärkere Maschinen herauskamen und wir anfingen, 64-Bit-Betriebssysteme zu bekommen, wurde es etwas schwierig.
32-Bit-Zeug könnte leicht auf 64-Bit ausgeführt werden und nur die Hälfte der Bandbreite verbrauchen, aber 64-Bit-Zeug könnte nicht auf 32-Bit ausgeführt werden, ohne alles in einem Prozess namens "Thunking" zu verdoppeln (MS machte auch den gleichen Fehler, als mit dem unglücklichen Win32S-Add-On-Paket von 16-Bit-Win 3.11 auf Win 95 umsteigen - aber das ist eine Geschichte für ein anderes Mal)
In ihrer unendlichen Weisheit und um die Kompatibilität mit alter Software aufrechtzuerhalten, entschied sich MS, anstatt die Dinge auf vernünftige Weise zu tun und einen 'System64'-Ordner sowie einen' System32'-Ordner zu haben, die Dinge etwas rückwärts zu machen.
Stattdessen beschlossen sie, ALLE 64-Bit-Komponenten in einem Ordner namens "system32" abzulegen. Der Grund dafür war, dass 32-Bit-Apps, die sich schlecht benahmen und fest codierte Pfade hatten, immer noch auf 64-Bit ausgeführt werden System und würde 64-Bit-Betriebssystemkomponenten laden und verwenden, ohne es tatsächlich zu bemerken.
In der Zwischenzeit wurde das gesamte 32-Bit-Material in einem Ordner namens "SysWOW64" abgelegt, der durch interne Kernelaufrufe des Betriebssystems transparent umgeleitet wurde, als eine echte gut erzogene 32-Bit-Anwendung mit legalen Betriebssystemaufrufen eine tatsächliche 32-Bit-DLL anforderte, um diese 32 zu bedienen Bit-DLL aus einer Sammlung von 32-Bit-Dateien.
Diese Umleitung wird als "64-Bit-Windows unter Windows X32-Kompatibilitätsschicht" bezeichnet, daher der Name "syswow64"
Das ist alles gut, wenn es funktioniert und nicht missbraucht wird.
Wegen dieses Missbrauchs (der während der DLL-Höllenjahre von Win XP andauerte) entwickelte MS eine neue verbesserte Methode, als Windows Vista mit dem Namen "Windows Side by Side Compatibility Layer" veröffentlicht wurde (sie lieben ihre Kompatibilitätsebenen, nicht wahr: - ))
Dies führte zur Einführung des Ordners 'winsxs', und die Idee war einfach
In diesen Ordner legen Sie einen 'Hard Link' (Ja Leute, NTFS kann Hard- und Softlinks genauso ausführen wie * nix). Dieser Hardlink sollte auf die entsprechende DLL verweisen, die für den korrekten Betrieb dieser Software auf dieser Plattform erforderlich ist.
In unserem Fall werden die visuellen c ++ - Laufzeiten jetzt in einem Ordner ohne Pfad installiert und dann mit dem Ordner winsxs verknüpft. Windows betrachtet dann transparent die Anwendung, die die DLL aufruft, stellt fest, ob es sich um 32- oder 64-Bit handelt, und leitet den Aufruf an den weiter geeignete DLL, wo immer sie installiert werden kann.
Der Ordner "winsxs" (wenn Sie mutig genug sind, ihn anzuzeigen) enthält einen Eintrag für jede Laufzeit- und / oder .net-Assembly auf Ihrem PC für jede von dieser Laufzeit unterstützte Plattform, und zum größten Teil funktioniert er die meiste Zeit außergewöhnlich gut.
Das heißt, bis eine verrückte Anwendung, die schwer zu programmieren ist, um nach system32 zu suchen, eine 32-Bit-DLL in den '32-Bit-Systemordner 'legt, wobei sie normalerweise die 64-Bit-Version überschreibt und dann die Winsxs-Verknüpfung herstellt Zeigen Sie für beide Plattformversionen der visuellen C ++ - Laufzeit auf eine 32-Bit-Version anstelle einer 32/64-Bit-Version, je nachdem, was angefordert wurde.
Gepaart mit der Tatsache , dass wieder zu Hilfe Kompatibilität, Pfad basierte Suche immer Vorrang vor SYSWOW nehmen & winsxs basierte Anrufe, dann , dass an der falschen Stelle eine DLL, die eine ganze Welt der Schmerzen bedeuten kann.
Im Falle von msvcrt ?? Es schafft es tatsächlich, die 32-Bit-Version in den 64-Bit-Adressraum zu "thunk" und weiter zu arbeiten (deshalb stürzt QGis beim Start nicht ab), aber dies kann später zu Problemen führen (wie zum Beispiel die zufällige Anwendung, die ich abstürzte während der Ausführung), da die App fälschlicherweise denkt, dass die Laufzeit einen 64-Bit-Wert verarbeiten kann.
Viele andere Apps können sich jedoch weigern, vollständig zu starten, sodass der Benutzer eine ziemlich kryptische, generische Fehlermeldung erhält, die das Problem überhaupt nicht behebt.
Wie auch immer, ich weiß, es ist ein bisschen wie ein Roman, den ich hier geschrieben habe, aber da es immer noch viele Leute gibt, die auf dieses Problem stoßen, sind Sie jetzt hoffentlich mit dem Wissen ausgestattet, das Sie brauchen, um es zu beheben.
Denken Sie daran, dies ist nichts für schwache Nerven, da Sie hier mit den Interna des Betriebssystems herumspielen. Stellen Sie also sicher, dass Sie die Daten sichern , bevor Sie anfangen, sie zu ändern.
Ich kann das nicht genug betonen. Wenn Sie einen Fehler machen, besteht die Möglichkeit, dass Ihr System nicht mehr bootfähig ist. Zugegeben, ich habe dies noch nicht gesehen, insbesondere wenn es sich bei den beteiligten DLLs nur um die C ++ - Laufzeitbibliothek handelt, aber das Risiko besteht weiterhin, wenn Sie versehentlich die falschen DLL-Dateien ändern oder verschieben.
