none
UAC prompt: Do you want to allow this app to update software on your device?, but no way to say Yes or OK, only Close. RRS feed

  • Question

  • After patches last night, roughly half of our Windows 10 PCs are getting a red UAC prompt (which usually means blocked, per the color codes described here: https://technet.microsoft.com/en-us/library/dd835561%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396.

    The message on the prompt says: "Do you want to allow this app to update software on your device?", but there are no "Yes" /"No" buttons - only "Close":


    We are shown on the prompt as a "Verified publisher" and the MSP & contents are signed with our current, valid AES 256 certificate from DigiCert:


    Any suggestions on how to debug / correct this would be greatly appreciated. Our build / packaging / deployment process is automated, so it seems odd it would work one day then cause issues the next. I do know a number of people have recently updated to the "Anniversary" Windows 10 update, but these prompts are happening on PCs with and without that update.

    Thanks in advance for any assistance or suggestions related to this issue.



    • Edited by Jeager Thursday, September 22, 2016 2:09 PM Adding pictures
    Thursday, September 22, 2016 1:46 PM

All replies

  • I emailed the fissues <at> microsoft.com about account verification, and they were very responsive. As a result I was able to edit the above to include pictures that I think should be very helpful in illustrating the issue. Thank you so much for the quick response Mr. Divya!
    • Edited by Jeager Thursday, September 22, 2016 2:11 PM
    Thursday, September 22, 2016 1:49 PM
  • Hi Jeager,

    That's weird. Since the elevation prompt color-coding is as follows:

    • Red background with a red shield icon: The application is blocked by Group Policy or is from a publisher that is blocked.

    • Blue background with a blue and gold shield icon: The application is a Windows 7 administrative application, such as a Control Panel item.

    • Blue background with a blue shield icon: The application is signed by using Authenticode and is trusted by the local computer.

    • Yellow background with a yellow shield icon: The application is unsigned or signed but is not yet trusted by the local computer.

    Did you install that app by yourself or unknown? What's the next operation if you click "Close" button?

    In addition, since you mentioned this issue occur after patching, please remove the update one by one to narrow down which update cause this issue.


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

    Friday, September 23, 2016 6:46 AM
    Moderator
  • We installed on workstations here at work, and 7 of 11 got the mangled UAC prompt (red background and only a "Close" button, but the "Do you want to allow...?" prompt and the "Verified publisher" listing for our company).

    The next operation when we hit the "Close" button was for UAC to disallow installation of the *.msp patch file. Our application stayed at 4.0.4 instead of patching to 4.0.5 (I'm omitting the build number).

    On a hunch I went and lowered UAC to the bottom rung setting and the workstations were able to get patches. We moved the setting right back up after installing because it doesn't seem safe to leave UAC disabled like that.

    Friday, September 23, 2016 1:33 PM
  • On a hunch I went and lowered UAC to the bottom rung setting and the workstations were able to get patches. We moved the setting right back up after installing because it doesn't seem safe to leave UAC disabled like that.

    Yes, security is the first.


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

    Tuesday, September 27, 2016 8:50 AM
    Moderator
  • My issue with marking this as the answer is we will not be able to simply ask our customers to lower their UAC security levels - even if we explain they should then revert them to their previous setting once patched.

    First, we patch fairly often due to the time sensitive nature of information contained in our application. Second, a lot of our customers are not particularly technical. Their area of expertise is financial in nature, not computer science.

    Taking a step back, if we are shown as a verified publisher by the prompt and the prompt is asking whether or not the user "wants to allow this app to update software on your device?"... why is the user not given a"Yes"/"No" buttons option to answer the question?

    This continues to plague all Windows 10 Anniversary or later installations, though seemingly at random. One day's patch sets off numerous mangled prompts like the one pictured at the top, the next day's patch may install perfectly fine. Then a few days later, back to mangled prompts.

    Wednesday, October 5, 2016 12:10 PM
  • This is still an issue that happens sporadically on Windows 10 machine. One day the patch will cause the mangled UAC prompt which doesn't allow for the installation of a valid, signed MSP despite asking the user if they would like to install... the next day a patch will work fine.

    We cannot continue to ask our clients to lower their UAC, install, and restore their UAC settings and we are not comfortable asking them to permanently lower UAC (nor would Microsoft  recommend such, I would imagine).

    We would love to get an official explanation for why this is happening and what / if anything we can do to correct. The prompt, as seen in the screenshot above, does not appear to be a valid prompt for any level of UAC elevation.

    Wednesday, October 19, 2016 3:21 PM
  • Hello Jeager,

    Have you resolved this issue? We are having exactly the same problem with our patch updates.

    Alan

    Tuesday, December 13, 2016 7:11 PM
  • Hi Jeager,

    Have you got an official explanation from MS or resolved this issue any other way? I'm having exactly the same problem with my MSI installer.

    Thursday, March 9, 2017 10:47 AM
  • I opened a ticket on 12/21/2016 it took me until 2/2/2017 before I was put in contact with an engineer who was prepared to consider that the problem lay in Microsoft's domain. However, she spent nearly 4 weeks (and a lot of my time) still trying to come up with a workaround. Finally on 2/28 she engaged her manager and on 3/3 she informed me that they had now engaged the developer team!!

    I am anxiously awaiting the next step :) 


    Thursday, March 9, 2017 2:19 PM

  • Here is a report of the same message with some 3rd party installer:
    Single EXE:“Repair” option causes red elevation prompt without Yes button
    One of the comments ironically links to here, but one other commenter wrote:
    Looks like there is a problem with your bootstrapper. I've built setup with setup.exe, separate .msi and separate .cab files. Then added all of them to RAR SFX. Now when SFX it extracts files to some folder and runs setup and does not delete extracted files, repair works without any issues.
    So I guess you modify extracted from bootstrapper files in some way after extraction

    So are you doing something special in your patch?
    Back in the day you could use Orca to verify msi and msp files. When this is still possible you could give it a try.

    Thursday, March 9, 2017 8:40 PM
  • I do apologize for the significant delay in response. 

    In 2016 what we discovered is you cannot patch SDF files (SQLCE data files). As a result of what we found in the beta stage of our product, we moved all static table data to code classes instead of publishing SQLCE data files. They are not versioned in such a way as to be patch-able using Windows Updates.

    We turned on verbose logging for the Windows Installer and tracking through the logs we saw where it failed to patch SQLCE files, abruptly ending the patching process. Why that threw up a red UAC is beyond me, but once we took care to not try and patch in those data files - our issues w/ UAC stopped entirely.

    Also, we tracked back to every known instance of a customer encountering the red UAC prompt and found a direct link to patches there those files were included, which explained the "seemingly random" behavior I first reported.

    While you may not use SQLCE files, it might be helpful to know that installation errors can throw up the red UAC. Hope it helps.

    Wednesday, January 29, 2020 3:44 PM