Recurring error on restarting application after auto update

Hey Mark,

Are you using the latest wyUpdate & AutomaticUpdater (v2.5.22)?

I thought that WyUpdate would automatically close all instances of my program.

No, it won't. That's probably the problem. The AutomaticUpdater only closes the first instance of your app. And wyUpdate should show a list of exes that need to be closed, but only if wyUpdate is in the parent directory (e.g. C:\dev\demo\LengthConverter\ or C:\dev\demo\LengthConverter\Current\).

Is wyUpdate showing a dialog listing the other running instances of "LengthConverter.exe"? Is the "LengthConverter.exe" being used by another program? Open task manager, how many instance of wyUpdate are running?

Can you reproduce this problem consistently? It would be easier for us to debug if you could.

Hi Wyatt,

I am indeed using 2.5.22 of wyUpdate and the AutomaticUpdater.

This morning, after a clean reboot since yesterday, I have run my application with the automatic update about probably 30 times, and only once did it get stuck in that loop where it wouldn't update properly.

When it *does* update properly, the first 3 steps of the update go very quickly, but the last step takes 1-2 seconds; enough time to actually see the "spinning wheel" on the last step. When it does *not* work properly, I noticed that the second step (backing up and updating files) would be marked with a red X, and wyUpdate would close almost instantly.

Watching the Task Manager, I was able to confirm that there was only one wyUpdate open and that my application was being properly restarted (as its PID would change). So, the likely culprit at this point seems to be the backing up and updating files step -- looking at the filesystem activity in Process Monitor, I can see that wyUpdate tries to create the LengthConverter.exe file 3 times, each time receiving a "SHARING VIOLATION"; then it waits about 0.3 seconds and tries 3 more times and gets the same error.

However: speaking with our IT guy, he suggested that because of the particular error and because of how infrequently it happened, it's very likely due to our anti-virus scanning the file and not allowing writes at that time. I am personally satisfied with this explanation.

As a workaround, you might consider backing off for a moment if you get a sharing violation when trying to overwrite an executable before retrying. Or, at least prompt the user that although the process was closed, write access to the executable was denied.

I hate to post unrelated questions in the same thread, but I'm not sure this deserves its own post: are you aware that while wyUpdate is open, if a user clicks the cancel button but does not click yes or no to the "are you sure" prompt, the update will still fully apply? I would think that wyUpdate should not close while the prompt is open.

Watching the Task Manager, I was able to confirm that there was only one wyUpdate open and that my application was being properly restarted (as its PID would change). So, the likely culprit at this point seems to be the backing up and updating files step -- looking at the filesystem activity in Process Monitor, I can see that wyUpdate tries to create the LengthConverter.exe file 3 times, each time receiving a "SHARING VIOLATION"; then it waits about 0.3 seconds and tries 3 more times and gets the same error.

Can you see from the logs which copy of "LengthConverter.exe" is receiving the "SHARING VIOLATION"? Or is it all copies? The reason I ask is that at one point in the update process there will be 3 copies of the *.exe.

1. The original.
2. The backup of the original.
3. The new version.

Is the sharing violation happening 3 times a single copy, or once to each copy?

However: speaking with our IT guy, he suggested that because of the particular error and because of how infrequently it happened, it's very likely due to our anti-virus scanning the file and not allowing writes at that time. I am personally satisfied with this explanation.

Your IT guy is very likely right. Can I ask what anti-virus you're using (name & version)?

This problem might also be caused by Windows Explorer reading & locking the file while it tries to load the thumbnail. This was a notorious problem with early versions of Windows XP. What version of Windows are you running, and are you using the latest SP?

As a workaround, you might consider backing off for a moment if you get a sharing violation when trying to overwrite an executable before retrying. Or, at least prompt the user that although the process was closed, write access to the executable was denied.

Sure, we'll add a dialog to notify the user of the locked file and allow the user to retry updating. This should be in wyUpdate v2.5.24 coming in a couple of weeks.

I hate to post unrelated questions in the same thread, but I'm not sure this deserves its own post: are you aware that while wyUpdate is open, if a user clicks the cancel button but does not click yes or no to the "are you sure" prompt, the update will still fully apply? I would think that wyUpdate should not close while the prompt is open.

Yes, this is a bug. The update progress should pause while the cancel dialog is up. We'll have this fixed in wyUpdate 2.5.24. Thanks for spotting it.

Can you see from the logs which copy of "LengthConverter.exe" is receiving the "SHARING VIOLATION"? Or is it all copies? The reason I ask is that at one point in the update process there will be 3 copies of the *.exe.

At time T, I have a successful CreateFile at MyDocuments/wc/e/base/LengthConverter.exe. At T + 0.11s, I have a successful CreateFile at WorkingDir/LengthConverter.exe. At T + 0.13s, I have a successful CreateFile at MyDocuments/wc/e/BACKUP/base/LengthConverter.exe. At T + 0.25s, I have a successful CreateFile at MyDocuments/wc/e/base/LengthConverter.exe.At T + 0.36s, I have a sharing violation on CreateFile at WorkingDir/LengthConvert.exe.At T + 0.66s, backup/base/LengthConverter.exe is opened, and then CreateFile on WorkingDir/LengthConvert.exe receives a sharing violation again.

If you need any more information, I can send you the Process Monitor logs I've saved (this one with the failure, and another one that successfully updated). Just PM me with where I should email it.

Can I ask what anti-virus you're using (name & version)?

This problem might also be caused by Windows Explorer reading & locking the file while it tries to load the thumbnail. This was a notorious problem with early versions of Windows XP. What version of Windows are you running, and are you using the latest SP?

I'm running Symantec Endpoint Protection v11.0.5002.333. Right now, I have Antivirus and Antispyware protection on with definitions from May 6 2010 r25, and Proactive Threat Protection from May 6 2010 r17. I don't know if those were the same definitions as yesterday, but that shouldn't make a difference anyway.

I'm running XP Pro SP3 with (AFAIK) all the latest updates.

This problem is caused by other programs not playing nice. But we'll include a delayed-retry on sharing violation errors and a dialog that lets the user retry again if there's still an error.

Thanks for reporting this Mark.

Ok, these problems are fixed in wyBuild 2.5.24 (out now). Thanks for reporting these issues.