locked
MSI BUG in Windows 10?: PATH env var not updated by MSI after s/w install finishes until user log out/in (or reboot). RRS feed

  • General discussion

  • I'm seeing different behavior when installing a software package under Windows 10 versus under previous versions of Windows.  The software package is installed via a Windows Installer (MSI) package that is invoked by a setup.exe bootstrapper application (which requires elevated privileges to run).  The MSI package updates the %PATH% environment variable during installation (using the MSI Environment Table).  The MSI package ONLY runs in the per-machine context so the environment variables for all users should be updated by the installation.  However, that is not the case on Windows 10 (until after the user logs out and back in or reboots the system).

    MSI Behavior on Windows 8.1 or earlier:
    After the MSI installation completes, the %PATH% environment variable is properly updated for all users.  This is evidenced by opening a non-elevated command window and running "echo %PATH%" to display the value of the %PATH% environment variable.  Running the command in BOTH a non-elevated command window and in an elevated command window (context under which the MSI ran) shows the same results: in both cases the %PATH% environment variable was properly modified by the MSI installation.

    MSI Behavior on Windows 10 (build 10240):
    After the MSI installation completes, the %PATH% environment variable is only updated for the user who ran the installation (the elevated user credentials used to run setup.exe).  If I open a non-elevated command window and examine the %PATH% environment variable it was NOT updated.  However, if I then log out and log back in (or just reboot), then the %PATH% environment variable is properly set for all users (as seen in both a non-elevated command window and in an elevated command window).

    Is this a bug with MSI on Windows 10?
    • Changed type Karen Hu Thursday, September 10, 2015 2:10 AM
    Thursday, August 13, 2015 6:42 PM

All replies

  • Hi Colby,

    Based on my test, yes, it's indeed like what you found. However, I don't think this is a bug. It's a changes by design.

    Before sign out

    After sign out:

    If you feel like uncomfortable, please submit this feedback via the built-in Feedback App. Please be assured that any improvements in the product are based on users' requirements. Our developers strive to capture Microsoft users' ideas and are working hard to create a more powerful and easy-to-use product.


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


    • Edited by Karen Hu Friday, August 14, 2015 3:02 AM
    Friday, August 14, 2015 2:58 AM
  • For what reason could this possibly be a "design" change?

    I'm in the process of determining how to submit this as a bug via out enterprise product support as this is going to negatively impact all of our customers when then install our software.
    Friday, August 14, 2015 9:42 PM
  • LOL  I installed "The Feedback App" but when I run it it tells me "Login Required" but then doesn't tell me where I need to "log in" or give my any way to enter login credentials.  WTH?
    Friday, August 14, 2015 9:59 PM
  • It would be interesting to know if you find out where this "log in" area is because it shows that I am logged in and I can assure them, I never have been. Something is really messed up!!
    Friday, August 14, 2015 10:16 PM
  • It actually means you can't use programs from the command line right after installation. This is annoying. I up-voted in the feedback app.
    Sunday, August 16, 2015 6:07 AM
  • I guess you need a Microsoft Account? That worked for me. You can then login: Settings > Accounts > Your account.
    Sunday, August 16, 2015 6:10 AM
  • Re-posting this question using my MSDN account as that is supposed to get me a response from Microsoft within two days...original post is here.

    I'm seeing different behavior when installing a software package under Windows 10 versus under previous versions of Windows.  The software package is installed via a Windows Installer (MSI) package that is invoked by a setup.exe bootstrapper application (which requires elevated privileges to run).  The MSI package updates the %PATH% environment variable during installation (using the MSI Environment Table).  The MSI package ONLY runs in the per-machine context so the environment variables for all users should be updated by the installation.  However, that is not the case on Windows 10 (until after the user logs out and back in or reboots the system).

    MSI Behavior on Windows 8.1 or earlier:
    After the MSI installation completes, the %PATH% environment variable is properly updated for all users.  This is evidenced by opening a non-elevated command window and running "echo %PATH%" to display the value of the %PATH% environment variable.  Running the command in BOTH a non-elevated command window and in an elevated command window (context under which the MSI ran) shows the same results: in both cases the %PATH% environment variable was properly modified by the MSI installation.

    MSI Behavior on Windows 10 (build 10240):
    After the MSI installation completes, the %PATH% environment variable is only updated for the user who ran the installation (the elevated user credentials used to run setup.exe).  If I open a non-elevated command window and examine the %PATH% environment variable it was NOT updated.  However, if I then log out and log back in (or just reboot), then the %PATH% environment variable is properly set for all users (as seen in both a non-elevated command window and in an elevated command window).

    Is this a bug with MSI on Windows 10?
    • Merged by Michael_LS Tuesday, August 18, 2015 9:24 AM same post
    Monday, August 17, 2015 4:26 PM
  • I re-posted this question using my MSDN credentials as that is supposed to get a response from Microsoft within two days.  The new post is here.
    Monday, August 17, 2015 4:34 PM
  • Collby,

    I merged your post into one thread.

    As explained, this seems to be the re-design issue, the feedback app need to sign in means it needs your registered Microsoft Account.

    Regards


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

    Tuesday, August 18, 2015 9:36 AM
  • Whether or not it's a re-design issue is beside the point.  It's a problem that's going to affect every MSI installation in existence that is installed per-machine and uses the MSI Environment Table to modify the %PATH% environment variable.  It means users won't be able to run installed applications from the command line unless they log out and back in (or reboot).  So if this was a planned "re-design" it was a poorly thought through decision.

    Regardless, I've opened Service Request incident number 115081713049192 with Microsoft Enterprise Tech Support and am working with a support engineer to determine what software application distributors can do about it.
    Tuesday, August 18, 2015 4:33 PM
  • Colby,

    Thanks for the update.

    I understand the situation and apologize for not being able to offer any helpful suggestions.

    Hope there would be solution available to share here from the support side, as it could help the others who encountered the same issue.

    Regards


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

    Wednesday, August 19, 2015 5:14 AM
  • The support engineer handling my open Service Request incident (115081713049192) agreed this behavior in Windows 10 is unexpected and submitted it as a bug to the development team on 8-19-15.  I'm waiting for development to respond.
    Friday, August 21, 2015 3:14 PM
  • Still waiting...here's the latest from the support tech:

    "As per my discussion with my TL, as of now this seems to be by design.  But still the debug team is looking into this, I will inform you further once I have any update on this."

    Thursday, September 10, 2015 4:02 PM
  • Finally, after 7 months of being told by support that they could reproduce this issue a support engineer has been assigned to it.  Below is the latest information I have from him.  Despite the mention of a workaround in the message, no such workaround has been provided yet (there was nothing on the referenced website workspace he set up for me).

    ===============

    Please find the details and analysis of the problem that we have been debugging as below.

    Windows installer in session 0 has an option to update system environment variable, after which it sends WM_SETTINGCHANGE via winsta to all sessions. 

    This is received in all sessions and BroadcastSystemMessage is used to broadcast this.

    It looks like the Window associated with “SHELL32!CDesktopBrowser::s_DesktopWndProc”, hosted by explorer.exe never receives this message, as a result it never its PEB with updated environment variables.

    As explorer never has updated environment variables, any new process started from this explorer process, by double clicking , run box, etc all inherit the old environment variables. It seems like this broadcast is only recieved by a few windows

    The one interesting thing that I see is in BroadcastSystemMessage BSF_NOHANG is set

    from msdn:

    Forces a nonresponsive application to time out. If one of the recipient’s times out, do not continue broadcasting the message.

    Here's the problem, Window associated with "SHELL32!CDesktopBrowser::s_DesktopWndProc", which does the work of updating environment variables in explorer is the last one in the desktop on the session.In win10 we have searchUI.exe(Cortana) and ShellExperienceHost.exe(ModernApp infrastructure and start menu), These processes like ModernApp processes go into suspended state when not in use.We cannot kill these while explorer is running. However, with explorer not running, how do I make sure that WM_SETTINGCHANGE is recieved by windows in the session? For this I wrote a testapp.

    Killing 1. explorer, 2. ShellExperienceHost.exe 3. searchUI.exe, with my testApp running I was able to confirm that it receives WM_SETTINGCHANGE.

    Workaround

    ===========================================================

    One feasible workaround would be, not to depend on shell's (explorer.exe) functionality. We could write an executable that calls CreateEnvironmentBlock.  This creates an environment block, with the information that has been updated by windows installer. The environmentblock returned by this function

     is passed to CreateProcess call to create a new process, which will now have the updated environment block. 

     Plan

    =====================================================

    As explained above, what we are seeing here is not really a code change in explorer process or the windows installer. This is more to do with the introduction of ModernAppsand the fact that in win10, startmenu happens to be a ModernAPP and these tend to stay in suspended state when not in use.

     This is strict terms can be termed as a regression, however getting this feature AND the new features in win10 to work does not seem to be trivial change. If required, I can go ahead with filing a bug and requesting a fix. Any chance of this being considered will be in future OS(es) RS1 /later.

     I am attaching a BIS.txt, please reply back with answers to the questions in the BIS, should you decide in going ahead with filing a bug in this regard

     Also with regard to the workaround, I have uploaded a sample with sample code. Given below is the usage:

    1. while testing with cmd window open, and verifying that it is still reporting the old system environment variables.

    2. in the same cmd, run the following command:

      envarcreateproc cmd.exe

      <wait for the new prompt to come in the same window. You can verify that its launch a new cmd.exe from task manager>

      in this prompt type "set Path"

      Observe that the updated path is displayed.

      type exit to get back to the old cmd prompt

      type "set path" to observe that the old path variable is still being displayed

    Debug info

    ===========================================================

    ---

      s 1  et 0xffffe00124fa1080 t 0xfffff9014223fb20 q 0xfffff9014064a460 ppi 0xfffff901423cb420 i 18e4.1a4c explorer.exe

    pwnd    = 0xfffff901408305e0

    title   = "<null>"

    wndproc = 0x00007ff950bcb530 = "TwinUI!CEdgeUiInput::s_WndProc" (Unicode) ZBID: 7, Class(V): 0xc0f8, (NV): 0xc0f8 Name:"EdgeUiInputWndClass"

    ---

      s 1  et 0xffffe00123a5e840 t 0xfffff901407e93e0 q 0xfffff90143d26e50 ppi 0xfffff90143c73c20 i 1a98.1360 SearchUI.exe-----------------------> modern APP process in suspended state

    pwnd    = 0xfffff901408321f0

    title   = "Default IME"

    wndproc = 0x00007ff973f84f20 = "ntdll!NtdllImeWndProc_W" (Unicode) ZBID: 13, Class(V): 0xc026, (NV): 0xc026 Name:"IME"

    ---

      s 1  et 0xffffe00123a5e840 t 0xfffff901407e93e0 q 0xfffff90143d26e50 ppi 0xfffff90143c73c20 i 1a98.1360 SearchUI.exe

    pwnd    = 0xfffff90140831fe0

    title   = "Cortana"

    wndproc = 0x00007ff94e3974c0 = "" (Unicode) ZBID: 13, Class(V): 0xc090, (NV): 0xc090 Name:"Windows.UI.Core.CoreWindow"

    ---

      s 1  et 0xffffe00124555240 t 0xfffff90143d2c310 q 0xfffff901406eb470 ppi 0xfffff90143d53010 i 1890.1068 ShellExperienc---------------------->modern app process in suspended state

    pwnd    = 0xfffff90140830a70

    title   = "Default IME"

    wndproc = 0x00007ff973f84f20 = "ntdll!NtdllImeWndProc_W" (Unicode) ZBID: 6, Class(V): 0xc026, (NV): 0xc026 Name:"IME"

    ---

    |

    <snip>

    |

    ---

    s 1  et 0xffffe00124c01840 t 0xfffff90143ee57b0 q 0xfffff90143c2e010 ppi 0xfffff901423cb420 i 18e4.19a8 explorer.exe

    pwnd    = 0xfffff9014082f9b0

    title   = "Program Manager"

    wndproc = 0x00007ff9729c4c60 = "SHELL32!CDesktopBrowser::s_DesktopWndProc" (Unicode) ZBID: 1, Class(V): 0xc145, (NV): 0xc145 Name:"Progman"

    ---

    kd> !process 0 0 searchui.exe

    PROCESS ffffe0012697a840

        SessionId: 1  Cid: 174c    Peb: 78f7a17000  ParentCid: 02ac

    DeepFreeze

        DirBase: aaf09000  ObjectTable: ffffc001e9f256c0  HandleCount: 869.

        Image: SearchUI.exe

    kd> !process 0 0 shellexperiencehost.exe

    PROCESS ffffe00121ecf080

        SessionId: 1  Cid: 195c    Peb: 82727f000  ParentCid: 02ac

    DeepFreeze

        DirBase: 9e484000  ObjectTable: ffffc001e7099b40  HandleCount: 701.

        Image: ShellExperienceHost.exe

    Best regards,

    Anshuman Ghosh

    Windows Serviceability – US Afterhours


    Monday, March 28, 2016 8:41 PM
  • Indeed a really annoying thing that affected me now when working on Automation that worked on Windows 7.

    Tuesday, July 12, 2016 7:35 PM
  • I forgot to update this post with the latest.  Microsoft has acknowledged this is a bug and has created KB article https://support.microsoft.com/en-us/kb/3166232 to describe the problem.
    • Edited by Colby Ringeisen Tuesday, July 12, 2016 7:44 PM updated KB url as link
    Tuesday, July 12, 2016 7:43 PM