> It's presumably failing to read nonblocking random from CrpytGen 
> and falling back to seeding using time and pid.

Yes and no. CryptGenRandom is not failing, but it is nonetheless calling random_seed_time_pid:

    >>> r = random.Random()
    Breakpoint 0 hit
    python36_d!random_seed:
    00000000`5e7277c0 4889542410      mov     qword ptr [rsp+10h],rdx
                                        ss:00000095`053ef0e8=0000000000000000
    0:000> g
    Breakpoint 1 hit
    python36_d!random_seed_time_pid:
    00000000`5e728910 48894c2408      mov     qword ptr [rsp+8],rcx
                                        ss:00000095`053ef040=000002319b6f3b88
    0:000> kc 3
    Call Site
    python36_d!random_seed_time_pid
    python36_d!random_seed
    python36_d!random_new

It looks like there's a bug in the new implementation of random_seed():

     if (arg == NULL || arg == Py_None) {
        if (random_seed_urandom(self) >= 0) {
            PyErr_Clear();

            /* Reading system entropy failed, fall back on the worst entropy:
               use the current time and process identifier. */
            random_seed_time_pid(self);
        }
        Py_RETURN_NONE;
    }

If random_seed_urandom fails, it returns -1, so this should be testing if the result is less than 0.