> For 2.7, Windows won't be able to find msvcr90.dll without an activation context, but that's just an ERROR_MOD_NOT_FOUND OS error.

Actually, it finds the DLL fine and the DLL terminates the entire process when it fails to detect an activation context. There's #24429 on this, which I forgot to link to (note that this bug is related to that one, but is much smaller in scope).

> For 3.4, it shouldn't be using SxS for msvcr100.dll, so the server in question must have an unusual configuration. Still, the OSError that gets raised should be ignored. 

Unfortunately I can't get hold of the error. It's almost certainly a strange configuration, but it was a commodity, publicly available server where the configuration is completely outside of the user's control. If we can avoid crashing when importing stdlib modules regardless of configuration, we should.

> 3.5 built with VC 14 has a separate issue related to this. Due to changes from issue 23606, find_msvcrt now returns None. But the TypeError raised by CDLL(None) should be ignored here all the same. 

And it will be ignored, but when we know it's going to raise, why bother trying to load the library?

> BTW, in Windows 10 I'm still able to reference CRT functions by name using CDLL('ucrtbase'). Are you sure the ultimate plan is to remove the named exports?

It looks like on Windows 10 the CRT has switched to the transparent API schema. My python35.dll does not directly reference ucrtbase, and so it's still intended to be non-public API, and I still want to discourage its use because the chance of applications on different Windows versions is too high.