Saya mengalami masalah yang sama dengan menggunakan Q2 V2.2.0 dan sudah mengganggu saya untuk sementara waktu, jadi saya akhirnya mencari untuk meneliti ini dan mencari tahu apa itu.
Sebelum saya melangkah lebih jauh, saya ingin menyatakan bahwa perbaikan ini mungkin tidak berhasil untuk Anda . Tampaknya ini adalah salah satu kesalahan tersebut, di mana alasan dasar untuk masalah ini adalah sama, tetapi setiap kasus memiliki nuansa kecil halus yang sedikit berbeda.
Dalam kasus saya, saya mulai dengan posting SO yang sangat baik direferensikan dalam jawaban pertama. Menjadi stack MS dev penuh oleh perdagangan, saya punya firasat bahwa itu semacam konflik RTL dengan mscvrt daripada masalah QGis yang sebenarnya (Sebagian karena saya juga melihat perilaku yang sama di aplikasi lain juga)
Setelah mendekati masalah jalur seperti yang dijelaskan di posting lain, dan gagal mendapatkan resolusi, saya mulai mengeksplorasi lebih banyak menggunakan proses explorer, dan ini membawa saya ke jalan menyadari bahwa QGis sebenarnya mencoba memuat dua salinan terpisah dari dua lokasi berbeda dari file 'msvcr90.dll'
Setelah menyadari ini, saya memindahkan salinan msvcr90.dll yang ada di folder windows \ system32 saya ke lokasi cadangan jauh dari drive sistem utama saya, dan menjalankan kembali QGis.
Pada titik ini saya kemudian mendapat kesalahan yang berbeda, satu mengeluh bahwa DLL yang diperlukan hilang.
Menempatkan file kembali di system32 dan mencoba lagi, memperbaikinya, tetapi membawa kembali kesalahan runtime C asli.
Setelah memindahkan dll msvcr90 ke lokasi yang aman, saya kemudian menggunakan beberapa jendela SDK / Alat pengembang untuk melacak grafik ketergantungan DLL yang dimuat
Setelah melakukan ini, sedikit lebih menyodok tentang dalam proses explorer, menunjukkan kepada saya bahwa QGis juga memuat 'msvcp100.dll' dan 'msvcr100.dll' dari folder itu sendiri, dan bahwa satu atau kedua DLL ini memiliki dependensi statis pada ' File msvcr90.dll 'yang ada di folder system32 saya.
Setelah pemeriksaan cepat untuk memastikan saya memiliki instalasi standar sistem yang luas dari semua 3 DLL di tempat yang benar (Folder Windows winxs) Saya juga memindahkan 2 file dari QGis bin ke lokasi cadangan.
Saya kemudian meluncurkan kembali QGis 2.0.2 dan hei presto, semuanya dimulai dan berfungsi tanpa pesan kesalahan.
Sekarang sedikit teori untuk mereka yang tertarik
Mengapa ini hanya memanifestasikan dirinya sendiri terutama pada sistem 64 bit?
Yah, itu ada hubungannya dengan cara windows mengelola lapisan kompatibilitas secara singkat.
Anda melihat 'c: \ windows \ system32' BUKAN karena Anda akan dituntun untuk percaya folder sistem 32 bit.
Bagi siapa pun yang mengingat masa kejayaan windows, ketika yang harus Anda khawatirkan adalah windows 95/98, semuanya serba 32 bit dan hidup itu baik.
Kemudian ketika mesin yang lebih kuat keluar dan kami mulai mendapatkan OS 64 bit hal-hal mulai menjadi sedikit rumit.
32 bit 'barang' dapat dengan mudah berjalan pada 64 bit dan hanya menggunakan setengah bandwidth, tetapi 'barang' 64 bit tidak dapat berjalan pada 32 bit tanpa menggandakan semuanya dalam proses yang disebut 'Pemukulan' (MS juga membuat kesalahan yang sama ketika pergi dari 16 Bit Win 3.11 ke Win 95 juga dengan paket add-on Win32S yang bernasib buruk - tapi itu cerita lain kali)
Dalam kebijaksanaan mereka yang tak terbatas dan untuk menjaga 'Kompatibilitas dengan perangkat lunak lama', MS bukannya melakukan hal-hal dengan cara yang masuk akal dan memiliki folder 'System64' serta folder 'System32' memutuskan untuk melakukan hal-hal sedikit mundur.
Sebaliknya, apa yang mereka putuskan untuk lakukan adalah menempatkan SEMUA komponen 64 bit dalam folder yang disebut 'system32', alasan di balik ini adalah agar aplikasi 32 bit yang berperilaku buruk dan memiliki jalur kode keras, masih akan berjalan pada 64bit sistem, dan akan memuat dan menggunakan komponen OS 64 bit tanpa benar-benar menyadarinya.
Sementara itu, semua 32 bit dimasukkan ke dalam folder yang disebut 'SysWOW64', yang secara transparan dialihkan oleh panggilan kernel OS internal ketika aplikasi 32 bit berperilaku baik menggunakan panggilan OS legal meminta DLL 32 bit yang sebenarnya, untuk melayani sebenarnya 32 bit DLL dari kumpulan file 32 bit.
Pengalihan ini dikenal sebagai '64 Bit Windows On Windows X32 Compatibility Layer 'maka nama syswow64
Sekarang ini semua baik, ketika berhasil dan tidak disalahgunakan.
Karena penyalahgunaan ini (Yang berlangsung selama bertahun-tahun DLL tahun Win XP) MS datang dengan metode baru yang ditingkatkan ketika windows Vista dirilis disebut 'Windows Side by Side Compatibility Layer' (Mereka suka lapisan kompatibilitas mereka bukan: - ))
Ini melihat pengantar folder 'winsxs', dan idenya sederhana
Ke dalam folder ini Anda meletakkan 'Hard Link' (Ya, NTFS dapat melakukan tautan keras dan lunak seperti * nix can), Hard Link ini harus mengarah ke DLL yang diperlukan untuk operasi yang benar dari perangkat lunak pada platform itu.
Dalam kasus kami, runtime visual c ++ sekarang dipasang di folder non pathed dan kemudian ditautkan ke folder winsxs, windows kemudian secara transparan melihat aplikasi yang memanggil DLL, mencari tahu apakah itu 32 atau 64 bit dan mengalihkan panggilan ke DLL yang sesuai di mana pun itu mungkin diinstal.
folder winsxs (jika Anda cukup berani untuk melihatnya) akan memiliki entri untuk setiap runtime dan / atau .net assembly pada PC Anda untuk setiap platform yang didukung oleh runtime itu, dan untuk sebagian besar itu berfungsi sangat baik sebagian besar waktu.
Yaitu, sampai beberapa aplikasi gila yang sulit dikodekan untuk mencari system32 berjalan dan menjatuhkan 32 bit dll dalam apa yang diyakininya adalah '32 bit system folder ', biasanya menimpa versi 64 bit dalam proses, dan kemudian membuat tautan winxs untuk kedua versi platform dari titik runtime C ++ visual ke versi 32 bit, bukan versi 32/64 bit tergantung pada apa yang diminta.
Pasangan ini dengan fakta bahwa sekali lagi untuk membantu kompatibilitas, pencarian berbasis path SELALU diutamakan daripada panggilan berbasis SysWOW & winxs, kemudian memiliki satu dll di tempat yang salah dapat berarti seluruh dunia sakit.
Dalam hal msvcrt ?? itu benar-benar berhasil 'Thunk' versi 32 bit ke dalam ruang alamat 64 bit dan tetap bekerja (Itulah mengapa QGis tidak benar-benar crash saat start up), tetapi ini dapat menyebabkan masalah di kemudian hari (Seperti aplikasi acak crash saya adalah mendapatkan saat menjalankan) karena aplikasi keliru berpikir runtime dapat menangani nilai 64 bit.
Namun banyak aplikasi lain dapat menolak untuk memulai sepenuhnya meninggalkan pengguna dengan cukup, pesan kesalahan generik samar yang sama sekali tidak membantu memperbaiki masalah.
Ngomong-ngomong, saya tahu ini sedikit novel yang saya tulis di sini, tetapi karena masih banyak orang di luar sana yang menghadapi masalah ini, semoga sekarang Anda dipersenjatai dengan pengetahuan yang Anda butuhkan untuk memperbaikinya.
hanya ingat, ini bukan untuk tipuan hati, kekacauan Anda dengan sistem operasi internal di sini, jadi PASTIKAN Anda mendukung semuanya sebelum Anda mulai mengubah hal-hal.
Saya tidak bisa cukup menekankan hal ini, jika Anda membuat kesalahan, ada kemungkinan Anda dapat membuat sistem Anda tidak dapat di-boot. Memang saya belum melihat ini terjadi, terutama ketika DLL yang terlibat hanyalah pustaka runtime C ++, tetapi risikonya masih ada jika Anda secara tidak sengaja mengubah atau memindahkan file DLL yang salah.
