Diagnose your Episerver site: find and fix the issues

It’s quite often to see some questions related to issues posted in Episerver World forums. While I (and most of people there) are willing to help, it still takes time for you to write the question and wait for an answer. Sometimes, the answer can be incomplete or even incorrect, because the people answering your question do not have the full context as you do. The truth is, you’re the person who know the most about your site, and you can do something to diagnose it. Those steps below are in the order you should take to diagnose your site:

  • Browser console is your friend. It’s the thing which seemingly ignored the most. When something does not work in Edit UI (CMS) or Catalog UI (Commerce), make sure to open your Browser console and switch to Console tab. If their was a network issue, such as a 500 “Server error” response, make sure to open it. (Right click and choose “Open in a new tab” in Chrome). More often than you might think, it can reveal the underlying problem. If it’s a JavaScript error, how does it look like?
  • Logging is your (another) friend. When something seems to be wrong, check your log file, or turn down your logging level to see if you can see any trace there. In some case, no log found can also be a trace to solve the problem.
  • Does iisreset solve your problem? No I’m not suggesting you to run iisreset every minute on your production site, but it might isolate the problem – if it does, then the problem might relate to cache, or initialization modules. If it does not, well, it can be anything else. But at least it’s not caused by certain things – the key is to narrow down the causes of problem. You can also try to call


    • if the issue seems to related to the “modern” cache – such as ContentProvider. Note that ISynchronizedObjectInstanceCache does not control everything and iisreset is still the more powerful cache-clearing option.

  • Does the problem happens in the reference site (Alloy for CMS or QuickSilver for Commerce) if you deploy it to same environment? This is to ensure if the issue is an implementation problem (your site) or an environment problem (configuration in IIS/SQL Server). Make sure to have same version of Episerver packages (EPiServer.CMS.Core, EPiServer.Commerce.Core, etc) in both your site and the reference site.
  • If the problem only happens in one of your environment, while it works in another one, and you think you have same files and databases – perhaps you should validate that. I would recommend Beyond Compare for comparing the folders, it’s simply the best tool for that:

You can throw almost anything to Beyond Compare and it just handles that – files, folders, even zip files. It’s that good.
For the database, make sure to check if the schema (tables, views, stored procedures) matches. I don’t use any specific tool recently, but from the experience, I think SqlDelta is a good choice.

  • If the problem happens after you upgrade your site, make sure the databases are properly updated (running update-epidatabase in context of front-end site should return no problem at all). In case of Commerce, make sure all migration steps are run successfully before starting your Commerce Manager. The more recent version of Commerce enforces this, but if you’re in older version (Says, 8.x), this should be on the check list.  This is also the reason I always recommend you to upgrade in small steps other than a big one. If something went wrong, it’s much easier to trace the step which cause issue and find a way to solve that.

In the end, if you can’t find the problem, or the solution to the issue, it’s time to ask for help. Of course, I always recommend you to ask in World forums first, and there are several reasons for that:

  • There are Episerver employee frequently available on World, and several of EMVP:s from several timezone there as well. They can answer your question quicker.
  • In most of the cases, the question and the answers will benefit future visitors. They can search the error on the Google and voila, the answer is already there. If you ask someone directly, the information might lost with your mail.

And then there are some tips which might help you to get the questions faster:

  • Specify your version. Episerver frameworks are developing, and developing fast. While the core API:s largely remains the same (trust me, Episerver takes backward compatibility seriously), there are certain parts which have been changed through releases. The behaviors might be changed. The new approaches might be available. The old ways might not be supported anymore, etc.
  • Post the full stack-trace. It’s uncommon to see only the error message is posted. It’s hard to guess what is wrong with only the error message, especially if it’s a generic one. If you have a screenshot, post it as well. If you’ve done any of diagnostic steps, mention them in your post.

In short, provide everything you have (of course, not your username and password, nor your credit card number 🙂 ). If the information you provided was not enough, I or some other people will have to ask for them, then wait for your reply. It can be a next business day, or the day after that. Having all necessary information in one place will cut down that time. Helping the people answering your question is also helping you to get the answer quick. You don’t want to leave the office with a problem unsolved, right? So do I.

World forums are still not your last resort. You’re still always welcome to contact our developer support service for further assistant. Episerver developer supports are specialized in helping you – they might ask for the access to your site and do investigation on that.

Good luck!

Leave a Reply

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