Runtime error R6034 in embedded Python application

Question

I am working on an application which uses Boost.Python to embed the Python interpreter. This is used to run user-generated "scripts" which interact with the main program.

Unfortunately, one user is reporting runtime error R6034 when he tries to run a script. The main program starts up fine, but I think the problem may be occurring when python27.dll is loaded.

I am using Visual Studio 2005, Python 2.7, and Boost.Python 1.46.1. The problem occurs only on one user's machine. I've dealt with manifest issues before, and managed to resolve them, but in this case I'm at a bit of a loss.

Has anyone else run into a similar problem? Were you able to solve it? How?

Solution 1

I found the solution to the problem. Hopefully this will help someone else--these problems can be so frustrating to debug.

The problem was caused by third-party software that had added itself to the path and installed msvcr90.dll in its program folder. In this case, the problem was caused by Intel's iCLS Client.

So... How to find the problem in similar situations?

1. Download Process Explorer here.

2. Start your application and reproduce runtime error R6034.

3. Start Process Explorer. In the "View" menu go to "Lower Pane View" and choose "DLLs".

4. In the top pane, locate your application and click on it. The bottom pane should show a list of DLLS loaded for your application.

5. Locate "msvcr??.dll" in the list. There should be several. Look for the one that is not in the "winsxs" folder, and make a note of it.

6. Now, check the path just before your application runs. If it includes the folder you noted in step 5, you've probably found the culprit.

How to fix the problem? You'll have to remove the offending entry from the path before running your program. In my case, I don't need anything else in the path, so I wrote a simple batch file that looks like this:

path=
myprogram.exe

That's it. The batch file simply clears the path before my program runs, so that the conflicting runtime DLL is not found.

Hope this helps!

Solution 2

This post elaborates on @Micheal Cooper and @frmdstryr and gives a better alternative than my earlier answer. You can put the following in front of a python script to purge the problematic entries.

import os, re
path = os.environ['PATH'].split(';')

def is_problem(folder):
    try:
        for item in os.listdir(folder):
            if re.match(r'msvcr\d\d\.dll', item):
                return True
    except:
        pass
    return False

path = [folder for folder in path if not is_problem(folder)]
os.environ['PATH'] = ';'.join(path)

For the vim with YouCompleteMe case, you can put the following at the top of your vimrc:

python << EOF
import os, re
path = os.environ['PATH'].split(';')

def is_problem(folder):
    try:
        for item in os.listdir(folder):
            if re.match(r'msvcr\d\d\.dll', item):
                return True
    except:
        pass
    return False

path = [folder for folder in path if not is_problem(folder)]
os.environ['PATH'] = ';'.join(path)
EOF

Solution 3

A more general solution is:

import os
os.environ['path'] = ";".join(
    [path for path in os.environ['path'].split(";") 
     if "msvcr90.dll" not in map((lambda x:x.lower()), os.listdir(path))])

(I had the same problem with VanDyke SecureCRT)

Solution 4

(This might be better as a comment than a full answer, but my dusty SO acct. doesn't yet have enough rep for that.)

Like the OP I was also using an embedded Python 2.7 and some other native assemblies.

Complicating this nicely was the fact that my application was a med-large .Net solution running on top of 64-Bit IIS Express (VS2013).

I tried Dependency Walker (great program, but too out of date to help with this), and Process Monitor (ProcMon -- which probably did find some hints, but even though I was using filters the problems were buried in thousands of unrelated operations, better filters may have helped).

However, MANY THANKS to Michael Cooper! Your steps and Process Explorer (procexp) got me quickly to a solution that had been dodging me all day.

I can add a couple of notes to Michael's excellent post.

• I ignored (i.e. left unchanged) not just the \WinSxS\... folder but also the \System32\... folder.

Ultimately I found msvcr90.dll being pulled in from:

• C:\Program Files (x86)\Intel\OpenCL SDK\2.0\bin\x64

Going through my Path I found the above and another, similar directory which seemed to contain 32-bit versions. I removed both of these, restarted and... STILL had the problem.

So, I followed Michael's steps once more, and, discovered another msvcr90.dll was now being loaded from:

• C:\Program Files\Intel\iCLS Client\

Going through my Path again, I found the above and an (x86) version of this directory as well. So, I removed both of those, applied the changes, restarted VS2013 and...

No more R6034 Error!

I can't help but feel frustrated with Intel for doing this. I had actually found elsewhere online a tip about removing iCLS Client from the Path. I tried that, but the symptom was the same, so, I thought that wasn't the problem. Sadly iCLS Client and OpenCL SDK were tag-teaming my iisexpress. If I was lucky enough to remove either one, the R6034 error remained. I had to excise both of them in order to cure the problem.

Thanks again to Michael Cooper and everyone else for your help!

Solution 5

Using Michael's answer above, I was able to resolve this without a bat file by adding:

import os

# Remove CLS Client from system path
if os.environ['PATH'].find("iCLS Client")>=0:
    os.environ['PATH'] = "".join([it for it in os.environ['PATH'].split(";") if not it.find("iCLS Client")>0])

to the main python file of the application. It just makes sure system path didn't include the paths that were causing the issue before the libraries that loaded the dll's were imported.

Thanks!

View more solutions

Comments

[Daniel]

You sir, are a champion! For me I was trying to use YouCompleteMe for gVim, and cmake was the offender that had added it's bin directory to the path which contained msvcr90.dll. Thanks for the excellent instructions

[TomiL]

Really helpful! I was having trouble using "gdb.exe" with "mingw" on Windows, when running Omnet++ simulation, where program was throwing error R6034. When I exclude CMAKE include from the Windows' PATH, it now works like a charm. thanks!

[denfromufa]

how can the path be temporarily cleaned in Visual Studio?

[martinako]

is it OK if the "msvcr??.dll" is in the c:\windows\SysWOW64?

[Michael Cooper]

@martinako I would be cautious of that one. The winsxs folder can contain many different versions of the DLL and the system knows how to find one that's compatible with your application. If the DLL is in the SysWOW64 folder, then I don't think the version will be managed--this could be an old version of the DLL which is not compatible with your application.

[Bruce]

Since the main program is developed in VS2005, it's better to deal this problem with manifest. Refer to here

[Pino]

Eclipse was using msvcr90.dll of iCLS Client together with the one provided by Windows. Instead of removing iCLS Client from the path I just renamed its msvcr90.dll to msvcr90.dll_bak and the problem disappeared. Thank you Michael.

[chtenb]

Please refer to my other answer for what is a better solution imho. I'll leave this answer be as alternative.

[Karthick]

Hi, i used the explorer and found the dll in the list. But, it is not appearing inside the path. However, i cleared the path as you suggested and run the exe. I am still getting the same error.

[JoeFox]

For me msvcr started two times by two different python interpreters caused the issue. Using process monitor made me find it and remove the second instance from appdata

[holdenweb]

This answer might have been more useful with a link to the referenced information.

[DaCruzR]

I'm a python newbie and not really familiar with the syntax. If you don't mind can you please explain to me the stuff inside the join parentheses. Do I start reading the code from the "for" or from the "if not"?

[Priya]

Thanks a ton lot.. This saved my 2 days.. I wasted one full day trying to solve this error. Finally now I am able to solve. Thanks to you and @Michael Cooper

[Priya]

Thanks a million ton. Ur solution along with @thomas iota's solution saved my day with this irritating issue. Finally its solved now :)

[Priya]

Also, I had same issue like you in two places and had to find them and restart them twice. Finally got rid of this frustrating issue. Thanks a lot @thomasiota