wyUpdate having trouble under Win 7Solved

Hey Simon,

On our test Win 7 machines, wyUpdate encounters an error (undefined).

What do you mean by undefined error? Does wyUpdate just crash? If so, at what point does it crash (checking for updates, installing files, registry, etc.)? If it doesn't crash, what error message does it display?

Also, are you using wyUpdate with the AutomaticUpdater or just wyUpdate alone?

Are you aware of any rights or limitations under Win 7 that might be causing the problem?

No, wyUpdate works on Windows 2000 through Windows 7.

Is there a log I can investigate to see exactly what is causing the failure?

No, but wyUpdate should give you a full error when it happens.

Thanks, Sam. Here is a fuller description. I do not believe I can attach screen shots so I'll try to describe as best I can.

The application is a client-server app that is, per tradition, installed under c:/Program Files.

Whenever it starts up. it calls wyUpdate to see if any newer files exist on the ftp server. For regular users on the Win 7 workstation, this attempt to call wyUpdate results in: "wyUpdate has stopped working. It is trying to locate a solution to the problem." After about 20 seconds, this message is replaced with "Error will checking for upgrade, Return code = 20301."

If we grant the local user account full admin rights, wyUpdate runs more successfully. However, company policy will not allow us to grant these generic users accounts, which will be the ones to run (and update) the application in the long run, the full admin rights.

Obviously, the issue is one of Win 7 workstation security. What are the options we have to run wyUpdate, preferrably in as unobtrusive a way as possible?

First, try it again with the latest version of wyUpdate (2.6.13). What commandline arguments are you running wyUpdate with and where are your running wyUpdate from (e.g. a GUI app or a Windows Service)?

If I could see a small snippet of code showing how you're starting wyUpdate it would be great.

Thanks again, Sam.

I'll work with our developers to see if they can get me an updated version of wyUpdate.exe. In the meantime, though, here is the code snippet (more or less; the developers didn't provide actual code)

>To check for updates the following command line is used:>wyupdate.exe -quickcheck -justcheck -noerr>>If updates are available, we simply run:>wyupdate.exe

This is run from the application; when it forst starts up, one of the commands it executes is this call to wyUpdate.

Here is a more detailed description of what we are encountering:If we log into the machine with UAC turned off and as the local administrator, wyUpdate performs perfectly. However, as I mentioned, such lax security settings will never be approved by our logistics group; UAC on and no local admin rights will be the account settings for users of this application. Now, when I run wyUpdate with UAC turned on, we encounter errors like the one I described in earlier posts. I'm pretty sure the issue we're having with wyUpdate must be tied to Win 7 security.

As I mentioned, the application is installed in c:\program files\<our app>\ and I am assuming that Windows is pretty restrictive, by default, as to what kind of changes can be made to c:\program Files. Before I go to the trouble of considering installing the application in a different folder (perhaps under one of the Users folders, or in the root of the C: drive?), which would entail that we reinstall the application on all our PC's, I ask: How have other wyUpdate users resolved the security issues with Win 7 when trying to manage applications that reside in Program Files?

Thanks!

Simon

I can't reproduce this on Windows 7 on a Limited Account with UAC turned on (or any other combination). It all works fine here on both limited and admin accounts (with UAC on or off).

I have a few more questions:

1) DId you (or your developers) make any modifications to wyUpdate? (A quick way to check is to right click wyUpdate.exe, click Properties, and there should be a "Digital Signatures" tab. If the "Name of the signer" is not "wyDay" or if the "Digital Signatures" tab is not there then you're using a modified wyUpdate. Only use our version of wyUpdate.

2) Are you running wyUpdate in "Compatability Mode"? If so, don't.

3) What happens when you just double click wyUpdate.exe - does it crash?

4) If it doesn't crash then open "cmd.exe" from your start menu, when run wyUpdate.exe from this commandline window with the "-quickcheck -justcheck -noerr" commandline arguments. Does it crash?

5) Are you using the "Group Policy Editor"? If so, try wyUpdate again under a plain old vanilla limited user account. Does it work?

To answer your question:

1) properties for wyUdate.exe has no 'tab' labeled "Digital Signatures". Only General, Compatibility, Security, Details, Previous Versions (btw its version 2.6.1.2 - modified date 10/1/2010 10.07 a.m

2) No - not running in compatibility mode

3) Double-click wyUdate.exe - yes, it crashes. If we change the privelege level to "Run this program as an administrator" ... it will prompt for elevated creds. If we supply local admin level creds, it runs...

As Simon mentioned - UAC must be enabled (currently at highest level) and users run the application with Standard User security role.

Is there a way to configure such that the wyUdate.exe does not need local admin rights to run?

When you're on either an admin account or a standard account with UAC enabled, then wyUpdate will prompt for elevation.

Try again using the latest version of wyUpdate (2.6.14). If that still crashes we'll have to schedule a time to debug this remotely on your computer.

How do I get version 2.6.14?

To answer your question - If I log in with an account with local admin privileges and double-click the wyUdate.exe, it generates the same error as when logged in with a Standard User account.

But - if I right-click the wyUdate.exe and select 'run as administrator' , it brings up the UAC window and I can click YES and it will run fine. (BTW - the publisher is listed as "unknown")

Is the missing 'signed digital signature' the reason for the UAC prompt requirement we are seeing and why you can't replicate in your lab? I also ran the Standard User Analyzer tool... let me know if this would be helpful.

You can get the latest version of wyUpdate by updating wyBuild. Then click the "Build wyUpdate" button. See the "new release workflow" article.

(BTW - the publisher is listed as "unknown")

You're using a custom version of wyUpdate. We don't support custom builds of wyUpdate. Only use our builds of wyUpdate.

Thanks. Understood.

Am I to assume your latest release can operate correctly in Windows 7 with Standard User and UAC enabled?

Yes, our version of wyUpdate works correctly on Windows Vista / 7 with UAC enabled, disabled, and every other combination.

Does this include files that are updated using wyUpdate? I assume when you say "wyUdate" works with Win7 Standard User and UAC enabled, that includes the actual files it is updating?

Yes, if wyUpdate needs to elevate it elevates itself. It can update any files anywhere.

Hi Wyatt,

I am having a similar problem with Win7, UAC and a standard limited user. wyUpdate starts, checks for update, displays update information. when I click Update - it prompts me to enter Admin password. After I enter the admin pass - it crashed with error:

Description: Stopped working

Problem signature: Problem Event Name: CLR20r3 Problem Signature 01: wyupdate.exe Problem Signature 02: 2.6.14.0 Problem Signature 03: 4ddcec0c Problem Signature 04: wyUpdate Problem Signature 05: 2.6.14.0 Problem Signature 06: 4ddcec0c Problem Signature 07: 19d Problem Signature 08: 4f Problem Signature 09: System.NullReferenceException OS Version: 6.1.7600.2.0.0.256.1 Locale ID: 1033

Please advise.

thanks,Alex Kulick

Hey Alex,

Are you using a custom version of wyUpdate? Right click wyUpdate.exe, click Properties, click the "Digital Signatures" tab. Is the "Digital Signatures" present? Is the name of the signer "wyDay"?

yes, wyDay is the signer. I just downloaded the new version and built wyUpdate using the latest wyBuild.

We can't reproduce this -- elevating from both standard and admin users works fine. Email me some times you're available so I can remotely debug this. My email is wyatt@wyday.com.

For those wondering what these errors are, it's all related to a common mistake people make when creating a custom version of wyUpdate. (For the correct way to make custom versions of wyUpdate, see: How to make a custom version of wyUpdate).

Open your "wyUpdate self-update" wyBuild project. Go to File -> Properties -> Update & server files. Look at the server filename. It should be different that your main app wyBuild project. For instance, in your app's project the server filename should be something like "wyserver.wys", and in the self-update project the server filename should be anything different (e.g. "selfupdate.wys").

It should go without saying that wyUpdate should never crash (even if the configuration is messed up). We'll fix this for wyUpdate 2.6.15. That is, in 2.6.15 the "self-update" *.wys file will never overwrite the "app" *.wys file even if they are named the same thing.

Hi, not meaning to hijack this thread, but I have a related question. I am looking for a suggestion of best practices related to making wyUpdate function in an environment using group policy where local or domain admin rights are never given to the end user.

Situation:1) UAC elevation is working fine for me. Users are appropriately prompted, but is some scenarios they never have admin credentials to enter.2) I have a client with massive group policy applied and does not grant (currently) admin account information to domain users. With 500+ clients deployed automatic updates is basically pointless because a tech has to go to each computer to run the automatic update. In fact half the time they just run the new MSI.

Options (in no particular order):1) Don't use MS best practices and install the program to a folder off the root instead of Program Files. No UAC will occur.2) Change the security rights on the Program Files/Man/Prod directory to give full rights to Users group. I am already changing rights on the corresponding ProgramData directory, but this does leave the assemblies exposed to all end users. (possibly a necessary risk).3) Have the group policy modified to all automatic admin rights granted to wyUpdate.exe without a prompt. This can be done with several tools, but is up to the Domain management team to handle. I suppose that if using the .Net control for automatic updates, the program assembly is the one that would need to be whitelisted. I am not using the .Net update control so I am not sure if it still call wyUpdate.exe.4) Use an encrypted file to hold a local admin account username and password and call the wyUpdate process with elevated privileges using an admin account. Major hassle factor distributing and maintaining login information in an encrypted file (but that is still better than hard coded into the app).5) Install a local service with your primary application that accepts commands. The service will execute wyUpdate when your application passes the service an update request. Since services get all the privilege stuff out of the way at install the end user won't get prompted by UAC.

I am pushing my client for a Group Policy Object (GPO) fix, so I don't have to change anything, but if there are some recommended best practices to help address these situations I think it would make good information for developers so they can address these situations when GPO control is not something they will have.

Thanks,Chris

Hey Chris,

We've had more than one customer run into these problems with corporate "locked-down" computers. We're working on a pre-built solution to this problem that will allow IT administrators to update large swaths of computers at once.

1) Don't use MS best practices and install the program to a folder off the root instead of Program Files. No UAC will occur.

Not the root directory, but rather a %userprofile% directory. That is, %appdata%, the desktop, etc., etc. This will let non-admin users update.

2) Change the security rights on the Program Files/Man/Prod directory to give full rights to Users group. I am already changing rights on the corresponding ProgramData directory, but this does leave the assemblies exposed to all end users. (possibly a necessary risk).

Right, this is just like the first suggestion except you're giving the user permission for a folder in Program Files. There's no real security risk other than the user can delete the app files.

3) Have the group policy modified to all automatic admin rights granted to wyUpdate.exe without a prompt. [...]

This is more trouble than it's worth.

4) Use an encrypted file to hold a local admin account username and password [...]

Ditto.

5) Install a local service with your primary application that accepts commands. The service will execute wyUpdate when your application passes the service an update request. Since services get all the privilege stuff out of the way at install the end user won't get prompted by UAC.

This is what we currently recommend. This is the perfect balance between letting customers update their apps without giving them permission to modify them. Although this particular choice requires you to build a dummy service to do the actual updating:

• How to Silently update a Windows Service
• AutomaticUpdater tutorial for Windows Services and Console Apps

Sam thanks for the reply.

Since the installer already sets the permissions on the ProgramData directory, I have decided to go with the same on the Program Files directory for the application. This was the path of least resistance. By "security risk", I mean as defined by my clients corporate IT department. Regarding option 2, setting the rights for all Users off the root should have the same effect.