Hi Kristoffer,

We are also have the similar issue would like to see what is causing it.  We are just restarting the site at the moment as we are in dev phase.

Cheers

Hi Murtaza!

is this also in the Dxc/Azure environment? We only have the problem in the Dxc.

/Kristoffer

There are still few modules in EPiServer Admin that can change web.config, e.g. enabling/disabling projects. Is there any activity that you do after deployment on DXC in EPiServer Admin?

Hi Kristoffer,

Yes we have Azure enviornment.

@K Khan, Not sure if anyone is doing that but its intermittent so very hard to figure out what causing it.

Cheers

We are facing the same issue on DXC.

In our case it was always the web.config file that was being changed by another program.
Although when looking at the timestamp of the file it wasn't changed.

After restarting the site it was down again after 10 minutes.
We disabled the task scheduler which seemed to fix the issue, but is not a solution.

Still looking for the real cause. Any suggestions are welcome.

Cheers,
Mark

Thanks Mark!

Exactlly like us, up and then down again after a while.
How do I disable the task scheduler? It is really anoying this problem!

I have a task at Epi I will let tem know that more than us has this problem. If you find a solution, please let ut know.

/Kristoffer

This error also started appearing for us in Azure after upgrading to one of the most recent releases of EPiServer. 

The error occurs for several config files, and seems random. It often happens when releasing new updates of the site. For us, disabling the task scheduler is not an option.

Hi guys,

FYI we have a ticket open for this issue, and we are currently testing a possible resolution. Stay tuned for results :)

Same issue for us (described here). @Martin, do you have a bug number / url where we can check status?

@Vladimir, I don't have a bug number I'm affraid, but I have asked for this thread to be updated with progess.

Thank you! We're experiencing the problem in 2 azure environments for 1 project, and really curios why other projects are not affected (or when to expect problems there)

@Kristoffer

To disable the task scheduler you can add the following to the episerver applicationsSettings section in your web.config

<episerver>
    <applicationSettings enableScheduler="false" .....>

This is however not a solution for this problem. For us it was a workaround to keep the site running.
I would suggest waiting for Episerver's solution.

Hi Martin!

We have a similar issue. I reported the details here :

http://world.episerver.com/forum/developer-forum/Episerver-Commerce/Thread-Container/2017/6/cmsmembershipproviders-throwing-error-in-windows-eventlog/?pageIndex=1#reply

I came across this article https://dzone.com/articles/stronger-password-hashing-net that talks about Password hashing causing the issue. And also increase in CPU utilization. We do see a high CPU utilization after this error is encountered.

We are using "HMACSHA512" hashalgorithm. Do you see any problem in using this hashing with CMSMembershipProvider?

Hi, we're experiencing the same problem on our Azure environment: after restarting the Azure app service or after a new deploy, the site works for about 10 minutes, and then it throws this "The configuration file has been changed by another program" error. 

Is there a solution? 

So I got this from Episerver as a workaround:

The issue happens due to an application setting in Azure. Not only EPiServer based sites but also Sitecore based sites are facing the same issue.
A Microsoft support ticket has been created and we'll inform you if there's any update. 
For now please try adding an app settings WEBSITE_DYNAMIC_CACHE and set its value of 0. Please let us know if your sites still encounter this problem.

So I did that and it look like it works for us. Hopefully there will be a Microsoft fix very soon!

/Kristoffer

@sapna I can't see any problems using that particular hash algorithm with the SQL Membership provider, that logic is all handled by system.web. I can't say at this point if the CPU load of one hash algorithm would provoke this issue more than others. Regardless, I think the underlying problem will be resolved soon.

@Kristoffer, @Martin

Thanks for the workaround, unfortunately it doesn't work for us. How it is now:

Octopus deploys a package to an azure (not DXC) site, it works for some time (5-10 minutes), and then goes down. Restarting web app from the azure portal fixes the problem. 

We have

<add key="WEBSITE_DYNAMIC_CACHE" value="0" />

in our appSettings, but still see the following in the EPiServerErrors.log: 

2017-07-05 12:11:17,873 [76] ERROR EPiServer.DataAbstraction.RuntimeModel.Internal.ContentTypeModelRegister: Detected change of type on property FocusedArticleLink on ListPage. Converting existing content of type EPiServer.Core.PropertyPageReference to new backing type EPiServer.Core.PropertyContentReference is not possible without loss of data. No change is commited.
2017-07-05 12:54:32,372 [42] ERROR EPiServer.Global: 1.2.5 Unhandled exception in ASP.NET
System.Configuration.ConfigurationErrorsException: The configuration file has been changed by another program. (D:\home\site\wwwroot\web.config)
   at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult)
   at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   at System.Web.Configuration.RuntimeConfig.GetSectionObject(String sectionName)
   at System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)
   at System.Web.Configuration.RuntimeConfig.get_Authorization()
   at System.Web.Security.UrlAuthorizationModule.CheckUrlAccessForPrincipal(String virtualPath, IPrincipal user, String verb)
   at EPiServer.Security.Internal.PathAccessChecker.HasPathAccess(String path, IPrincipal principal)
   at EPiServer.Web.Internal.DefaultDisplayChannelService.<>c.<.ctor>b__3_0(IPrincipal p)
   at EPiServer.Web.Internal.DefaultDisplayChannelService.GetActiveChannels(HttpContextBase context)
   at EPiServer.Web.Internal.TemplateResolverImplementation.ResolveCore(HttpContextBase httpContext, ContentType contentType, Type itemType, Object itemToRender, TemplateTypeCategories category, String tag)
   at EPiServer.Web.TemplateResolver.Resolve(HttpContextBase httpContext, Object itemToRender, TemplateTypeCategories templateTypeCategory, ContextMode contextMode)
   at EPiServer.Web.Mvc.Internal.ExistingActionRouteConstraint.Match(Route route, SegmentContext routingContext, String parameterName)
   at EPiServer.Web.Routing.Internal.DefaultContentRoute.MatchConstraints(SegmentContext segmentContext, HttpContextBase context)
   at EPiServer.Web.Routing.Internal.DefaultContentRoute.GetRouteData(HttpContextBase httpContext)
   at System.Web.Routing.RouteCollection.GetRouteData(HttpContextBase httpContext)
   at EPiServer.Web.Routing.RouteCollectionExtensions.HandleRouteData(RouteCollection routes, HttpContextBase context)
   at EPiServer.Global.DefaultDocumentHandling(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
System.Configuration.ConfigurationErrorsException: The configuration file has been changed by another program. (D:\home\site\wwwroot\web.config)
   at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult)
   at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
   at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
   at System.Web.Configuration.RuntimeConfig.GetSectionObject(String sectionName)
   at System.Web.Configuration.RuntimeConfig.GetSection(String sectionName, Type type, ResultsIndex index)
   at System.Web.Configuration.RuntimeConfig.get_Authorization()
   at System.Web.Security.UrlAuthorizationModule.CheckUrlAccessForPrincipal(String virtualPath, IPrincipal user, String verb)
   at EPiServer.Security.Internal.PathAccessChecker.HasPathAccess(String path, IPrincipal principal)
   at EPiServer.Web.Internal.DefaultDisplayChannelService.<>c.<.ctor>b__3_0(IPrincipal p)
   at EPiServer.Web.Internal.DefaultDisplayChannelService.GetActiveChannels(HttpContextBase context)
   at EPiServer.Web.Internal.TemplateResolverImplementation.ResolveCore(HttpContextBase httpContext, ContentType contentType, Type itemType, Object itemToRender, TemplateTypeCategories category, String tag)
   at EPiServer.Web.TemplateResolver.Resolve(HttpContextBase httpContext, Object itemToRender, TemplateTypeCategories templateTypeCategory, ContextMode contextMode)
   at EPiServer.Web.Mvc.Internal.ExistingActionRouteConstraint.Match(Route route, SegmentContext routingContext, String parameterName)
   at EPiServer.Web.Routing.Internal.DefaultContentRoute.MatchConstraints(SegmentContext segmentContext, HttpContextBase context)
   at EPiServer.Web.Routing.Internal.DefaultContentRoute.GetRouteData(HttpContextBase httpContext)
   at System.Web.Routing.RouteCollection.GetRouteData(HttpContextBase httpContext)
   at EPiServer.Web.Routing.RouteCollectionExtensions.HandleRouteData(RouteCollection routes, HttpContextBase context)
   at EPiServer.Global.DefaultDocumentHandling(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Do you have any other ideas/suggestions?

Hi!

We have set WEBSITE_DYNAMIC_CACHE as an Azure variable in Azure environment, not in web.config. Don't know if that makes any difference but that is how we done it and it works just fine.

/Kristoffer

Thank you, @Kristoffer, my bad. Setting it in the azure portal has solved the issue!

Thanks Kristoffer Lindén

Azure uses a feature called dynamic cache that is similar to local cache (https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/app-service/app-service-local-cache.md) however, instead of caching your entire site on the VM, only the files which are requested, at least once, get cached.

Setting WEBSITE_DYNAMIC_CACHE to 0 disables this type of caching, enabeling the site can re-load the latest version of a cache file, if it needs to

Hello,

I had the same problems with forms.config.

Disabling the cache resolved the issue, bet there is also a 3rd option, which also works for me.

https://github.com/projectkudu/kudu/wiki/Configurable-settings#turning-on-the-dynamic-cache-feature

WEBSITE_DYNAMIC_CACHE=2 -> caches only the metadata.

Kind regards,

bob

New recommendation,

WEBSITE_DYNAMIC_CACHE = 0, so disabled.

Mode 2 solved my issues during deploy (arm template), but I still had issues during horzontal scaling...

Hi Bob,

Thanks for confirming that :)