New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Melt.exe crashes when melting an MSI and running with elevated privileges #5859

Open
dtuchlinsky opened this Issue Aug 3, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@dtuchlinsky
Copy link

dtuchlinsky commented Aug 3, 2018

  • Which version of WiX are you building with?

WiX v3.11.1

  • Which version of Visual Studio are you building with (if any)?

N/A

  • Which version of the WiX Toolset Visual Studio Extension are you building with (if any)?

N/A

  • Which version of .NET are you building with?

.NET v4.6.1

  • If the problem occurs when installing your packages built with WiX, what is the version of Windows the package is running on?

(Windows version)

  • Describe the problem and the steps to reproduce it.

Melt.exe crashes when melting an MSI if it is run with elevated UAC privileges. Melt will run fine in the same environment if melt.exe is run without elevated UAC privileges. This was working fine until KB4338420 was installed on our build servers which caused all patch builds to fail.
Steps to reproduce:

  • Install “Update for Microsoft .NET Framework 4.6.1 (KB4338420)” on a Windows 2008 R2 server (also reproducible on Windows 7).
  • Launch a command prompt with elevated UAC privileges (i.e. run as administrator)
  • Run melt against an MSI with the matching wixpdb

Output from melt below
"C:\Program Files (x86)\WiX Toolset v3.11.1\melt.exe" "test.msi" "test.wixpdb" -pdb "test.wixpdb"
Windows Installer XML Toolset Melter version 3.11.1.2318
Copyright (c) .NET Foundation and contributors. All rights reserved.

test.msi / test.wixpdb
melt.exe : error MELT0001 : Could not find a part of the path 'C:\Users\test\AppData\Local\Temp\p1nkl0pw\p1nkl0pw.cab'.

Exception Type: System.IO.DirectoryNotFoundException

Stack Trace:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at Microsoft.Tools.WindowsInstallerXml.Pdb.Load(Stream stream, Uri uri, Boolean suppressVersionCheck, Boolean suppressSchema)
at Microsoft.Tools.WindowsInstallerXml.Pdb.Load(String path, Boolean suppressVersionCheck, Boolean suppressSchema)
at Microsoft.Tools.WindowsInstallerXml.Tools.Melt.MeltProduct()
at Microsoft.Tools.WindowsInstallerXml.Tools.Melt.Run(String[] args)

  • Describe the behavior you expected and how it differed from the actual behavior.

Melt should be able to melt an MSI when running with or without elevated privileges.

@BMurri

This comment has been minimized.

Copy link
Collaborator

BMurri commented Aug 3, 2018

@dtuchlinsky

This comment has been minimized.

Copy link

dtuchlinsky commented Aug 3, 2018

In Microsoft.Tools.WindowsInstallerXml.Pdb.Load(Stream stream, Uri uri, bool suppressVersionCheck, bool suppressSchema), an instance of TempFileCollection is created to generate a name of
using (TempFileCollection tempFileCollection = new TempFileCollection()) { cabPath = tempFileCollection.AddExtension("cab", true); }

KB4338420 changed the behaviour of TempFileCollection. Before KB4338420 was installed, TempFileCollection::AddExtension would return a file path in the %TMP% directory (i.e. C:\Temp\zwlyt205.cab). After KB4338420 is installed, it would create random subdirectory in %TMP% and return a file path in this directory (i.e. C:\DaveTemp\zwlyt205\zwlyt205.cab).

The "using" statement in Pdb.Load would cause the instance of the TempFileCollection to be disposed of which will delete the temporary folder in the %TMP% directory since the cab file has not yet been created. Later in the function another instance of TempFileCollection is created and the cab file is added to this.

A solution to this is to avoid using the "using" statement to prevent the premature garbage collection.
Microsoft.Tools.WindowsInstallerXml.Pdb.Load also uses the TempFileCollection, however, it avoids creating a temporary instance of it.

@barnson

This comment has been minimized.

Copy link
Member

barnson commented Aug 16, 2018

If the fix is simple/safe, we'd take it in v3.14. (We'll investigate the PR.) Otherwise, the bug doesn't occur in WiX v4.0 because it doesn't use TempFileCollection at all.

@jakebullet70

This comment has been minimized.

Copy link

jakebullet70 commented Aug 28, 2018

What is the status of this bug? I am running into the same problem as mentioned here on our Server 2008 build machine. I did try and install 'https://support.microsoft.com/en-us/help/4345913' as mentioned above but this did not help. I see that a fix has been submitted but it looks like it has not been merged.

@CC4C37A9-A0F6-43C9-B966-B26952D6B656

This comment has been minimized.

Copy link

CC4C37A9-A0F6-43C9-B966-B26952D6B656 commented Nov 28, 2018

Hi guys,
I managed to solve that issue on Wix Toolset 3.11 by turning the Windows UAC back on.

Please note:
Turn the Windows UAC back on. With that enabled, no program you start will automatically run as administrator

Best regards,
Wanderson PIN

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment