Fixing Runtime Error R6034: application has made attempt to load C runtime library incorrectly?

Question

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

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

Answer 1

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.

Answer 2

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:

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

Answer 3

Shawty's answer was excellent and helped me identify my issue. Process Explorer was the right scope, and killing some directories from my path was the magic bullet. (I.e. removing Intel iCLS and Intel's OpenCL SDK from my system path). Please see also Michael Cooper's answer and associated comments and other answers on SO:

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

(Although the following link is in the SO responses too...) Process Explorer was a free download at:

https://technet.microsoft.com/en-ca/sysinternals/bb896653.aspx

R6034 is a nasty, vague error. Seems like it's often a missing/bad/conflicted msvcr90.dll (C++ runtime file).

Answer 4

The solution for me was the following:

• I noticed I have installed the QGIS 32 bit. However my machine is 64 bit.
• I uninstall the QGIS and removed the registry (Run "regedit.exe" ) and deleted the QGIS folder (I'm not sure if this step is necessary. PS: If you do that, you lose all the QGIS plugins you've installed )
• Finally, I installed the QGIS 64 bit version. As consequence, the R6034 error disappeared.