none
February and March rollups break Windows Installer junction RRS feed

  • Question

  • On Windows 7 computers that use a C:\Windows\Installer directory junction the MSI installation is broken due to update KB4490511. The update is meant to address database access and VMs failing to restore; and though it's not documented it also updates Windows Installer components. It is contained in both February and March 2019 monthly rollups.

    The computers use a directory junction for the C:\Windows\Installer directory so that it is not on the SSD C drive. On some of the computers the Installer directory is very large and would take up a lot of space if it were to reside on the SSD, so it was offloaded.

    Installer junction WORKS:
    January 8, 2019—KB4480970 (Monthly Rollup)
    January 17, 2019—KB4480955 (Preview of Monthly Rollup)

    Installer junction FAILS:
    February 12, 2019—KB4486563 (Monthly Rollup)
    February 19, 2019—KB4486565 (Preview of Monthly Rollup)
    March 12, 2019—KB4489878 (Monthly Rollup)

    This issue has been reproduced in a vanilla Windows 7 Enterprise x64 VM. To reproduce allow Windows Update to update to the most recent rollup and reboot (required). Move the Windows Installer files to a different directory and make a junction: 

    '
    cd /d C:\Windows
    attrib -h -s Installer
    move Installer Windows_Installer
    attrib +h +s Windows_Installer
    mklink /j Installer C:\Windows\Windows_Installer
    '
    
    Now try to install any MSI. There will be an error such as "The system cannot open the device or file specified." The installation will end with an error such as "The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2755."

    A screenshot of an error message from MSI installation: The system cannot open the device or file specified.

    According to Process Monitor two CreateFile calls return ACCESS DENIED at the time. A significant difference from the previous behavior is both of the calls now request impersonation. Even with Everyone (OI)(CI)(F) there is still a denial. Here are the calls:

    <eventlist>
    <event>
    <ProcessIndex>90</ProcessIndex>
    <Time_of_Day>2:45:56.4247458 AM</Time_of_Day>
    <Process_Name>msiexec.exe</Process_Name>
    <PID>1660</PID>
    <Operation>CreateFile</Operation>
    <Path>C:\Windows\Windows_Installer\3326e.msi</Path>
    <Result>ACCESS DENIED</Result>
    <Detail>Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: None, AllocationSize: 0, Impersonating: Win7Enterprise\Owner</Detail>
    </event>
    
    <event>
    <ProcessIndex>90</ProcessIndex>
    <Time_of_Day>2:45:56.4256611 AM</Time_of_Day>
    <Process_Name>msiexec.exe</Process_Name>
    <PID>1660</PID>
    <Operation>CreateFile</Operation>
    <Path>C:\Windows\Windows_Installer\3326e.msi</Path>
    <Result>ACCESS DENIED</Result>
    <Detail>Desired Access: Generic Write, Read Attributes, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: None, AllocationSize: 0, Impersonating: Win7Enterprise\Owner</Detail>
    </event>
    </eventlist>

    Here's a concise before and after in CSV format:

    '

    before KB4490511: "10:01:59.7733322 PM","msiexec.exe","252","CreateFile","C:\Windows\Windows_Installer\c7751.msi","REPARSE","Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Access System Security, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: None, AllocationSize: 0, OpenResult: <unknown>" "10:01:59.7734058 PM","msiexec.exe","252","CreateFile","C:\Windows\Windows_Installer\c7751.msi","SUCCESS","Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Access System Security, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: None, AllocationSize: 0, OpenResult: Overwritten"

    after KB4490511: "10:11:34.6958538 PM","msiexec.exe","2740","CreateFile","C:\Windows\Windows_Installer\8361d.msi","REPARSE","Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: None, AllocationSize: 0, Impersonating: Win7Enterprise\Owner, OpenResult: <unknown>" "10:11:34.6959311 PM","msiexec.exe","2740","CreateFile","C:\Windows\Windows_Installer\8361d.msi","ACCESS DENIED","Desired Access: Generic Write, Read Attributes, Write DAC, Write Owner, Dis, Options: Synchronous IO Non-Alert, Non-Directory File, Open No Recall, Attributes: n/a, ShareMode: None, AllocationSize: 0, Impersonating: Win7Enterprise\Owner" '

    Access System Security is no longer requested, now impersonation is attempted.

    msi files before and after:

    '
    system32 before and after KB4490511:
    
    06/27/2018  11:55 AM         3,246,592 msi.dll
    06/27/2018  11:21 AM           128,512 msiexec.exe
    
    01/01/2019  12:05 PM         3,247,104 msi.dll
    01/01/2019  11:39 AM           128,512 msiexec.exe
    
    syswow64 before and after KB4490511:
    
    06/27/2018  11:42 AM         2,366,464 msi.dll
    06/27/2018  11:16 AM            73,216 msiexec.exe
    
    01/01/2019  11:58 AM         2,368,000 msi.dll
    01/01/2019  11:39 AM            73,216 msiexec.exe
    '

    Reverting just msi.dll to the 06/27/2018 version is a workaround that restores the previous behavior and MSI installation succeeds. I do not know of a way to remove the offending KB since it is now part of the monthly rollup. Why is it no longer possible to remove individual KBs from a rollup? It took a lot of testing to figure out which KB was causing the problem and that it was even included in the rollup. I was fortunate KB4490511 was available independently of the rollup, otherwise I wouldn't have been able to identify it.

    Can an engineer working for Microsoft please address this? From what I understand there is a preview rollup next week, it would be great if a fix could be included.

    Friday, March 15, 2019 8:00 PM

All replies

  • Hi,

    Uninstalling an individual update is no longer possible. When you find out about issues after the update is already applied, you will have to uninstall the entire Monthly Rollup which again might also remove  fixes for critical vulnerabilities.

    If the next rollup doesn’t fix your issue, feel free to let us know.

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, March 21, 2019 8:13 AM
    Moderator
  • That's not feasible. I tried the preview rollup for April and it doesn't fix the issue. Can you report this as a bug to Microsoft please and ask an engineer to take a look? Thanks.

    Installer junction FAILS:
    March 19, 2019—KB4489892 (Preview of Monthly Rollup)

    Thursday, March 21, 2019 11:07 PM
  • Hi,

    I will help to feedback. And please note that after January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7. 

    Best Regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, April 1, 2019 2:16 AM
    Moderator
  • Respectfully I don't think that should be marked as the answer. An engineer should address the issue.
    Monday, April 8, 2019 6:40 AM
  • The same issue is present in the April rollup.
    • Edited by popchoc Wednesday, April 10, 2019 6:24 AM
    Wednesday, April 10, 2019 6:24 AM
  • There really isn't a way to send a bug report through the Social platform. Rarely does it happen, usually only if an actual MSFT employee of the appropriate department happens upon a thread, or there is some grave security issue.

    Especially for Windows 7, where it seems impossible to get help with to begin with. I gave up trying to get help with Win7 for a few years now when support went dark on it.

    Thursday, April 11, 2019 7:01 PM
  • That's unfortunate but thanks for letting me know.
    Thursday, April 11, 2019 7:08 PM
  • Did you see if registering the msi.dll makes any difference?
    Friday, April 12, 2019 8:05 PM
  • Given what I saw in Process Explorer I doubt it. As a workaround we're manually restoring the older MSI.DLLs in system32 and syswow64 after every update.
    Friday, April 12, 2019 8:18 PM
  • I have the same problem on Windows 10 x64.
    How to manually restore older MSI.DLL? I've tried all methods and failed (taking ownership, safe mode, MoveFile etc).
    Wednesday, April 17, 2019 8:07 AM
  • You can only replace the DLL when no process is using it. You may need to use process explorer CTRL+F to find out what has an open handle to msi.dll such as explorer.exe and kill those processes. Once that is done you can overwrite the DLLs with the older versions from an administrator command prompt. Here is how I do it in a batch file:

    echo. ^
      && takeown /F c:\windows\system32\msi.dll /A  ^
      && takeown /F c:\windows\syswow64\msi.dll /A  ^
      && echo. ^
      && icacls c:\windows\system32\msi.dll /grant Administrators:F /L /Q  ^
      && icacls c:\windows\syswow64\msi.dll /grant Administrators:F /L /Q  ^
      && echo. ^
      && copy /y system32\msi.dll c:\windows\system32\msi.dll  ^
      && icacls c:\windows\system32\msi.dll /reset  ^
      && echo. ^
      && copy /y syswow64\msi.dll c:\windows\syswow64\msi.dll  ^
      && icacls c:\windows\syswow64\msi.dll /reset
    if %ERRORLEVEL% NEQ 0 goto fatal


    Here is a link to MSI.DLLs from Windows 7 (2018-06-27) and Windows 10 (2018-04-11) that I have stored on my OneDrive.

    I have also reported it to Microsoft as a Windows 10 bug via the feedback center. Recent updates break Windows Installer junction. It's a shame I can't do the same with Windows 7. To view the bug report you have to be using Windows 10 since now they limit viewing them to Windows 10 users which doesn't make sense to me but whatever.

    • Edited by popchoc Wednesday, April 17, 2019 7:25 PM punctuation
    Wednesday, April 17, 2019 7:23 PM
  • "Your account has no access to this opinion" - I have privacy settings that MS doesn't like.

    I've tried to run that script but had only "The process cannot access the file because it is being used by another process."

    That's not true. Process Explorer doesn't show this dll in the list (I killed all processes that were using msi.dll). Of course I'm running this from cmd with admin rights etc.

    I'm not able to replace msi.dll on my machine. Obviously I'm not an owner of "my" computer - now MS is an owner and decides what I can do and what not :((  Spoiled my system and blocks me from repairing it. Thank you MS.

    Monday, April 22, 2019 12:58 PM
  • This is still an issue in the latest Windows 10, version 1903 (OS Build 18362.388). I did not test Windows 7.
    Wednesday, October 9, 2019 5:40 AM