How to diagnose an URL based installation issue with a signed bootstrapper (setup.exe)? RRS feed

  • Question

  • We have been deploying C# applications to client computers for many years, using the same URL based installation, initiated by downloading a signed bootstrapper.  All of my old builds, signed with a SHA-1 cert, continue to work.

    All attempts to download and execute a newly built and signed bootstrapper (setup) result in "Windows protected your PC".  If the bootstrapper is copied to the new computer, from removable media or over an RD connection, it starts, as desired, requests and verifies the msi package, and executes the installation.

    Sigcheck says that the digital signature and certificate path are valid in the bootstrapper.  There is no difference between the manifests in working and "blocked" setup files (see Setup Manifest below).

    So...  It's looking like it's either a different problem within the setup file or an environmental / security change (in Windows or IIS).


    • Is there a new or existing setting in IIS to designate a file as an "installer" or similar?
    • Is there a new or existing way to bind or reference an installer file with a hyperlink?
    • Does MSIstuff.exe really exist?  ;  )  It would be nice to peek inside the setup file?
    • Are there other possible diagnostic tools?

      Windows Installer documentation brings you here:
      Which references msistuff.exe.  I have been unable to find it anywhere (even after installing nearly all of VS 2017, the installer pack, and windows sdk).


      Bill Clark

    Setup Manifest

    <?xml version="1.0" encoding="utf-8" ?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
          <assemblyIdentity name="Microsoft.Windows.Common-Controls" version="" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" type="win32"/>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
      <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
          <!--Windows 10 -->
          <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
          <!-- Windows 8.1 -->
          <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" />
          <!-- Windows 8 -->
          <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" />
          <!--Windows Vista -->
          <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
          <!--Windows 7 -->
          <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>

    We purchased a new SHA-1 authenticode cert in Oct. 2018.
    We didn't need to promote any new code until Feb. 2019.
    The C# projects and the (Setup) deployment projects have been built with VS 2015.
    The setup and msi files are signed with a SHA-1 cert.
    The setup and msi files are copied to a web server.
    All certificates on the path report as OK.
    The setup file is referenced with a basic link:
    <a href='https://myserver/myapps/thisapp/setup.exe'>Install</a> or
    <a href="setup.exe">Install</a>.
    Download and execution of the setup file results in "Windows protected your PC".

    We initially suspected the cert, so we requested a new SHA-1 cert and repeated the exorcise with the same result.
    We then thought that it might be an issue with SHA-1, so we requested a SHA-256 cert, repeated the exorcise, and once again, had the same result.
    Then we tried different timestamping authorities and different versions of signtool.exe.
    We were able to verify that our signature on the msi was acceptable to winverifytrust, by executing the setup file from external media or by copying it to a computer over RD.  An unsigned msi failed as expected (unrecognized publisher).
    We then turned to the bootstrapper and started reseaching the current state of windows installer.
    We repeated the exorcise using the SHA-256 cert and VS 2017, to the same end.

    Thursday, February 21, 2019 11:04 PM

All replies

  • Hello,

    You might check if there is a policy prohibiting this action even with a certificate. The company I work for does not accept a install because it has a validate certificate as there are internal policies prohibiting this so you might check if something has changed it policies for installations. 

    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.
    VB Forums - moderator
    profile for Karen Payne on Stack Exchange, a network of free, community-driven Q&A sites

    Friday, February 22, 2019 1:55 AM
  • Hi water_rat_,

    Thank you for posting here.

    Since your question is more related to Setup and Deployment, I will move it to ClickOnce and Setup & Deployment Projects forum.

    The Visual C# forum discuss and ask questions about the C# programming language, IDE, libraries, samples, and tools.

    Best Regards,


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact

    Friday, February 22, 2019 3:13 AM
  • Thank you Wendy.  I missed the "and" in ClickOnce and Setup & Deployment Projects...
    Friday, February 22, 2019 4:53 PM
  • Did you ever find msistuff.exe?  I too have gone through multiple interations of the win 10 sdk install that claims to have this exe in it but to no avail. Maybe msitools port.?

    I do see msiinfo.exe and others in C:\Program Files (x86)\Windows Kits\10\bin\x86.  Just not MsiStuff.exe.

    Thank you.

    Just trying to do this 2018 example:

    UPDATE 20191109: Solved by finding old source code at

    and compiling in a developers prompt.  Still find it hard to believe all searches led to a 2018 microsoft article that relied on this non-existent exe.  Not the MSFT I remember working for.  


    • Edited by naticklamb Saturday, November 9, 2019 9:33 PM
    Wednesday, October 16, 2019 6:44 PM