File "random.pyc", line 828, in ?
   File "random.pyc", line 95, in __init__
   File "random.pyc", line 109, in seed
 WindowsError: [Errno -2146893795] Provider DLL failed 
to initialize correctly

Logged In: YES 
user_id=1188172

Could you provide some more information? OS specs, Python
version, reproducability etc.

Logged In: YES 
user_id=731668

Windows XP, python 2.4.2
Not sure how to reproduce it.

Logged In: YES 
user_id=731668

This time from Windows 98 SE:

  File "random.pyc", line 828, in ?
  File "random.pyc", line 95, in __init__
  File "random.pyc", line 109, in seed
WindowsError: [Errno -2146893818] Windows Error 0x80090006

Logged In: YES 
user_id=21627

The errors are actually different. The first one is

0x8009001d: NTE_PROVIDER_DLL_FAIL (Provider DLL failed to
initialize correctly) 

and the second one is

0x80090006: NTE_BAD_SIGNATURE (Invalid Signature)

For the second error, please check whether

http://support.microsoft.com/default.aspx?scid=kb;en-us;811886

applies. For the first error, I only found

http://support.microsoft.com/default.aspx?scid=kb;en-us;321459

but I doubt it's relevant.

In any case, I'm tempted to declare this a Windows bug.

Given MvL's diagnostics and lack of response from OP, suggest closing.

I got a very similar error on an Otek Pocket PC running Windows Mobile
2003 SE and the latest version of pythonce from
pythonce.sourceforge.net.  The error is:

File
"C:\devl\release\PythonCE-2.5-20061219\Python-2.5-wince\Lib\random.py",
line 108, in seed
<type 'exceptions.WindowsError'>: [Error 87] Provider DLL failed to
initialize correctly

Although this was thrown up at the "import random" at the start of my
program, the actual change I made that resulted in this error was much
later in the program, and it was to change the lines

            try: justSynthesize=raw_input("Say: ")
            except EOFError: break

into

            try:
justSynthesize=raw_input(cond(winCEsound,"".join(warnings_printed)+cond(warnings_printed,"\n",""),"")+"Say:
") # (WinCE uses an input box so need to repeat the warnings if any)
            except EOFError: break

where "cond" is an "if a then b else c" function.

A little more investigation showed that the culprit was the comment! 
Removing the comment after the raw_input() call (or putting it on a
different line) causes the program to work again.

I confirmed that adding any raw_input() call to any function, with a
prompt parameter and a comment afterwards, causes this error to happen
on the "import random" near the top of the program.  This is a very
strange bug.

After further investigation I'm suspecting that this issue is actually
due to the process running out of RAM.

Note that there are still people who get this error in some strange cases, me included.

E.g.:
http://stackoverflow.com/questions/27904936/python-exe-file-crashes-while-launching-on-windows-xp/32137554#32137554

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'})

There is another related question [here](http://stackoverflow.com/questions/21791005/windows-error-provider-dll-failed-to-initialize-correctly-on-import-of-cgi-mo).
And some discussion on [this GitHub issue](https://github.com/aws/aws-cli/issues/1226).
All those seem to be related to `crypt32.dll` in a frozen Python app, or via py2app.

Albert, this issue was opened for Python 2.4 and was closed over 6 years ago. Open a new issue if you believe there's a bug or room for improvement in a currently supported Python version. 

FYI, on Windows _PyOS_URandom first initializes the Crypto API by calling [CryptAcquireContext][1]. As shown in the debug session below, this function requires the SystemRoot environment variable to be correctly defined. 

    C:\>cdb -g "C:\Program Files\Python27\python.exe"

    Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
    Copyright (c) Microsoft Corporation. All rights reserved.

    ...

    >>> import os
    >>> from ctypes import *
    ...
    >>> PROV_RSA_FULL = 1
    >>> CRYPT_VERIFYCONTEXT = 0xf0000000
    >>> CryptAcquireContextA = WinDLL('advapi32').CryptAcquireContextA 
    >>> hcrypt = c_void_p()

    >>> del os.environ['SystemRoot']
    >>> CryptAcquireContextA(byref(hcrypt), None, None, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)
    ModLoad: 000007fe`fc480000 000007fe`fc498000   C:\Windows\system32\CRYPTSP.dll
    CryptAcquireContext:  CheckSignatureInFile failed at cryptapi.c line 5198
    CryptAcquireContext:  Failed to read registry signature value at cryptapi.c line 873
    0

    >>> os.environ['SystemRoot'] = 'C:\\Windows'
    >>> CryptAcquireContextA(byref(hcrypt), None, None, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)
    ModLoad: 000007fe`fc180000 000007fe`fc1c7000   C:\Windows\system32\rsaenh.dll
    ModLoad: 000007fe`fcae0000 000007fe`fcaef000   C:\Windows\system32\CRYPTBASE.dll
    1
    >>> hcrypt
    c_void_p(4407952L)

It has always struck me as odd that this API uses the environment variable instead of the object manager's secured \SystemRoot object symbolic link. C'est la vie. 

Anyway, I don't think Python's os and subprocess modules should prevent you from shooting yourself in the foot here. When creating an environment block for a child process, excluding SystemRoot is generally a bad idea, but the language shouldn't get in the way. 

I think it's prudent to include at least all of the system-defined variables. Here's a function that calls [CreateEnvironmentBlock][2] and returns the system variables in a dict. It excludes user variables and doesn't inherit from the current process.

    import ctypes

    userenv = ctypes.WinDLL('userenv', use_last_error=True)

    def errcheck_bool(result, func, args):
        if not result:
            raise ctypes.WinError(ctypes.get_last_error())
        return args

    userenv.CreateEnvironmentBlock.argtypes = (ctypes.POINTER(ctypes.c_void_p),
                                               ctypes.c_void_p,
                                               ctypes.c_int)
    userenv.DestroyEnvironmentBlock.argtypes = (ctypes.c_void_p,)

    def get_system_environ():
        WCHAR_SIZE = ctypes.sizeof(ctypes.c_wchar)
        environ = {}
        cenv = ctypes.c_void_p()
        userenv.CreateEnvironmentBlock(ctypes.byref(cenv), None, 0)
        addr = cenv.value    
        try:
            while True:
                s = ctypes.c_wchar_p(addr).value
                if not s:
                    break
                i = s.find('=', 1)
                if i != -1:
                    environ[s[:i]] = s[i+1:]
                addr += (len(s) + 1) * WCHAR_SIZE
        finally:
            userenv.DestroyEnvironmentBlock(cenv)
        return environ

[1]: https://msdn.microsoft.com/en-us/library/aa379886
[2]: https://msdn.microsoft.com/en-us/library/bb762270

I forgot to set errcheck:

    import ctypes

    userenv = ctypes.WinDLL('userenv', use_last_error=True)

    def errcheck_bool(result, func, args):
        if not result:
            raise ctypes.WinError(ctypes.get_last_error())
        return args

    userenv.CreateEnvironmentBlock.argtypes = (ctypes.POINTER(ctypes.c_void_p),
                                               ctypes.c_void_p,
                                               ctypes.c_int)
    userenv.DestroyEnvironmentBlock.argtypes = (ctypes.c_void_p,)

    userenv.CreateEnvironmentBlock.errcheck = errcheck_bool
    userenv.DestroyEnvironmentBlock.errcheck = errcheck_bool

    # ...

Ah thanks, that explains why it failed for me, and why it works after my fix, which was anyway what I intended.

I mostly posted my comment here in case someone else hits this, so he has another thing to check/debug.

I don't think that there is a bug on Python's side. Maybe a nice thing would be a small check in _PyOS_URandom for os.environ['SystemRoot'] and print a more helpful error.