Eu enfrentei o mesmo problema usando a V2.2.0 do QGis e ele está me atormentando há um tempo, então eu finalmente comecei a pesquisar isso e descobrir o que era.
Antes de prosseguir, quero expressar que essa correção pode não funcionar para você ; parece que esse é um desses erros, em que os motivos básicos do problema são os mesmos, mas cada caso tem pequenas sutis nuances levemente diferente.
No meu caso, comecei com o excelente post do SO mencionado na primeira resposta. Por ser um desenvolvedor de MS de pilha cheia por comércio, tive a sensação de que havia algum tipo de conflito de RTL com o mscvrt em vez de um problema real de QGis (em parte porque também vi o mesmo comportamento em outros aplicativos)
Depois de abordar o problema do caminho, conforme descrito na outra postagem, e não conseguir obter uma resolução, comecei a explorar mais usando o Process Explorer, e isso me levou a perceber que o QGis estava de fato tentando carregar duas cópias separadas de duas. locais diferentes do arquivo 'msvcr90.dll'
Depois de perceber isso, movi a cópia do msvcr90.dll que estava na minha pasta windows \ system32 para um local de backup bem longe da unidade principal do sistema e executei novamente o QGis.
Nesse ponto, recebi um erro diferente, um queixava-se de que estava faltando uma DLL necessária.
Colocar o arquivo de volta no system32 e tentar novamente, corrigiu isso, mas trouxe de volta o erro original do tempo de execução em C.
Depois de mover a dll msvcr90 de volta para o local seguro, usei algumas das ferramentas do SDK / Developer do Windows para rastrear o gráfico de dependência de DLLs carregadas
Depois de fazer isso, um pouco mais sobre o processo explorador, mostrou-me que o QGis também estava carregando 'msvcp100.dll' e 'msvcr100.dll' de sua própria pasta e que uma ou ambas as DLLs tinham dependências estáticas no arquivo ' arquivo msvcr90.dll 'que estava na minha pasta system32.
Após uma verificação rápida para garantir que eu tenha uma instalação padrão do sistema em todas as 3 DLLs no local correto (pasta Windows winsxs), também movi esses 2 arquivos do QGis bin para um local de backup.
Em seguida, despedi o QGis 2.0.2 e, pronto, tudo foi iniciado e funciona sem nenhuma mensagem de erro.
Agora um pouco de teoria para os interessados
Por que isso só se manifesta principalmente em sistemas de 64 bits?
Bem, isso tem a ver com a maneira como o Windows gerencia a camada de compatibilidade em poucas palavras.
Você vê que 'c: \ windows \ system32' NÃO é como você levaria a acreditar em uma pasta do sistema de 32 bits.
Para quem se lembra dos dias de glória do Windows, quando você só precisava se preocupar com o Windows 95/98, tudo era de 32 bits e a vida era boa.
Então, quando máquinas mais poderosas surgiram e começamos a obter sistemas operacionais de 64 bits, as coisas começaram a ficar um pouco complicadas.
O 'material' de 32 bits pode ser executado facilmente em 64 bits e usa apenas metade da largura de banda, mas o 'material' de 64 bits não pode ser executado em 32 bits sem dobrar tudo em um processo chamado 'Thunking' (a MS também cometeu o mesmo erro quando passando do 16 Bit Win 3.11 para o Win 95 também com o mal-intencionado pacote adicional do Win32S - mas essa é uma história para outra hora)
Em sua infinita sabedoria e para manter 'Compatibilidade com software antigo', a MS, em vez de fazer as coisas da maneira mais sensata e com uma pasta 'System64' e uma pasta 'System32', decidiu fazer as coisas um pouco para trás.
Em vez disso, o que eles decidiram fazer foi colocar TODOS os componentes de 64 bits em uma pasta chamada 'system32', a lógica por trás disso era que aplicativos de 32 bits que se comportassem mal e tivessem caminhos codificados permaneciam em execução em 64 bits sistema e carregaria e usaria componentes de sistema operacional de 64 bits sem realmente perceber.
Enquanto isso, todo o material de 32 bits foi colocado em uma pasta chamada 'SysWOW64', que foi redirecionada de forma transparente por chamadas internas do kernel do sistema operacional quando um aplicativo genuíno e bem comportado de 32 bits usando chamadas legais do sistema operacional solicitou uma DLL real de 32 bits, para servir os 32 bits reais. DLL de bits de uma coleção de arquivos de 32 bits.
Esse redirecionamento é conhecido como 'Camada de Compatibilidade Windows 64 no Windows X32' e, portanto, o nome syswow64
Agora isso é bom, quando funciona e não é abusado.
Devido a esse abuso (que durou os anos infernais da DLL do Win XP), a Microsoft surgiu com um novo método aprimorado quando o Windows Vista foi lançado, chamado 'Windows Side by Side Compatibility Layer' (eles amam suas camadas de compatibilidade, não gostam: - ))
Isso viu a introdução da pasta 'winsxs' e a ideia era simples
Nesta pasta, você coloca um 'Hard Link' (Sim, pessoal, o NTFS pode fazer hard e soft links assim como * nix), esse Hard Hard deve apontar para a DLL apropriada necessária para a operação correta desse software nessa plataforma.
No nosso caso, os tempos de execução do visual c ++ agora são instalados em uma pasta não encaminhada e, em seguida, são vinculados à pasta winsxs, o Windows olha de forma transparente para o aplicativo que chama a DLL, descobre se é 32 ou 64 bits e redireciona a chamada para o diretório DLL apropriada onde quer que esteja.
a pasta winsxs (se você for corajoso o suficiente para visualizá-la) terá uma entrada para cada conjunto de tempo de execução e / ou .net no seu PC para todas as plataformas suportadas por esse tempo de execução e, em grande parte, ele funciona excepcionalmente bem na maioria das vezes.
Ou seja, até que algum aplicativo lunático codificado para procurar system32 vá e solte uma dll de 32 bits no que acredita ser a 'pasta do sistema de 32 bits', geralmente substituindo a versão de 64 bits no processo e fazendo o link winsxs para as duas versões de plataforma do tempo de execução visual do C ++, aponte para uma versão de 32 bits, em vez de uma versão de 32/64 bits, dependendo do que foi solicitado.
Junte isso ao fato de que, novamente, para ajudar na compatibilidade, as pesquisas baseadas em caminhos SEMPRE têm precedência sobre as chamadas baseadas em SysWOW e winsxs; depois, ter uma DLL no lugar errado pode significar um mundo inteiro de dor.
No caso de msvcrt ?? ele realmente consegue 'Thunk' a versão de 32 bits no espaço de endereço de 64 bits e continua trabalhando (é por isso que o QGis não falha na inicialização), mas isso pode levar a problemas mais tarde (como o aplicativo aleatório trava) ficando em execução) devido ao aplicativo pensar erroneamente que o tempo de execução pode lidar com um valor de 64 bits.
Porém, muitos outros aplicativos podem se recusar a iniciar completamente, deixando ao usuário uma mensagem de erro genérica e enigmática que não ajuda em nada a resolver o problema.
De qualquer forma, sei que é um romance que escrevi aqui, mas como ainda há muitas pessoas por aí que enfrentam esse problema, espero que agora você esteja armado com o conhecimento necessário para corrigi-lo.
apenas lembre-se, isso não é para quem finge coração, você está mexendo com os sistemas operacionais aqui, por isso certifique- se de fazer o backup das coisas antes de começar a mudar as coisas.
Não posso enfatizar isso o suficiente, se você cometer um erro, há uma chance de tornar seu sistema não inicializável. É certo que ainda não vi isso acontecer, especialmente quando as DLLs envolvidas são apenas a biblioteca de tempo de execução C ++, mas o risco ainda existe se você acidentalmente alterar ou mover os arquivos DLL errados.
