Trending Issue: HTTP Error 500.19 – “Cannot read configuration file because it exceeds the maximum file size”

- - 30 Comments

After installation of recent updates for SharePoint (SP2016, SP2019, SPSE) users may receive an HTTP 500 error with the following additional details:
“Cannot read configuration file because it exceeds the maximum file size”

Cause

The upgrade operation in SharePoint invoked through the configuration wizard (psconfig.exe or psconfigui.exe) after installing a SharePoint fix adds duplicate “<authorizedType …/>” entries to the web.config file which increases the size of the web.config file with every upgrade.

SharePoint configures IIS to have a limit of 900 KB for web.config files. As soon as the web.config file exceeds this size the problem will occur.

Solution

The underlying problem that causes the duplication is currently under investigation.

As a workaround affected customers can run the PowerShell script create by my colleague Joe Erickson which removes the duplicate entries from the web.config:

https://github.com/joeric2/SharePoint/blob/main/Remove-DuplicateAuthorizedTypeEntryFromWebConfig.ps1

By default the script will only report the duplicates but will not remove them. This allows to quickly verify if the web.config is affected. To remove the duplicates you need to us the “RemoveDuplicates” mode:

Be aware that the script only updates the local web.config. If you have multiple web frontend server you need to run the script on each of them.

30 Comments


    1. I had it happen on my SharePoint Server 2019 environment too.

      Reply

    2. Hi Girish,
      as you can see I tagged this article for SP2016, 2019 and SE.
      This affects all SharePoint Versions.
      Cheers,
      Stefan

      Reply

    3. We already have a closed case by Microsoft on this topic.
      They informed us:

      “A change in the in the product is very unlikely probably impossible, since on Tuesday next week the product goes out of mainstream support.”

      Reply

      1. That would be very unfortunate, since the issue was already present and support was notified before the EOL date. I would find it very strange that issues created in the final patch would not be resolved.

        But lets not jump to conclusions, we’ll see how they handle it. They have to fix the same issue for SE too…

        Reply

  3. I posted about this in two other areas on this site – the issue has been happening on for the last 2~3 (yes, it happened again with KB 5002539 ) patching cycles for SharePoint Server 2019.

    It’s about damn time that that some acknowledgement of the problem (“…currently under investigation.”) and some kind of fix to locate the duplicating and duplicated sections in the web.config has been offered.

    Even the smallest/newest site web.configs will become bloated fat-burgers after a few cycles of updates.

    Reply

  4. Any indication SE is affected?

    Reply

    1. Hi Kurt,
      yes this affects all SharePoint Versions.
      Cheers,
      Stefan

      Reply

  5. Stefan, thank you for this post. My SP2016 farms have this issue, so glad to see it is being investigated. Increased registry size limit after last month’s update, but found out yesterday on Dev that SP Update for Dec reset the size limit :-). I will be running the remove dupes script on both farms.
    Thanks again.

    Reply

  6. Hi Stefan,
    The mitigation script was not without further issue on our farm. Automaticly triggered workflows in Nintex were no longer running after applying it. I’ve upped the maximum size via the reg key as described in your article (https://blog.stefan-gossner.com/2022/10/17/trending-issue-cannot-read-configuration-file-because-it-exceeds-the-maximum-file-size-on-sharepoint-server-2013/). That’ll keep us running until the issue is patched. As I understand, until the issue is fixed a patch, I’ll have to reset the setting in registry after every patch, correct?

    Reply

    1. Hi Jenne,
      yes thats the only workaround right now aside of the cleanup script.
      Cheers,
      Stefan

      Reply

    2. That’s correct, you indeed should be aware that updates can reset the register value.

      In our attempt to prevent downtime, we have created a scheduled task which makes sure the value is set to our preference.

      The scheduled task calls a script (1) on startup and – to be sure – every night. Because we run OTP with multiple servers, credentials and update rollout times, we also created a script to create the scheduled task (2).

      (1)

      Check if the registry entry is correct

      $registryPath = “HKLM:\SOFTWARE\Microsoft\InetStp\Configuration”
      $registryName = “MaxWebConfigFileSizeInKB”
      $targetValue = 2304

      $currentValue = Get-ItemProperty -Path $registryPath -Name $registryName | Select-Object -ExpandProperty $registryName

      if ($currentValue -lt $targetValue) {
      # Adjust the registry entry if needed
      Set-ItemProperty -Path $registryPath -Name $registryName -Value $targetValue

      # Wait for 2 minutes to prevent bootloop
      Start-Sleep -Seconds 120

      # Reboot the system
      Restart-Computer -Force

      } else {
      Write-Host “Registry value is already greater than or equal to $targetValue. No action needed.”

      }

      (2)

      #O environment credentials and time
      if ($env:COMPUTERNAME -eq “XXXX”) {
      $User= “XXX\XXXX”
      $Trigger= New-ScheduledTaskTrigger -AtStartup
      $Trigger2= New-ScheduledTaskTrigger -Daily -At 03:30
      #T environment credentials and time
      } elseif ($env:COMPUTERNAME -eq “XXXX” -or $env:COMPUTERNAME -eq “XXXX”) {
      $User= “XXX\XXX”
      $Trigger= New-ScheduledTaskTrigger -AtStartup
      $Trigger2= New-ScheduledTaskTrigger -Daily -At 06:30
      #P environment credentials WFE1 AS1 and time
      } elseif ($env:COMPUTERNAME -eq “XXX” -or $env:COMPUTERNAME -eq “XXX”) {
      $User= “XXX\XXX”
      $Trigger= New-ScheduledTaskTrigger -AtStartup
      $Trigger2= New-ScheduledTaskTrigger -Daily -At 03:30
      #P environment credentials WFE2 AS2 and time
      } elseif ($env:COMPUTERNAME -eq “XXXX” -or $env:COMPUTERNAME -eq “XXXX”) {
      $User= “XXX\XXX”
      $Trigger= New-ScheduledTaskTrigger -AtStartup
      $Trigger2= New-ScheduledTaskTrigger -Daily -At 06:30
      } else {
      Write-Host “Unknown server” -BackgroundColor red
      Write-Host “Break” -BackgroundColor red
      Break
      }

      $Action= New-ScheduledTaskAction -Execute “PowerShell.exe” -Argument ‘-ExecutionPolicy Bypass -file “X:\XXXX_Scheduled\CHECK_REGISTER_MAXWEBCONFIGSIZE.ps1″‘
      $password= Read-Host “Enter Password”

      cls

      Specify what program to run and its parameters

      Register-ScheduledTask -TaskName "CHECK_REGISTER_MAXWEBCONFIGSIZE"
      -Description “Updates a registry entry when it doesn’t meet the criteria” -Trigger $Trigger,$Trigger2
      -User $User -Password $password
      -Action $Action -RunLevel Highest
      -TaskPath “SharePoint” `

      –Force # Specify the name of the tasks

      PS https://blog.stefan-gossner.com/2023/12/12/december-2023-cu-for-sharepoint-server-2019-is-available-for-download/#comment-21586

      Reply

      1. The formatting has been lost while posting the code. That’s actually good; I only share the script for inspiration, if you don’t know how to fix the formatting, it’s probably better you don’t use the script.

        Reply

    3. Hello Jenne,

      Can you please expand on the issues you ran into with automatically triggered workflows for Nintex? We use Nintex extensively in our farms, and obviously want to avoid any issues. I have ran the remove option on our Staging farms, but still need to test workflows.

      Many thanks

      Reply

      1. Hi Scott,
        we followed up with Jenne on this. The problem here was not related to Nintex – there was an incorrect entry in the web.config which caused a problem in the script.
        The script has been updated to take care of this. There should be no issue related to Nintex when using this script.
        Cheers,
        Stefan

        Reply

        1. Nintex becomes very very slow over 300 kb of web.config
          You should always use the script to clean up the web.config

          Reply

  7. I got hit by this defect this round of patches. I cleaned up the web.configs manually, what a pain. Thanks for the PS script. At this point, I’ll just make the registry change after each run of PSConfig till you get this fixed. Hopefully in the next round or two of patches.

    Question… are their other events other than running the PSConfig post patch install that will update the registry value back to 900??

    Reply

  8. What Are the KBs having this Problem -From Post above “I posted about this in two other areas on this site – the issue has been happening on for the last 2~3 (yes, it happened again with
    KB 5002539
    ) patching cycles for SharePoint Server 2019.”
    What are other Kbs having this problem?

    Reply

    1. Hi Chris,
      this issue exists since a long time – even with SP2013 we saw this.
      The more fixes you install the bigger the web.config gets till you hit the threshold.
      Cheers,
      Stefan

      Reply

  9. Thanks, Stefan, for great information always. Here are my experiences, this information may help someone.
    We have two SP 2019 farms that are patched every month. One farm is patched using psconfigGUI.exe and one using psconfig.exe via command line. Information about the two methods can be found here:

    https://blog.stefan-gossner.com/2015/08/20/why-i-prefer-psconfigui-exe-over-psconfig-exe/

    The farm that is patched with the GUI method has had the issue this article describes for the last few months. The farm that is patched via command line has not yet had this issue. Btw…. the farm that has the issue is corrected via the registry method described in a few articles.

    Hope that helps…

    Reply

  10. Thanks, Walter for the information you posted.

    Stefan, can you please comment or confirm that the issue doesn’t occur if patched via the psconfig.exe command-line tool?

    Reply

    1. Hi Wishnu,
      sorry – but I do not have this information.
      Cheers,
      Stefan

      Reply

  11. Just to clarify. The web.config file is also growing when the command line is used to run psconfig.exe, but the growth has not pushed the file over the 900k limit. My last updates using the command (info above) grew the web.config file on app servers I have from 717k to 747k. Eventually with that rate the file may reach 900k, but it will be a while before that happens. On the farm that I used the GUI on to update, the web.config file is now around 950k, forcing me to either clean up duplicate entries or modify the registry. I modified the registry knowing full well I will need to modify the registry next month after the initial updates modify the registry back down to a 900k limit. I always update the Operating Systems on all SharePoint servers before I run SharePoint updates, so I am not sure what modified the registry, the OS updates or the SharePoint binary updates. Next month I will determine what is setting the registry setting back to a limit of 900k. Hope that helps…

    Reply

  12. Hi Walter,

    I would recommend running the duplication script provided. I have ran this on multiple SP farms that we have in our environment, and can now confirm that the average size of all web configs is around the 290 KB size, and that is after applying the latest patch as well.

    I have also found this script useful when it comes to 3rd party install, such as Nintex, which can sometime produce duplicates. It’s a great housekeeping tool

    Reply

  13. Further to my last comment, this also means that there is no requirement to amend the registry setting each time a patch is done.

    Regards

    Reply

  14. Hi , I was getting error while updating KB 5002541 and KB 5002535,
    KB 5002524

    Error type: Config Error Cannot read configuration file because it exceeds the maximum file size (500 internal server error)

    Is this issue fixed?

    Reply

  15. Before we go ahead and patch with the March update for SharePoint Server 2019, can you please confirm that this issue is not going to be fixed in the April 2024 updates?

    Reply

    1. Hi Rob,
      the fix is indeed planned for April 2024 CU.
      Cheers,
      Stefan

      Reply

  16. Thanx Stephan,

    I was very fortunate to come across this blog – saved me tons of time!

    Dave

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.