Skip to the content

White screen on umbraco backoffice after an upgrade

This week I had an issue where I had upgraded a website from Umbraco 7.7 to 7.14. The bit that really confused me was the site worked perfectly on my local dev enviroment. When I say local dev enviroment I mean my own laptop running in Visual Studio 2019.

I could spin up the site, access all the pages, hit the backoffice with no issues, a pretty straight forward upgrade to be honest.

Then it came to uploading the site in to Microsoft Azure DevOps (used to be Team Foundation Server). Although Visual Studio handles Git commands pretty well, I do like to load up GitKraken and do all my pushing and pulling via that. I just find it more user friendly and since the latest version of GitKraken (version 6) it's much quicker than Visual Studio. Unfortunately, if you are reading this and thinking that you'll give it a go, you do need a Pro account to hook in to Azure DevOps. If you're not using Azure Devops then I'd recommend giving is a go. Anyway, I digress.

With all my code and files pushed to Azure DevOps and a release and deployment pipeline created I could access my site on our internal dev domain but as soon as I hit https://dev.ourdomain.local/umbraco I would just get a white screen! No obvious errors.

I then opened up the browser console and was greeted with this:


I spent a day trying all sorts of things to get it to work.

  1. Deleted the TEMP folder
  2. Cleared my browser cache
  3. Incremented the Client Dependency version number
  4. Manually copied my Umbraco and Umbraco_client folders to the Dev server
  5. Ran nuget updates on the CMS install

Nothing worked!

 I'd asked on the Slack Umbraco community channel and no-one was sure why this was happening.  Eventually I posted on Our and then tweeted asking for help.

As it happened, a contractor who works with us at LEWIS spotted my tweet and dropped me a message at work. Instantly he asked whether I had a maxQueryString value in the web.config. I had no idea so went searching.

Due to some of the clients I work with at LEWIS, we have to implement some pretty strict security policies on the site and this maxQueryString value is one of the settings we've had to change. The value within the web.config was set to 50. Usually, this makes complete sense because why would you want a QueryString any larger than that? Well, the way Umbraco Client Dependency works is it puts a massive QueryString on to the end of the url. The QueryString in question was over 2000 characters in length!

  <requestFiltering allowDoubleEscaping="true">
    <!--allowDoubleEscaping needed to allow +++- in fund sheet file names-->
    <verbs allowUnlisted="true">
      <add verb="OPTIONS" allowed="false" />
    <requestLimits maxUrl="500" maxQueryString="500" maxAllowedContentLength="52428800">
        <add header="Content-type" sizeLimit="100" />

Once I increased the value for maxQueryString to 3000 the backoffice came alive again!

UPDATE - 09/07/2019

Since publishing this blog, I have been given a tip on how to fix this issue just for the back office, this means the vulnerability report will still be happy with a lower maxQueryString for the front end. 

You leave the maxQueryString as it was but then add a new location tag towards the bottom of your web.config file which targets the clientdependency.axd file, after the </runtime> tag.

<location path="clientdependency.axd">
        <requestFiltering allowDoubleEscaping="true">
           <requestLimits maxUrl="500" maxQueryString="3000" maxAllowedContentLength="52428800" />

Photo by Chris Ried on Unsplash

Edit: I've just noticed that the image used in this blog is of Python code - which reminds me, I'll be blogging about my journey into the world of Python very soon!

About the author



Owain is an Umbraco MVP, an Umbraco certified master and works on Umbraco projects on a daily basis. When not coding, he enjoys running, spending time with his wife and building lego! 

He is also a GitKraken ambassador and helps look after the website.

comments powered by Disqus