Error opening installation log file. Verify that the specified log file location exists and that you can write to it.
“Error opening installation log file. Verify that the specified log file location exists and that you can write to it.” error when attempting to install any Setup package. For example, try installing any one of the below packages:
The Microsoft .Net Framework patch KB2972216
The Microsoft Visual C++ 2008 Redistributable Package
The Microsoft Forefront Endpoint Protection
The sample error screenshots are displayed below:
There was a log file (dd_NDP45-KB2972216-x64_decompression_log.txt) in the user temp folder (%temp%) and I found the below information:
[3/15/2015, 10:40:28] Drive 'C:\' has been selected as the largest fixed drive
[3/15/2015, 10:40:28] Directory 'C:\2d7a2b9d5ac9fde4e25b451fb755\' has been selected for file extraction
[3/15/2015, 10:40:28] Extracting files to: C:\2d7a2b9d5ac9fde4e25b451fb755\
[3/15/2015, 10:40:31] Extraction took 3.485 seconds
[3/15/2015, 10:40:31] Executing command line: 'C:\2d7a2b9d5ac9fde4e25b451fb755\Setup.exe
The subject error message appears to be an issue with NTFS file/folder permission. Hence, I ran a tool called Process Monitor. The procmon trace shows the failure. The MSI fails to write it’s log and that is what eventually kills the install.
Setup.exe 1880 CreateFile C:\Users\MyUser\AppData\Local\Temp\MSI3a3f7.LOG ACCESS DENIED Desired Access: Generic Write, Read Attributes, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: N, ShareMode: Read, AllocationSize: 0
User Mode Stack:
18 KernelBase.dll CreateFileW + 0x35e, 0x7578c5f7 C:\Windows\SysWOW64\KernelBase.dll
19 Kernel32.dll CreateFileWImplementation + 0x69, 0x758f3f66 C:\Windows\SysWOW64\kernel32.dll
20 msi.dll CMsiPath::TempFolderOrFile + 0x52e, 0x6f4b4739 C:\Windows\SysWOW64\msi.dll
21 msi.dll CMsiPath::TempFileName + 0x2c, 0x6f4b4907 C:\Windows\SysWOW64\msi.dll
22 msi.dll MsiUIMessageContext::InitializeLog + 0x601, 0x6f327ff2 C:\Windows\SysWOW64\msi.dll
23 msi.dll MsiUIMessageContext::Initialize + 0x1da, 0x6f307d81 C:\Windows\SysWOW64\msi.dll
24 msi.dll MsiUIMessageContext::RunInstall + 0x91, 0x6f308085 C:\Windows\SysWOW64\msi.dll
25 msi.dll RunEngine + 0xe2, 0x6f308ed8 C:\Windows\SysWOW64\msi.dll
26 msi.dll MsiInstallProductW + 0xa1, 0x6f39ee2c C:\Windows\SysWOW64\msi.dll
27 SetupEngine.dll IronMan::MspInstallerT<IronMan::PatchesFilteredT <IronMan::CMsiInstallContext>>::Execute + 0x20d, 0x6f5abc76 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
28 SetupEngine.dll IronMan::BaseMspInstallerT<IronMan::MsiExternalUiHandler, IronMan::PatchesFilteredT<IronMan::CMsiInstallContext> >::PerformMsiOperation + 0x323, 0x6f5a2643 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
29 SetupEngine.dll IronMan::BaseMspInstallerT<IronMan::MsiExternalUiHand
ler,IronMan::PatchesFilteredT<IronMan::CMsiInstallContext> >::PerformAction + 0x162, 0x6f5a2015 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
30 SetupEngine.dll IronMan::CompositePerformerBaseT<IronMan::Performers <IronMan::MsiInstaller,IronMan::MspInstallerT<IronMan::Patches<IronMan::CMsiInstallContext> IronMan::RelatedProductsRepairer>,IronMan::Performers<IronMan::MsiUnInstallerT<IronMan: + 0x552, 0x6f5a3c62 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
31 SetupEngine.dll IronMan::CompositePerformer::PerformAction + 0x1fa, 0x6f596f99 C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
32 SetupEngine.dll IronMan::NotifyController::ThreadProc + 0x12, 0x6f58aacc C:\2d7a2b9d5ac9fde4e25b451fb755\SetupEngine.dll
33 kernel32.dll BaseThreadInitThunk + 0xe, 0x758f338a C:\Windows\SysWOW64\kernel32.dll
34 ntdll.dll __RtlUserThreadStart + 0x70, 0x77879f72 C:\Windows\SysWOW64\ntdll.dll
35 ntdll.dll _RtlUserThreadStart + 0x1b, 0x77879f45 C:\Windows\SysWOW64\ntdll.dll
I thought that there must be something busted with the ACL in the temp directory. So I ran Icacls.exe for the Temp folder:
C:\Users\MyUser\AppData\Local\>icacls Temp
Temp NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
MyPC\MyUser:(I)(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 files
It shows that the ACL in the temp directory is appropriate and it is a default configuration. In fact re-creating the team folder didn’t make any difference. This problem occurs with different users as well. I used custom log path(/log C:\temp\Netfx.log) but still the issue was not resolved. Then, I tried turning on auditing for the Temp folder to see which user tries to access the Temp folder and I found the below information:
Access Reasons:
READ_CONTROL: Unknown or unchecked
SYNCHRONIZE: Unknown or unchecked
WriteData (or AddFile): Denied by Integrity Policy check
AppendData (or AddSubdirectory or CreatePipeInstance): Unknown or unchecked
WriteEA: Unknown or unchecked
ReadAttributes: Unknown or unchecked
WriteAttributes: Unknown or unchecked
I checked the Integrity level in the process monitor. The below screen shot shows that the Setup.exe process is launched with low Integrity level. We know that Low integrity level processes cannot write in most of the places under user profile.
This should not be a default behavior as by default such levels are defined in the OS. It must be explicitly defined and it was inherited to the process launched from the source directory C:\2d7a2b9d5ac9fde4e25b451fb755\. Here, the package is created using sfxcab(Self-Extracting Cabinet) - that's the self-extracting technology used for many Setup installers.During runtime it creates a randomly named folder at the drive where maximum free disk space is available and it's the temp location that setup extracts it's contents i.e. C:\2d7a2b9d5ac9fde4e25b451fb755\
Next, I ran Icacls.exe for the above folder and found the below output:
C:\>icacls 2d7a2b9d5ac9fde4e25b451fb755
2d7a2b9d5ac9fde4e25b451fb755 BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
Everyone:(OI)(CI)(RX)
BUILTIN\Users:(OI)(CI)(RX)
Mandatory Label\Low Mandatory Level:(I)(OI)(CI NW)
Output for the root drive:
C:\>icacls C:
C: NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)
BUILTIN\Users:(CI)(AD)
BUILTIN\Users:(CI)(IO)(WD)
CREATOR OWNER:(OI)(CI)(IO)(F)
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
By default it should be like this:
C:\>icacls C:
C: BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Users:(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
NT AUTHORITY\Authenticated Users:(AD)
Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)
The integrity level in the security access token of a process can be viewed using tools that expose the security details of a process, such as Process Explorer The below image shows the display from Process Explorer with the Integrity Level column added to the view.
If we look at the security properties of a specific process, such as Setup.exe, Process Explorer shows the integrity level in the list of groups that are defined in the security access token of the process. The below image shows the Mandatory Label/Low Mandatory Level assigned to the access token for the process, Setup.exe
In order to resolve the issue, You can change the integrity level on the extracted folder(C:\2d7a2b9d5ac9fde4e25b451fb755) or on the root drive(C:\) from low to high. You can modify the mandatory level requirements using the icacls utility. It contains a command line switch: /setintegritylevel
For example: icacls c:\myLowIntegrityFolder /setintegritylevel high
Note that you cannot change the integrity level to high from a Low integrity level process, so if you want to change the value to high, you would need to do so from a high integrity level (elevated) command prompt.
Reference links:
https://msdn.microsoft.com/en-us/library/bb625963.aspx
https://msdn.microsoft.com/en-us/library/bb625960.aspx
P.S. Impersonation is one way that a service thread may be running at a lower integrity level. When a service thread impersonates a local client, the impersonation thread has the client’s security context, which includes the client’s integrity level if the client is running on the same local machine.
Not all application programs will run properly in a low-integrity process. A low integrity process does not have write access to most areas under the user’s local profile area of the file system or the registry under HKCU. The inability for a low-integrity process to get write access to the user profile is a good thing if the program is unwanted malicious software. But for applications like Protected Mode Internet Explorer, some redesign may be necessary to get all features of the application behaving correctly.