You might have a package/code that is incompatible with version 8.6.1

Hi Ifrahim,

When you performed the upgrade, did you do any config changes at the same time?

Nik

Hi Nik

I didnt do any config changes. Just like a standard upgrade process, I ran Nuget command and chose to overwrite files (as asked).

I have seen this before, a restart of the website and app pool resolved this for me.

Removing entry for "Umbraco.Core.MainDom.Lock" in web.config seems to fix the issue.

The default MainDom implementation of using a system-wide semaphore lock doesn't natively work on Azure because Azure doesn't respect system-wide semaphore or event wait handles.

Thanks for your help guys.

check that you have these keys in web.config

<add
    key="Umbraco.Core.MainDom.Lock"
    value="SqlMainDomLock" />
<add
    key="Umbraco.Core.LocalTempStorage"
    value="EnvironmentTemp" />
<add
    key="Umbraco.Examine.LuceneDirectoryFactory"
    value="Examine.LuceneEngine.Directories.SyncTempEnvDirectoryFactory, Examine" />

Same issue Boot Failed

<add
    key="Umbraco.Core.MainDom.Lock"
    value="SqlMainDomLock" />

during the upgrade . Wont allow the upgrade to take place . Once you remove this it allows the upgrade to be done . I see this is in the log : Execute "AddMainDomLock" Once the Upgrade of the db is done , Then once the upgrade is completed this can be re-added

<add
    key="Umbraco.Core.MainDom.Lock"
    value="SqlMainDomLock" />

So not sure what is does ? or why is it required ? But if its not added i get error Lock.timeouts in log . So can someone explain what this does ? Andy

The SqlMainDomLock app setting key is need on Azure websites to change how the MainDomLock works. This is because previously a file lock was used (which on a VPS/Shared Hosting is no problem), however the Main Dom Lock behaviour on Azure doesn't work how Main Dom locks were meant to work and as such it would result in "File locked" errors being thrown where Nucache and Examine files couldn't be accessed after a slot swap/restart/auto move.

After a lot of investigation into this bizarre file lock error the cause was finally found and this key was introduced to change the lock from a File Lock to one in SQL.

In "theory" having the key in place before the Upgrade runs shouldn't be an issue, or having it on a non-azure environment, but it appears (based on various reports including this thread) that, because of various restarts, it does cause an issue.

The general advice is don't have the key in place during the upgrade but add it after the upgrade has been completed if you need it.

is working on a reply...