'Error: Another updater instance is running' when trying to start DCSW

[ARM505]

During an update by the autoupdater, my UPS decided to die, and the PC powered down. Now, whenever I try to start DCS World, I get the message Error: Another updater instance is running.

 

There isn't any other DCS or related process I can find that is running. The repair option just gives the same error. Multiplayer loads ok. Anything else gives the error. Is this just not a very robust program or am I missing some obvious solution? I've tried deleting autoupdater logs etc, no joy, same error every time.

[ARM505]

This is the autoupdate.log

 

00000.000 INFO : === MiniLog opened UTC 2012-11-20 18:46:19

00001.009 ERROR : Caught an exception: Another updater instance is running.

00002.094 INFO : === MiniLog closed.

 

 

ie basically useless.

[aap_flanker]

I had same issue today when my connection hangs... I resolved by open task manager, and have to finish the autoupdater process. Then I start autoupdater and the update was acomplished without any problem

[c0ff]

During an update by the autoupdater, my UPS decided to die, and the PC powered down. Now, whenever I try to start DCS World, I get the message Error: Another updater instance is running.

 

There isn't any other DCS or related process I can find that is running.

 

It's a problem of Windows, it should delete the lockfile when the process exits.

But in such case it seems not to.

Please, delete the file C:\Users\<YOU>\Saved Games\DCS\autoupdate.lock

 

I'll think about a better solution for this.

[ALDEGA]

I'll think about a better solution for this.

CreateMutex?

[ARM505]

It's a problem of Windows, it should delete the lockfile when the process exits.

But in such case it seems not to.

Please, delete the file C:\Users\<YOU>\Saved Games\DCS\autoupdate.lock

 

I'll think about a better solution for this.

 

+1000 internet points to you, that it's. Funnily enough, I deleted the 'autoupdate.cache' file thats in the same folder, but didn't try that one.

 

Anyway, that was fast and sorted the problem out, thanks a lot.

[c0ff]

CreateMutex?

 

Mutexes (or it's "mutices"?) have their own share of problems: http://vermiculture.blogspot.ru/2010/05/closehandle-vs-releasemutex.html

And from CreateMutex MSDN page: "Alternatively, you can use a file for this purpose. To limit your application to one instance per user, create a locked file in the user's profile directory."

Edited November 20, 2012 by c0ff

[ALDEGA]

From that page, btw: "Alternatively, you can use a file for this purpose. To limit your application to one instance per user, create a locked file in the user's profile directory."

Yep, I saw that too. Locked files aren't deleted in all cases though (system crash, loss of power [as in ARM505's case] ...).

 

What about enumerating processes and looking for other instances of DCS_updater.exe / DCS_update_apply.exe?

[ALDEGA]

Mutexes (or it's "mutices"?) have their own share of problems: http://vermiculture.blogspot.ru/2010/05/closehandle-vs-releasemutex.html

A GUID can be used as mutex name. GUID's are quite ... unique :D

[c0ff]

A GUID can be used as mutex name. GUID's are quite ... unique :D

 

Have you read the link?

Win32 mutexes are "abandoned" when the owning thread exits without releasing them. That is, if the process owning the mutex does not call ReleaseMutex, then nobody will ever own this mutex again - a recipe for a deadlock.

[c0ff]

Anyway, that was fast and sorted the problem out, thanks a lot.

I just found an easy solution for this.

Thanks for your bugreport.

[Scooternutz]

It's a problem of Windows, it should delete the lockfile when the process exits.

But in such case it seems not to.

Please, delete the file C:\Users\<YOU>\Saved Games\DCS\autoupdate.lock

 

I'll think about a better solution for this.

 

Thank you so much!!!!!!!!!!