“Windows Error: provider DLL failed to initialize correctly” on import of cgi module in frozen wxpython app

Question

I have a user of a frozen wxpython app that gets the appended screenshot.

The error message is \"Windows Error: provider DLL failed to initialize correctly\"

Answer 1

I think the minimal solution is to include the SYSTEMROOT environment variable in the Python subprocess.

I have seen the problem when trying to load os.urandom:

self._authkey = AuthenticationString(os.urandom(32)) WindowsError: [Error -2146893795] Provider DLL failed to initialize correctly

It turns out that the _PyOS_URandom on Windows relies on the SYSTEMROOT environment to be set. See: http://bugs.python.org/issue1384175#msg248951 for a detailed explaination

Answer 2

This seems to occur somewhere inside os.urandom and is probably caused by some missing or incorrect environment variables. In particular it happens if the environment is too long.

• If you are starting Python from a shell, open a new shell and try again. If the problem persists, check if there are unusually many environment variables
• If you are starting Python from another process, check if the proces environment is set up correctly. I found that this is often not the case for processes run by Apache's CGI module.

if you are starting Python as a CGI process, then you may want to consider better alternatives, such as mod_wsgi.

Answer 3

For me, the exact error message was:

WindowsError: [Error -2146893795] Provider DLL failed to initialize correctly

with a trace such as:

  File "C:\Dev\Python\python-2.7.11\lib\tempfile.py", line 35, in <module>
    from random import Random as _Random
  File "C:\Dev\Python\python-2.7.11\lib\random.py", line 885, in <module>
    _inst = Random()
  File "C:\Dev\Python\python-2.7.11\lib\random.py", line 97, in __init__
    self.seed(x)
  File "C:\Dev\Python\python-2.7.11\lib\random.py", line 113, in seed
    a = long(_hexlify(_urandom(2500)), 16)
WindowsError: [Error -2146893795] Provider DLL failed to initialize correctly

And what solved it for me was a comment from http://bugs.python.org/issue1384175 (http://bugs.python.org/msg248947), saying the following:

This happened at a call to `os.urandom` for me.
This was in a subprocess.

The bug for me was that I called `_subprocess.CreateProcess` 
with an `env_mapper = {'foo': 'bar'}`. The fix:

    env_mapper = os.environ.copy()
    env_mapper.update({'foo': 'bar'})