App throws exception that web.config was modified but it's not

Question

I'm facing strange problem on azure app service with my asp.net web forms site.

Got exception:

ConfigurationErrorsExceptionSystem.Configuration.BaseConfigurationRecord in EvaluateOne

The configuration file has been changed by another program. (D:\home\site\wwwroot\web.config)

ConfigurationErrorsException: The configuration file has been changed by another program. (D:\home\site\wwwroot\web.config)
  Module "System.Configuration.BaseConfigurationRecord", line 72, col 0, in EvaluateOne
System.Object EvaluateOne(System.String[], System.Configuration.SectionInput, Boolean, System.Configuration.FactoryRecord, System.Configuration.SectionRecord, System.Object)
  Module "System.Configuration.BaseConfigurationRecord", line 515, col 0, in Evaluate
Boolean Evaluate(System.Configuration.FactoryRecord, System.Configuration.SectionRecord, System.Object, Boolean, Boolean, System.Object ByRef, System.Object ByRef)
  Module "System.Configuration.BaseConfigurationRecord", line 666, col 0, in GetSectionRecursive
Void GetSectionRecursive(System.String, Boolean, Boolean, Boolean, Boolean, System.Object ByRef, System.Object ByRef)
  Module "System.Configuration.BaseConfigurationRecord", line 0, col 0, in GetSection
System.Object GetSection(System.String)
  Module "System.Web.Configuration.RuntimeConfig", line 0, col 0, in GetSectionObject
System.Object GetSectionObject(System.String)
  Module "System.Web.Configuration.RuntimeConfig", line 19, col 0, in GetSection
System.Object GetSection(System.String, System.Type, ResultsIndex)
  Module "System.Web.Configuration.RuntimeConfig", line 0, col 0, in get_Authorization
System.Web.Configuration.AuthorizationSection get_Authorization()
  Module "System.Web.Security.UrlAuthorizationModule", line 153, col 0, in OnEnter
Void OnEnter(System.Object, System.EventArgs)
  Module "System.Web.HttpApplication+SyncEventExecutionStep", line 65, col 0, in System.Web.HttpApplication.IExecutionStep.Execute
Void System.Web.HttpApplication.IExecutionStep.Execute()
  Module "System.Web.HttpApplication", line 21, col 0, in ExecuteStep
System.Exception ExecuteStep(IExecutionStep, Boolean ByRef)

YSOD with Exception is throw after 10-15minutes application deploy.App is not restarting it's just showing YSOD.

But no one edited web.config. Date modified didn't change and nor did the content - compared with win merge and files are identical (one straight after deploy with one that throws exception).

After manually saving web.config (without any changes) file or re deploying app problem is resolved for next 10-15 minutes.

@Edit1

Tried also:

• deploy it as another app service - not working
• run it locally not on azure (working so it seems to be connected with azure app service host).

@Edit2

We got first error in logs from 6.6.2017 and it occured from time to time (i'd say once a week. But it's test environment with very low traffic) till two days ago (27.06.2017). Then It just exploded and happens all the time.

@Edit3

I Downloaded source files from symbol server and debugged it.

Current version returned from method GetStreamVersion is strange. Last write time is 10 minutes before creation time. (maybe it's somehow connected with 10-15 before app crashes?)

Where Last version which is compared with current version is normal. Created before last write.

No idea why creation time is modified. I double checked it on kudu with powershell and everything seems to be ok (values are the same as in lastVersion).

currentVersion:

• CreatedTime: {6/29/2017 10:28:30 AM}
• LastWriteTime: {6/29/2017 10:17:18 AM}

lastVersion:

• CreatedTime: {6/28/2017 8:50:11 AM}
• LastWriteTime: {6/29/2017 10:17:18 AM}

Times taken with kudu for web.config:

• CreationTime : 6/28/2017 8:50:11 AM
• LastWriteTime : 6/29/2017 10:17:18 AM
• LastAccessTime : 6/28/2017 8:50:11 AM

https://github.com/Microsoft/referencesource/blob/master/System.Configuration/System/Configuration/BaseConfigurationRecord.cs#L3988

Answer 1

Received response from the Azure team:

Setting WEBSITE_DYNAMIC_CACHE_FCN_MODE = 1 try it first, as per issue behavior it should address the issue. If this setting does not heal we need to go for WEBSITE_DYNAMIC_CACHE = 0

Side note:

Setting WEBSITE_DYNAMIC_CACHE_FCN_MODE = 1 should not lead to performance impact. Setting WEBSITE_DYNAMIC_CACHE = 0 may slightly impact the performance during initial loads if website content size is huge.

They are still investigating why this problem occurred all the sudden.

Answer 2

The error has come and go for me over the last few days, and I haven't managed to work out what settings or behaviour is causing it. So far;

• Restarting the Web app worked for me on a site with no additional deployment slots configured.
• On a different site, with multiple deployment slots, only a re-deployment seems to work.

I haven't tried either of Jeroen's solutions yet, as I feel more comfortable doing a restart or re-deployment than changing a setting I don't understand.

Answer 3

Please make sure you are using

WEBSITE_DYNAMIC_CACHE = 0

Do not use WEBSITES_DYNAMIC_CACHE = 0 as it won't work.

Answer 4

It looked like @JeroenSlor answer also helped me for some period of time, but after next App deployment it came back again. So mentioned flags looks like had some placebo effect.

If you look at Environment variables set on your WebApp (https://[yourwebapp].scm.azurewebsites.net/Env.cshtml), you will see a list of variables as:

WEBSITE_AUTH_ENABLED = False
WEBSITE_COMPUTE_MODE = Dedicated
WEBSITE_CURRENT_STAMPNAME = <...>
WEBSITE_DYNAMIC_CACHE = 1
WEBSITE_HOME_STAMPNAME = <...>
WEBSITE_HOSTNAME = <...>.azurewebsites.net
WEBSITE_HTTPLOGGING_ENABLED = 0
...and much more

If you will look at this list, you will find there is mentioned WEBSITE_DYNAMIC_CACHE = 1.

But.. please spot the difference - it's WEBSITE_, not WEBSITES_ as suggested previously. So I guess flags should be WEBSITE_DYNAMIC_CACHE_FCN_MODE and WEBSITE_DYNAMIC_CACHE, but it's only my guess, since it's really hard to find any official response about it.

I'm not blaming, just really trying to find the real fix.;)

Answer 5

According to Microsoft Support (we raised a ticket on this in parallel with finding this post) - there is a small error in this - it should be WEBSITE - not WEBSITES.