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:

AError_KB2972216

 

BError2_KB2972216

 

Cvcredist_2008

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.

Procmon

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.

Process_Exp

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

Process_Exp1

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.

 

 


Comments (1)

  1. Michael Schachinger says:

    Hello Soumitra,
    many thanks for your perfect analysis. After trying to find the problem literally for months, your solution in this article has solved my problems. I've had exactly the issues you are describing. I've found this nowhere else!
    Mostly the error messages pointed me to the windows installer service which is misleading.
    Best Regards
    Michael

Skip to main content