locked
Registry's EnumKey Lookup Failing When Called By MSBuild? RRS feed

  • Question

  • A MS-DOS script executes the VBScript below and it works fine. However, when using a MS Build master deployment file which calls the aforementioned MS-DOS script, the 2nd location lookup ("SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\") fails with a result code of 2. I have spent countless hours trying to figure out why the difference. Any ideas?

    Const HKLM = &H80000002 'HKEY_LOCAL_MACHINE
    Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & node & "/root/default:StdRegProv")

    REM 1st location: "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\"
    sBaseKey = "SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\"
    iRC = oRegistry.EnumKey(HKLM, sBaseKey, arSubKeys)
    If iRC <> 0 THEN
    WScript.Echo "Registry lookup failed for " & sBaseKey
    ELSE
    For Each sKey In arSubKeys
    iRC = oRegistry.GetStringValue(HKLM, sBaseKey & sKey, "DisplayName", sValue)
    If sValue = Wscript.Arguments.Item(1) Then
    oRegistry.GetStringValue HKLM, sBaseKey & sKey, "UninstallString", sValue
    InstalledApplications = Replace(sValue, "/I{", "/X{")
    IF LEN(InstalledApplications) > 0 THEN
    InstalledApplications = InstalledApplications & " /qn /l*vx """ & sFile & ".Log"""  & Chr(13) & Chr(10) 
    END IF
    END IF
    NEXT
    END IF

    REM 2nd location: "SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\<GUID>\InstallProperties"
    arProducts = NULL
    sBaseKey = "SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\"
    iRC = oRegistry.EnumKey(HKLM, sBaseKey, arProducts)
    If iRC <> 0 THEN
    WScript.Echo "Registry lookup failed for " & sBaseKey
    ELSE
    For Each guid In arProducts
    sInnerKey = sBaseKey & guid & "\InstallProperties\"
    iRC = oRegistry.GetStringValue(HKLM, sInnerKey, "DisplayName", sValue)
    If sValue = Wscript.Arguments.Item(1) Then
    oRegistry.GetStringValue HKLM, sInnerKey, "UninstallString", sValue
    InstalledApplications = Replace(sValue, "/I{", "/X{")
    IF LEN(InstalledApplications) > 0 THEN
    InstalledApplications = InstalledApplications & " /qn /l*vx """ & sFile & ".Log""" & Chr(13) & Chr(10) 
    END IF
    END IF
    NEXT

    InstalledApplications = InstalledApplications & "GOTO:EOF"
    END IF


    Shawn (Mail@ShawnAugust.Com)

    Monday, February 23, 2015 1:51 PM

Answers

All replies

  • 64/32 bit execution environments.  Default build for VS is 32 bit.

    You need to ask this kind of question in the developers forum.


    ¯\_(ツ)_/¯

    Monday, February 23, 2015 2:15 PM
  • 64/32 bit execution environments.  Default build for VS is 32 bit.

    You need to ask this kind of question in the developers forum.


    ¯\_(ツ)_/¯

    Why would the "build" have anything to do with the execution of MS-DOS and VBScript files?


    Shawn (Mail@ShawnAugust.Com)

    Monday, February 23, 2015 3:04 PM
  • Depends on how you are executing MSBuild.

    Again - this is a question for the developer forum.  It is not a scripting issue as you have already proven that the script works.


    ¯\_(ツ)_/¯

    Monday, February 23, 2015 3:18 PM
  • Think about the issue. What does returncode 2 mean and why might you get it.  Either the path does not exist or you are looking at the wrong registry view.

    Try this:

    c:\windows\system32\cscript <yourscript>

    and

    c:\windows\SysWow64\cscript <yourscript>

    One should succeed and the other fail.


    ¯\_(ツ)_/¯

    Monday, February 23, 2015 3:22 PM
  • Think about the issue. What does returncode 2 mean and why might you get it.  Either the path does not exist or you are looking at the wrong registry view.

    Try this:

    c:\windows\system32\cscript <yourscript>

    and

    c:\windows\SysWow64\cscript <yourscript>

    One should succeed and the other fail.


    ¯\_(ツ)_/¯

    Both of the above call fails for me. It only works if I remove the call from MSBuild and just execute via MS-DOS shell window.

    Shawn (Mail@ShawnAugust.Com)

    Monday, February 23, 2015 7:29 PM
  • There is no DOS. Cmd.exe is a Win32 console program that, despite appearances, has nothing whatsoever to do with DOS.


    -- Bill Stewart [Bill_Stewart]

    Monday, February 23, 2015 8:16 PM
  • Think about the issue. What does returncode 2 mean and why might you get it.  Either the path does not exist or you are looking at the wrong registry view.

    Try this:

    c:\windows\system32\cscript <yourscript>

    and

    c:\windows\SysWow64\cscript <yourscript>

    One should succeed and the other fail.


    ¯\_(ツ)_/¯

    Both of the above call fails for me. It only works if I remove the call from MSBuild and just execute via MS-DOS shell window.

    Shawn (Mail@ShawnAugust.Com)

    I wanted you to run both of these commands at a command prompt and not from MSBuild.


    ¯\_(ツ)_/¯

    Monday, February 23, 2015 8:20 PM
  • Think about the issue. What does returncode 2 mean and why might you get it.  Either the path does not exist or you are looking at the wrong registry view.

    Try this:

    c:\windows\system32\cscript <yourscript>

    and

    c:\windows\SysWow64\cscript <yourscript>

    One should succeed and the other fail.


    ¯\_(ツ)_/¯

    Both of the above call fails for me. It only works if I remove the call from MSBuild and just execute via MS-DOS shell window.

    Shawn (Mail@ShawnAugust.Com)

    I wanted you to run both of these commands at a command prompt and not from MSBuild.


    ¯\_(ツ)_/¯

    My apologies for misunderstanding. The "system32" variant worked while the "syswow64" did not. 

    Shawn (Mail@ShawnAugust.Com)

    Tuesday, February 24, 2015 3:45 PM
  • Those keys are not visible form the 32 bit version of MSBuild and Visual Studio,  You must run from a 64 bit session to access the 64 bit registry.  Change your build environment to 64 bits and try it.


    ¯\_(ツ)_/¯

    Tuesday, February 24, 2015 4:06 PM
  • Or try sysnative:

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx


    Don't retire TechNet! - (Don't give up yet - 13,225+ strong and growing)

    But that is not a portable solution.  it does not apply to 32 bit platforms and will only work from a 64 bit session when calling intp a 32 bit session.

    If we are in a 32 bit session running VBScript then we cannot see the 64 bit registry without the help of WMI.  The correct solution is to build in the correct environment.  If you want to run in both environments then you will need to test the 32 bit version on a 32 bit system assuming the applications being enumerated use the same keys on both architectures.


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, February 24, 2015 4:33 PM
    • Marked as answer by SAgosto Tuesday, February 24, 2015 5:03 PM
    Tuesday, February 24, 2015 4:29 PM
  • Or try sysnative:

    https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx


    Don't retire TechNet! - (Don't give up yet - 13,225+ strong and growing)

    But that is not a portable solution.  it does not apply to 32 bit platforms and will only work from a 64 bit session when calling intp a 32 bit session.

    If we are in a 32 bit session running VBScript then we cannot see the 64 bit registry without the help of WMI.  The correct solution is to build in the correct environment.  If you want to run in both environments then you will need to test the 32 bit version on a 32 bit system assuming the applications being enumerated use the same keys on both architectures.


    ¯\_(ツ)_/¯


    This is correct. I totally forgot there are 32 bit and 64 bit versions of MSBuild. I made no changes except to execute the main deployment script with the 64 bit version of MS Build. Thank you for all of your help.

    -Shawn


    Shawn (Mail@ShawnAugust.Com)

    Tuesday, February 24, 2015 5:11 PM
  • Now that you recognize the symptom you will not get easily caught by this.  The first time is a bit of a hassle.

    ¯\_(ツ)_/¯

    Tuesday, February 24, 2015 5:18 PM