I used Detours with trclnk64 to get the following log:

```
20201218193836960 4332 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4ccebef0
20201218193836960 4332 50.60: trclnk64: 001   GetProcAddress(7ffc4ccd0000,LCMapStringEx)
20201218193836960 4332 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4cce6640
======== <= This is the point where it differs from a clean run.
20201218193838163 4332 50.60: trclnk64: 001   GetProcAddress(7ffc4c710000,FlsFree)
20201218193838163 4332 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4c78b000
20201218193838163 4332 50.60: trclnk64: 001   FAIL LoadLibraryExW(c:\users\nelson85\documents\devel\open\jpype\_jpype.cp39-win_amd64.pyd,0,1100)
20201218193838164 4332 50.60: trclnk64: 001 LoadLibraryExW(,,) -> 0
```

It really is nothing to go on...  Everything succeeds, then we get an extra successful request for FlsFree then it immediately returns with a fail.

In the successful run (without the cache) we get...
```
20201218192451068 20440 50.60: trclnk64: 001   GetProcAddress(7ffc4ccd0000,LCMapStringEx)
20201218192451068 20440 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4cce6640
20201218192451068 20440 50.60: trclnk64: 001 LoadLibraryExW(,,) -> 7ffc349f0000
20201218192451068 20440 50.60: trclnk64: ### 349f0000: c:\users\nelson85\documents\devel\open\jpype\_jpype.cp39-win_amd64.pyd 00000000
20201218192451068 20440 50.60: trclnk64: MSVCP140.dll [7ffc34a7af48 7ffc34a5a0c8]
20201218192451068 20440 50.60: trclnk64:   ?_Lock@?$basic_streambuf@DU?$char_traits@D@std@@@std@@UEAAXXZ    0 7ffc36f22350
20201218192451068 20440 50.60: trclnk64:   ?_Unlock@?$basic_streambuf@DU?$char_traits@D@std@@@std@@UEAAXXZ    0 7ffc36f22350
```

So the failure appears to be internal to the call before we load MSVCP140.dll.   Unfortunately, I am way outside my element here as a Linux/Java/CPython programmer.   My next guess would be to instrument the set system error and if we are within LoadLibrary then execute "int *i=0; *i=0;"  and hope the debugger would get me the point of failure so that I can examine the stack trace to find out where we are.  But if you have another direction I would be happy to hear it.   Is there some function I should add to trclnk64 to that may have gone wrong?  It must be something that fetched the address of LCMapStringEx, but I have no clue what that may be.

This really does not look like a JPype bug.  Yes, two minutes in the future from where the car ran over the pedestrian, he was going to run into the bank and demand money (monkey patch and other bad things).  But at the point in time the car hit, the pedestrian was just minding his own business.