Hey Alex,
Does this error only happen when wyUpdate is self-updating? That is, when you have an older version than the latest version?
wyUpdate exited prematurely / wyUpdate failed to start
Hi,
We have the following versions installed on the development Windows 7 64-bit machine:
A. wyBuild => 2.16.17.1 - Check for updates states that all is up to date.B. AutomaticUpdater.dll .Net 4.0 => 2.6.16.0 - this is located in C:\Program Files (x86)\wyBuild\AutomaticUpdater\Microsoft .NET 4.0 folderC. wyUpdate.exe => 2.6.16.4
Our own application is a 32-bit Windows service written in C#, performing silent checks for updates every 10 minutes. We host wyUpdate.exe's self-updates on our own updates server, i.e., client.wyc contains our own site as specified in wyBuild's File / Properties / wyUpdate tab.
Originally installed versions of wyUpdate.exe & AutomaticUpdater.dll were 2.6.14.0 and 2.6.14.0 respectively, i.e., the same version.When we pushed the updated .wyu and .wys files, all the updates (both our own app & wyUpdate.exe) were auto-updated successfully. So B and C were updated and reside in the app folder on different client installations, both 32-bit & 64-bit Windows 7.
On one of the installations (32-bit) every 5th check for updates consistently results in the following error, as logged inside CheckingFailed event handler:
Error: wyUpdate exited prematurely Message: wyUpdate failed to start.
It does appear that the other 4 out 5 checks for updates result in no errors at all. So we have these errors occurring exactly every 50 minutes ever since the update took place.
The error does not occur on Win7 64-bit client installations, though this may or may not be relevant.
Thanks a lot,Alex
No, wyUpdate itself & our own software were both updated successfully. No new versions (.wyu / .wys) are available on our update server.
This every-5th-check-for-updates error began occurring ever since that successful update...
Just as a reference, we took your advice from this post (https://wyday.com/forum/t/1189/error-downloading-client-net4-wys-wyday-com-from-a-locked-down-machine/) to host wyUpdate self-updates and modified clients' hosts file to resolve the updates site name to a known IP. So client.wyc points to our own site. This did work very nicely, i.e., wyUpdate self-updated just fine...
Thanks!
Originally installed versions of wyUpdate.exe & AutomaticUpdater.dll were 2.6.14.0 and 2.6.14.0 respectively, i.e., the same version.When we pushed the updated .wyu and .wys files, all the updates (both our own app & wyUpdate.exe) were auto-updated successfully. So B and C were updated and reside in the app folder on different client installations, both 32-bit & 64-bit Windows 7.
It sounds like you're testing updates from your software that has wyUpdate/AU version 2.6.14 installed and you're updating to a version that has wyUpdate version 2.6.16.4 and AU version 2.6.16.0. Is that correct?
If that is correct, my question is does this error every 5th update happen when the wyUpdate.exe is the latest version? That is, you say the version has wyUpdate version 2.6.14.0 installed. What happens if, before running your update, you manually replace wyUpdate.exe with the latest version (2.6.16.4). Does this error still happen?
This error occurs with already updated version of both wyUpdate and AU.dll.In other words, the currently running versions are 2.6.16.4 and 2.6.16.0 respectively.So the actual update did take place successfully. Now it's just periodic checks for updates, but everything is up to date
Hopefully I'm not being too confusing...
No, I understand. We're trying to reproduce this without any luck. Can you make a simple example app that reproduces this problem? Also, what are the specs for the Windows 7 32-bit machine?
RAM? CPU cores? CPU speed?
Aside from the specs, the only major difference that I do know, is that this particular machine resides at a customer's location and is completely locked out with respect to networking. It has no access to the outside world, and can only connect to the update server via a VPN tunnel.
The only puzzling thing is that this error does not occur on every check for updates, but every 5th one.
We have 3 other non-locked down machines in our own environment, both 32 & 64 bit Win 7, where this error does NOT occur.
But I'll get the precise machine specs for the one we're getting the errors on.
For reference, wyUpdateCommandline is set to:-server="https://some-ip/updates/beta/wyserver.wys" -updatepath="https://some-ip/updates" /fromservice -logfile="C:\ProgramData\cvodUpdaterLog.txt"
Hi Wyatt,
Here are more details about the machine:
Windows 7 ProfessionalPentium(R) Dual-Core CPU E6500 @ 2.93GHzRAM: 2.00 GBHard disk: 23GB Free (33GB Total)32-bit operating systemDisplay adapter type: Intel(R) B43 Express ChipsetTotal available graphics memory: 795 MBNetwork Adapter1: Intel(R) 82567LM-3 Gigabit Network ConnectionNetwork Adapter2: Intel(R) Gigabit CT Desktop Adapter
Ok, we'll try reproducing this on a similarly spec-ed machine.
We're not having any luck reproducing this behavior. The only thing we can think of is if the computer is extremely loaded (near 100% CPU and/or memory usage). Can you reproduce this on any of your computers?
You hit the nail on the head with your hypothesis! After reading your last post and asking the client about their CPU utilization, it turned out that there is a periodic switching of partitions on that machine for their video recording software. That's when the CPU does spike for some time, which is exactly around the time our app tries to invoke wyUpdate.
This would certainly explain why neither you nor we were able to reproduce on any of the other machines...
Thank you very much for trying to reproduce and pointing in the precise location of the culprit!
Alex
Thank you very much for trying to reproduce and pointing in the precise location of the culprit!
It's my pleasure. Just FYI, the reason you get the "wyUpdate failed to start" message is because the AutomaticUpdater only waits a finite amount of time (30 seconds in the current version) for wyUpdate to start. If it doesn't start within that finite amount of time then it shows the error.
Maybe we should bump up that time to around a minute.