Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I just downloaded QGIS 2.0 and everytime I open it I get this error message window popping up:

enter image description here

Does anyone know what this means or how I might be able to fix it? Thanks!

share|improve this question
2  
What Operating System? Looks like Windows 7 (64bit). Please confirm. –  Mapperz Sep 25 '13 at 19:18
1  
Same error here, on Win 7 64bits, stand-alone install (not through OSGEO4W). This bug occurs each time I launch QGIS 2, even if when closed, it just doesn't disturb QGIS who works fine. –  RobinC Sep 25 '13 at 21:24
2  
This is a know issue with the 64bit build of QGIS at the moment. You can just ignore it for now we are working on fixing it. –  Nathan W Sep 26 '13 at 10:20
    
I do have 64bit system, glad it's a known bug already! thank you! –  CZuck Sep 26 '13 at 20:03
    
@NathanW Please add an answer when the installer is fixed so this thread can be closed. Thanks! –  underdark Oct 5 '13 at 15:30

4 Answers 4

I ran into a similar issue with my own application some time ago. The problem wound up being caused by a third-party application which had (improperly) put its own version of the runtime DLLs in the PATH. The solution in my case is given here:

http://stackoverflow.com/questions/14552348/runtime-error-r6034-in-embedded-python-application/14680947#14680947

share|improve this answer

bit late to the party, but just wanted to share my fix here for folks that might still be having problems here.

I hit the same problem using V2.2.0 of QGis and it's been plaguing me for a while, so I finally got around to researching this and figuring out what it was.

Before I go any further though, I want to express that this fix might not work for you it appears that this is one of those errors, where the base reasons for the issue are the same, but each case has subtle little nuances that are slightly different.

In my case, I started with the excellent SO post referenced in the first answer. Being a full stack MS dev by trade, I had a gut feeling that it was some kind of RTL conflict with mscvrt rather than an actual QGis problem (Partially because I've also seen the same behavior in other apps too)

After approaching the path problem as described in the other post, and failing to get a resolution, I started to explore more using process explorer, and this lead me down the path of realizing that QGis was in fact trying to load two separate copies from two different locations of the file 'msvcr90.dll'

After realizing this I moved the copy of msvcr90.dll that was in my windows\system32 folder to a backup location well away from my main system drive, and re-ran QGis.

At this point I then got a different error, one complaining that a required DLL was missing.

Putting the file back in system32 and trying again, fixed this, but brought back the original C runtime error.

After moving the msvcr90 dll back to it's safe location, I then used some of the windows SDK/Developer tools to track the dependency graph of loaded DLL's

After doing this, a little more poking about in process explorer, showed me that QGis was also loading 'msvcp100.dll' and 'msvcr100.dll' from it's own folder, and that one or both of these DLL's had static dependencies on the 'msvcr90.dll' file that was in my system32 folder.

After a quick check to make sure I had a standard system wide install of all 3 DLL's in the correct place (The windows winsxs folder) I also moved those 2 files from QGis bin to a backup location.

I then fired QGis 2.0.2 back up and hey presto, everything started up and works without any error messages.


Now a little bit of theory for those interested

Why does this only manifest itself primarily on 64 bit systems?

Well, it has to do with the way windows manages the compatibility layer in a nutshell.

You see 'c:\windows\system32' is NOT as you would be lead to believe a 32 bit system folder.

For anyone who remembers the windows glory days, when all you had to worry about was windows 95/98, everything was all 32 bit and life was good.

Then when more powerful machines came out and we started getting 64 bit OS'es things started to get a little tricky.

32 bit 'stuff' could easily run on 64 bit and only use half the bandwidth, but 64 bit 'stuff' couldn't run on 32 bit without doubling everything up in a process called 'Thunking' (MS also made the same mistake when going from 16 Bit Win 3.11 to Win 95 too with the ill fated Win32S add-on pack - but that's a story for another time)

In their infinite wisdom and to maintain 'Compatibility with old software' , MS instead of doing things the sensible way and having a 'System64' folder as well as a 'System32' folder decided to do things a bit backwards.

Instead, what they decided to do was to put ALL the 64 bit components in a folder called 'system32', the rationale behind this was so that 32 bit apps that where badly behaved and had hard-coded paths, would still run on a 64bit system, and would load and use 64 bit OS components without actually realizing it.

Meanwhile, all the 32 bit stuff was put in a folder called 'SysWOW64', which was transparently redirected by internal OS kernel calls when a genuine well behaved 32 bit application using legal OS calls requested an actual 32 bit DLL, to serve said actual 32 bit DLL from a collection of 32 bit files.

This redirection is known as the '64 Bit Windows On Windows X32 Compatibility Layer' hence the name syswow64

Now this is all good, when it works and doesn't get abused.

Beacuse of this abuse (Which lasted through the DLL hell years of Win XP) MS came up with a new improved method when windows Vista was released called 'Windows Side by Side Compatibility Layer' (They love their compatibility layers don't they :-) )

This saw the introduction of the 'winsxs' folder , and the idea was simple

Into this folder you place a 'Hard Link' (Yes folks, NTFS can do hard and soft links just like *nix can), this Hard Link should point to the appropriate DLL required for correct operation of that software on that platform.

In our case, the visual c++ runtimes now get installed in a non pathed folder and are then linked to the winsxs folder, windows then transparently looks at the application calling the DLL, figures out if it's 32 or 64 bit and redirects the call to the appropriate DLL where ever it may be installed.

the winsxs folder (if your brave enough to view it) will have an entry for every runtime and/or .net assembly on your PC for every platform supported by that runtime, and for the large part it works exceptionally well most of the time.

That is, until some lunatic application that's hard coded to look for system32 goes and drops a 32 bit dll in what it believes is the '32 bit system folder' , usually overwritting the 64 bit version in the process, and then making the winsxs link for both platform versions of the visual C++ runtime point to a 32 bit version, instead of a 32/64 bit version depending on what's been asked for.

Couple this with the fact that again to aid compatibility, path based searches ALWAYS take precedence over SysWOW & winsxs based calls, then having that one dll in the wrong place can mean an entire world of pain.

In the case of msvcrt?? it actually manages to 'Thunk' the 32 bit version into 64 bit address space and keep working (Thats why QGis doesn't actually crash at start up), but this can lead to problems later on (Such as the random application crashes I was getting while running) due to the app mistakenly thinking the runtime can handle a 64 bit value.

Many other apps however can refuse to start-up completely leaving the user with quite a cryptic, generic error message that doesn't at all help fix the problem.

Anyway, I know it's a bit of a novel I've written here, but since there are still plenty of people out there encountering this problem, hopefully your now armed with the knowledge you need to fix it.

just remember, this is not for the feint of heart, your messing with operating system internals here, so MAKE SURE you back things up before you start changing things.

I can't stress this enough, if you make a mistake there is a chance you can make your system un-bootable. Admittedly I have yet to see this happen, esp when the DLL's involved are just the C++ runtime library, but the risk is still there if you accidentally change or move the wrong DLL files.

Hope this helps someone trying to fix their own QGis installs

Shawty

share|improve this answer

Solution of runtime error r6034 This r6034 runtime error occur when a application run without a supported system files it show error message to the user “An application has made an attempt to load the C runtime library incorrectly." To overcome from this error try to System scan with a good antivirus software and download Registry cleaner software to recover all supported system files and driver.

share|improve this answer

Restart your System because sometimes it provides solution if any file is missing, PC get chance to reload the files again. If you are currently installed any software, temporarily uninstall it. System scan is necessary with good antivirus software to remove malware from the Computer. Run the registry cleaner tool to recover the registry issue and you may able to fix runtime error r6034.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.