Duane Ellis <duane <at> duaneellis.com> writes: > > > The problem has only been seen with the git > > that ships with 64-bit cygwin. > > Use “ldd” - against the executable, determine the exact file (absolute path) of every dll that is used/required. > > Including any missing DLLs. > > You might also need to walk through your “Python Library” (where all of the python loadable modules are stored) > Remember: LDD will only tell you the DLLs that are used, it will not tell you about the modules that are loaded. > > Use a “DLL Explorer” program to determine exactly what type of DLL (32bit or 64bit) of each DLL. > Examples: Dependancy Walker, ‘DumpBin” - there are a number of tools that help > > Painful process I have ran into this many times with other things. > > have also run into problems with Python DLLs built with different versions of Visual Studio. > (The C runtime library is different) > > In the end, I have had to put a shell wrapper around Python - so that it would *change/reset” various Python > ENV variables. > > With multiple versions of python (32,64, 2.7, 3.0, windows, cygwin, local-build) nothing is consistent. > > Again painful. > >
Thanks, Duane. You are definitely correct that locating all the loaded modules would take awhile. The python binary only statically loads 4 Windows DLL's. Though, this didn't seem to be the rabbit hole I should go down. The MD5 sum is the same for the python.exe binaries whether they executed or not. I did an experiment. I copied the binary to another directory and executed there. It worked! So, it was something about where the binary was rather than what it was. It turned out that the directory permissions were not correct: # On the repo that works. $ icacls windows windows USWIN\V605040:(I)(F) CREATOR OWNER:(I)(OI)(CI)(IO)(F) USWIN\Domain Users:(I)(RX) CREATOR GROUP:(I)(OI)(CI)(IO)(RX) Everyone:(I)(OI)(CI)(RX) # On the repo that does not work. $ icacls windows windows USWIN\V605040:(F) USWIN\Domain Users:(RX) Everyone:(RX) CREATOR OWNER:(OI)(CI)(IO)(F) CREATOR GROUP:(OI)(CI)(IO)(RX) Everyone:(OI)(CI)(IO)(RX) The directory did not inherit permissions from its parent. Using explorer I went to the advanced security settings and checked the "Replace all child object permissions with the inheritable permissions from this object." Voila! The failing binary started working. Not sure that this is a cygwin/git bug. I would think this behavior would be more widely reported if it was a bug. It is more likely that the problem was caused by either a security policy or the "IT approved" version of cygwin had been modified. Company issued laptops are heavily managed by IT department where I work. (And, dog slow because of all the installed nannies.)