Hi folks. Thanks for the ideas.
Anders: I am extracting every file that comes in the June 2010 DirectX redist package - one exe, two dlls, and 155 .cab files. Please look back at my NSIS script snippet for details. After all files are copied onto the target machine, I invoke the just-copied "DXSetup.exe" using ExecWait. That exe does a bunch of logic to decide what cab files need extracting, and then tries to extract them. Somewhere along the way it fails, apparently because some other process is holding an exclusive handle to the cab files, or to some other file-read-related shared resource.
As for the folder to which the DX files are extracted - I used to just "hard-code" the path:
But once these problems started happening, I was worried that the files being extracted were perhaps corrupt somehow, so I started using a non-temporary path whose contents I could later inspect. So I now define
!define DIRECTX_INSTALL_PATH "$INSTDIR\Install Media\DirectX Redist"
And I have verified that all 158 files are extracted correctly.
redxii - Microsoft is pretty clear in their documentation that you should run the redist installer hands-off, rather than trying to handle any of the logic or dll's manually. I don't believe manually adding the directX dlls is an option, even if it would allow our exe's to run.
It feels to me like AV is the most likely culprit.
I will run a test with a long sleep before the execWait.
And if we do get the failure, we'll use sysInternals to see who's holding the file handle. But I suspect that would come up empty - I bet the file handles are only held temporarily. Otherwise it would fail on the first cab file every time...
demiller9's idea is sort of pragmatic - just re-run if the ExecWait call returns failure. Unfortunately, the DX installer pops up a very nasty looking failure dialog of its own before returning, so I really can't wait that long. We need to prevent this problem, not react to it.
Thanks for everyone's ideas. Keep them coming!