View Single Post
Old 5th May 2012, 01:56   #6
chief-pinhead
Junior Member
 
Join Date: May 2012
Posts: 6
Anders: yes, the user's login is "I7", so "C:\Users\I7\AppData\Local\Temp" is the correct temp folder. In fact, that account is the system administrator account.
But I just found some additional error messages from a more recent failed installation attempt. It turns out the most recent DirectX redistributable stores its log files under C:\Windows\logs, which is a new location. We did not see those files at first. So the most recent DXError.log file contains two sets of error messages like these:

--------------------
[04/25/12 10:47:48] module: dxupdate(Mar 30 2011), file: dxupdate.cpp, line: 5738, function: DirectXUpdateInstallPlugIn

Failed API: SetupIterateCabinet()
Error: (1224) - The requested operation cannot be performed on a file with a user-mapped section open.

Unable to iterate through C:\Users\I7\AppData\Local\Temp\DIRECT~1\Nov2007_d3dx10_36_x64.cab. The file may be damaged.

--------------------
[04/25/12 10:47:48] module: dsetup32(Mar 30 2011), file: dxupdate.cpp, line: 280, function: CSetup::InstallPlugIn

DirectXUpdateInstallPlugIn() failed.

--------------------
[04/25/12 10:47:48] module: dsetup32(Mar 30 2011), file: setup.cpp, line: 1727, function: CSetup::SetupForDirectX

InstallPlugIn() failed.


I looked up that error 1224, and it seems to be saying that another process had a file handle open on the cab file that the installer was trying to extract. (I know for sure that the cab file itself was not corrupt - I did a binary comparison of the cab files in the temp folder with our installer source directory, and all files were copied cleanly.) I wonder who could be holding the open file handle(s).
My NSIS script executes these commands:

SetOutPath "${DIRECTX_INSTALL_PATH}"
File '${LocalResDir}\DirectX\*'
ExecWait '"${DIRECTX_INSTALL_PATH}\DXSetup.exe"' $3

Is there any chance that the "File" command is still hanging on to any file handles after the ExecWait begins execution? Could/should I do something to confirm that the files are actually ready for consumption?

I still think it must be somehow related to NSIS, because the other system that exhibited this failure had the same DX error messages, but on that system re-running the DX installer manually outside of NSIS succeeded. So in NSIS it failed, outside of NSIS it worked.

If anyone sees anything wrong with our approach, or has any suggestions for better practices, I am all ears.
Right now I have an installer that failed on 1/3 of all machines tested. And our only recourse is to detect the DX failure, tuck our tails, and ask the user to please double-click the DX installer manually. I don't like that option one bit.
chief-pinhead is offline   Reply With Quote