QGisのV2.2.0を使用して同じ問題にぶつかり、しばらくの間悩まされてきたので、ようやくこれを調査して、それが何であるかを理解することに取りかかりました。
先に進む前に、この修正が機能しない可能性があることを表明したいと思います。これはそれらのエラーの1つであり、問題の基本的な理由は同じですが、それぞれのケースには微妙な微妙なニュアンスがあります違う。
私の場合、最初の回答で参照された優れたSO投稿から始めました。フルスタックのMS開発者であるため、実際のQGisの問題ではなく、mscvrtとのRTLの競合のようなものだと直感しました（一部、他のアプリでも同じ動作を見たことがあります）
他の投稿で説明されているようにパスの問題に取り組み、解決策を得ることができなかった後、私はプロセスエクスプローラーを使用してさらに探索し始めました。 'msvcr90.dll'ファイルの別の場所
これに気付いた後、windows \ system32フォルダーにあるmsvcr90.dllのコピーをメインシステムドライブから離れたバックアップ場所に移動し、QGisを再実行しました。
この時点で、別のエラーが発生しました。1つは、必要なDLLが欠落していることを訴えています。
ファイルをsystem32に戻して再試行すると、これは修正されましたが、元のCランタイムエラーが返されました。
msvcr90 dllを安全な場所に戻した後、Windows SDK /開発者ツールのいくつかを使用して、読み込まれたDLLの依存関係グラフを追跡しました
これを実行した後、プロセスエクスプローラーで少し突っ込んで、QGisが 'msvcp100.dll'と 'msvcr100.dll'をその独自のフォルダーから読み込んでいること、およびこれらのDLLの1つまたは両方が '私のsystem32フォルダーにあったmsvcr90.dll 'ファイル。
3つのDLLすべてを正しい場所（windows winsxsフォルダー）にシステム全体で標準インストールしたことを確認した後、これら2つのファイルをQGis binからバックアップの場所に移動しました。
次に、QGis 2.0.2を起動してprestoを起動しました。すべてが起動し、エラーメッセージなしで動作しました。
今興味のある人のための理論の少し
これは主に64ビットシステムでのみ発生するのはなぜですか？
まあ、それはウィンドウが一言で言えば互換性レイヤーを管理する方法と関係があります。
「c：\ windows \ system32」は、32ビットのシステムフォルダを信じるように誘導されるものではないことがわかります。
Windowsの栄光の日々を思い出す人なら、心配する必要があるのはWindows 95/98だけだったのに、すべてが32ビットであり、人生は良かったです。
その後、より強力なマシンが登場し、64ビットOSを入手し始めると、少しトリッキーになり始めました。
32ビットの「もの」は64ビットで簡単に実行でき、帯域幅の半分しか使用できませんが、64ビットの「もの」は「サンキング」と呼ばれるプロセスですべてを2倍にしないと32ビットで実行できませんでした（MSも同じミスを犯しました運命の悪いWin32Sアドオンパックで16ビットWin 3.11からWin 95に移行する-しかし、それはまた別の話です）
MSは無限の知恵と「古いソフトウェアとの互換性」を維持するために、賢明な方法で物事を行う代わりに、「System64」フォルダーと「System32」フォルダーを使用する代わりに、少し後方に物事を行うことにしました。
その代わり、彼らがやろうと決めたのは、すべての64ビットコンポーネントを「system32」というフォルダーに配置することでした。これの背後にある理論的根拠は、動作が悪く、ハードコーディングされたパスを持つ32ビットアプリが64ビットで実行できるようにすることでした。システム、および実際には実現せずに64ビットOSコンポーネントをロードして使用します。
その間、すべての32ビットのものは「SysWOW64」と呼ばれるフォルダーに入れられました。合法的なOS呼び出しを使用する正規の動作の32ビットアプリケーションが実際の32ビットDLLを要求し、実際の32ビットDLLを要求したときに、内部OSカーネル呼び出しによって透過的にリダイレクトされました。 32ビットファイルのコレクションからのビットDLL。
このリダイレクトは「64ビットWindows On Windows X32互換性レイヤー」として知られているため、syswow64という名前です。
それが機能し、悪用されない場合、これはすべて問題ありません。
この乱用の理由（Win XPのDLLの地獄の年月まで続いた）MSは、Windows Vistaがリリースされたときに、「Windows Side by Side互換性レイヤー」と呼ばれる新しい改良された方法を思い付きました（彼らは互換性レイヤーを愛していません：- ））
これは「winsxs」フォルダの導入を見たもので、アイデアはシンプルでした
このフォルダーに「ハードリンク」を配置します（はい、皆さん、NTFSは* nixと同じようにハードリンクとソフトリンクを実行できます）。このハードリンクは、そのプラットフォームでのそのソフトウェアの正しい動作に必要な適切なDLLを指す必要があります。
今回のケースでは、ビジュアルc ++ランタイムがパスのないフォルダーにインストールされ、winsxsフォルダーにリンクされます。次に、ウィンドウはDLLを呼び出すアプリケーションを透過的に調べ、32ビットか64ビットかを判断して、呼び出しをインストールされる可能性のある場所に適切なDLL。
winsxsフォルダー（それを表示するのに十分な勇気がある場合）には、そのランタイムでサポートされているすべてのプラットフォームのPC上のすべてのランタイムおよび.netアセンブリのエントリがあり、ほとんどの場合、非常によく機能します。
つまり、system32を探すようにハードコーディングされている狂気のアプリケーションが「32ビットシステムフォルダー」であると信じているところに32ビットdllがドロップされるまで、通常はプロセスで64ビットバージョンを上書きしてから、winsxsリンクを作成します。どちらのプラットフォームバージョンのビジュアルC ++ランタイムでも、要求された内容に応じて32/64ビットバージョンではなく、32ビットバージョンをポイントします。
再び援助の互換性に、パスベースの検索がいるという事実のカップルこれを常に、間違った場所に1つのDLLは、痛みの世界全体を意味することができた、呼び出しをベースSysWOW＆winsxsよりも優先されます。
msvcrtの場合？それは実際に32ビットバージョンを64ビットアドレス空間に「サンク」して機能し続けます（そのため、QGisは実際に起動時にクラッシュしません）が、後で問題が発生する可能性があります（ランダムアプリケーションがクラッシュするなど）実行中に取得）ランタイムが64ビット値を処理できるとアプリが誤って考えているためです。
ただし、他の多くのアプリは、起動を完全に拒否して、問題の修正にまったく役立たない非常に不可解な一般的なエラーメッセージをユーザーに残します。
とにかく、私がここで書いたのは少し小説であることはわかっていますが、この問題に遭遇している人はまだまだたくさんいるので、修正に必要な知識で武装していることを願っています。
ただこれは、ここにオペレーティングシステムの内部であなたのメッシング、心のフェイントのためではない、覚えていることを確認してくださいは、あなたが物事を変更する開始する前に、あなたが物事をバックアップします。
私はこれを十分に強調することはできません。もし間違いを犯した場合、システムをブート不能にする可能性があります。確かに私はまだこれが起こるのを見ていません。特に、DLLがC ++ランタイムライブラリのみの場合は、誤ったDLLファイルを誤って変更または移動した場合でもリスクは残ります。
