View Single Post
Old 3rd May 2012, 21:41   #1
Junior Member
Join Date: May 2012
Posts: 6
Does "ExecWait" inherit admin ExecutionLevel on Win7? (DX redist installer failing)

Our product uses DirectX11, so as part of our NSIS installer, we want to install the DirectX runtime components on the target machine. Our NSIS installer uses "RequestExecutionLevel admin". We copy all of the DirectX redist files (.cab, .dll, .exe) into a temporary directory on the target machine, and then call
ExecWait '"${DIRECTX_TEMP_PATH}\DXSetup.exe"'

This approach has worked without problem for years, on Win7, Vista, and XP. But we recently upgraded to the June 2010 version of the DirectX redist files, and now the DX installer is failing with an internal error on some Win7 x64 boxes. The DX error log shows a few weird failures that could be explained by insufficient permission levels.
Also, on one of the "broken" systems we had the user launch the same DX redist installer manually by double-clicking DXSetup.exe directly, and it succeeded.
So there seems to be a difference between launching the DX installer directly vs. launching it from within an NSIS installer.

So that's my question - when I launch a process using ExecWait, does that process inherit the administrator privileges of the NSIS process?
If not, how can I give the DirectX installer process admin access?
If yes, then can anyone suggest an explanation for why this 3rd-party installer might fail when launched out of NSIS, but succeed when launched manually? Is there anything that I might do differently to avoid these failures?

Thanks in advance!
chief-pinhead is offline   Reply With Quote