Archives / 2014 / January
  • Office Web Apps 2013: Excel Web App ran into a problem - not rendering Excel files

    Tags: Office Web Apps, WAC Server


    This is a story from the trenches where Excel Web App in Office Web Apps 2013 refuses to render Excel documents, while other Apps such as Word and PowerPoint works just fine. The end-users are met with the generic error message: “We’re sorry. We ran into a problem completing your request.”

    Houston - we got a problem

    The problem is easy to solve but can be somewhat difficult to locate and in this post I will show you how to find the issue and fix it.


    Whenever Office Web Apps 2013 fails to render a document it shows the end-users a generic error message without any details. Fortunately the Office Web Apps Server contains good logging mechanisms and will in most cases give you an idea on where to solve it and in some cases it’s written in clear text.

    This specific issue, for the Excel Web Apps, shows itself in three different places (except for the error message that is shown in the user interface). First of all “normal” sys admins will see a couple of errors in the System Event Log manifesting itself like this:

    System log

    Event Id 5011:

    A process serving application pool 'ExcelServicesEcs' suffered a fatal 
    communication error with the Windows Process Activation Service. 
    The process id was '2168'. The data field contains the error number.

    Event Id 5002:

    Application pool 'ExcelServicesEcs' is being automatically disabled due to a series 
    of failures in the process(es) serving that application pool.


    Pretty nasty messages which does not give you a clue, except that something is horribly wrong. There are also lots of Dr Watson log entries in the Application log which might cause the admin to start looking up the Microsoft support phone number.

    The more “clever” admin then knows that Office Web Apps actually has it’s own log in the Event Viewer. When checking that log messages like the following are shown for the Excel Web App:

    Event Id 2026:

    An internal error occurred.
       at System.Diagnostics.PerformanceCounterLib.CounterExists(String machine, String category, String counter)
       at System.Diagnostics.PerformanceCounter.InitializeImpl()
       at System.Diagnostics.PerformanceCounter..ctor(String categoryName, String counterName, String instanceName, Boolean readOnly)
       at System.Diagnostics.PerformanceCounter..ctor(String categoryName, String counterName, Boolean readOnly)
       at Microsoft.Office.Excel.Server.CalculationServer.ExcelServerApp.Initialize()
       at Microsoft.Internal.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, 
          TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)

    This should actually start to give you an idea – something is wrong with the Performance Counters on this machine. Worst thing to do here is to start fiddling with the registry and try to fix it or start adding users/groups into the performance counter groups.

    The “smartest” Office Web Apps admin then takes a look at the Trace Logs (ULS) (and that admin most likely read my SharePoint post “The Rules of SharePoint Troubleshooting” – if not, he/she should!). This is what will be found:

    Excel Web App                 	Excel Calculation Services    	cg34	Unexpected	Unexpected exception occured 
      while trying to access the performance counters registry key. Exception: System.InvalidOperationException: Category does not 
      exist.     at System.Diagnostics.PerformanceCounterLib.CounterExists(String machine, String category, String counter)     at ...
    Excel Web App                 	Excel Calculation Services    	89rs	Exception	ExcelServerApp..ctor: An unhandled exception 
      occurred during boot. Shutting down the server. System.InvalidOperationException: Category does not exist.     at 
      System.Diagnostics.PerformanceCounterLib.CounterExists(String machine, String category, String counter)     at 
      System.Diagnostics.PerformanceCounter.InitializeImpl()     at ...
    Excel Web App                 	Excel Calculation Services    	89rs	Exception	...atchBlock, FinallyBlock 
      finallyBlock) StackTrace:  at uls.native.dll: (sig=4635455b-a5d6-499c-b7f2-935d1d81cf8f|2|uls.native.pdb, offset=26E32) at 
      uls.native.dll: (offset=1F8A9)	 

    The key thing here is the “Category does not exist” message.

    When the Excel Web App Calculation Services is starting (and the Excel Calc Watchdog) it is trying to read a performance counter. If that performance counter is not found – it will just crash!

    Unfortunately there is no good way to find out which performance counter it is trying to use, except firing up good ole Reflector. Using that tool we can find that it is trying to access an ASP.NET performance counter.


    The fix for the problem is easy – we just need to register/update the performance counters for ASP.NET. This is done using the lodctr.exe tool like this:

    lodctr C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_perf.ini

    Give it a few seconds and then retry to load an Excel file using Office Web Apps and all your users should once again be happy.


    A simple fix to an annoying problem, which could be difficult to locate unless you know where to look (and in this case also have the skillz to read some reflected code).

    This error might not be so common, but it shows the importance of having a correctly installed machine and that you shouldn’t go fiddling with settings or the registry if you’re not really sure on what you’re doing – ok, not even then…

  • SharePoint 2013: How to refresh the Request Digest value in JavaScript

    Tags: SharePoint 2013, JSOM, Security


    SharePoint 2013 (and previous versions) uses a client side “token” to validate posts back to SharePoint to prevent attacks where the user might be tricked into posting data back to the server. This token is known by many names; form digest or message digest or request digest. The token is unique to a user and a site and is only valid for a (configurable) limited time.

    When building Apps or customizations on top of SharePoint, especially using patterns such as Single Page Applications (SPA) or using frameworks such as knockout.js it is very common that you see errors due to that the token is invalidated, which is due to that you have not reloaded the page and the token has timed out. The purpose of this article is to show you how you can refresh this form digest using JavaScript.

    How to use the Request Digest token

    When working with CSOM or REST you need to add the Request Digest token to your request. Well, with CSOM (JSOM) it is done for you under the hood, but when you handcraft your REST queries you need to manually add them. It usually looks something like this:

        url: _spPageContextInfo.siteAbsoluteUrl + "/_api/web/,,,",
        method: "POST",
        headers: { 
            "Accept": "application/json; odata=verbose", 
            "X-RequestDigest": $('#__REQUESTDIGEST').val() 
        success: function (data) {},
        error: function (data, errorCode, errorMessage) {}

    On line #6 we add the “X-RequestDigest” header, with the value of the hidden input field “__REQUESTDIGEST” – which is the form digest value. I will not dig deeper into this since it’s part of basically every SharePoint POST/REST sample on the interwebs.

    But what happens if you’ve built a page (SPA application) where you don’t reload the page and the users work on the page for longer times than the token timeout (default 30 minutes). Then they will get exceptions like these:

    HTTP/1.1 403 FORBIDDEN
    {"error":{"code":"-2130575252, Microsoft.SharePoint.SPException","message":{
    "value":"The security validation for this page is invalid and might be corrupted. 
    Please use your web browser's Back button to try your operation again."}}}

    How to refresh the token

    So how do we get a new and updated token? There are multiple ways to refresh the token, or retrieve a new and updated one. The two most common ways are to either use ye olde web services and call into the /_vti_bin/sites.asmx and use the GetUpdatedFormDigest method. To use this you have to create a SOAP message and then parse the response and retrieve the updated token. You can then either pass that new token for your subsequent requests, or even better update the hidden __REQUESTDIGEST field. The second one is to use the new REST POST endpoint /_api/contextinfo and then parse that response which can be either XML or JSON. This is how to do it the JSON way:

        url: _spPageContextInfo.webAbsoluteUrl + "/_api/contextinfo",
        method: "POST",
        headers: { "Accept": "application/json; odata=verbose"},
        success: function (data) {
        error: function (data, errorCode, errorMessage) {

    It’s also worth noticing that for every REST query SharePoint actually generates a new Form Digest which is sent back as a response header (X-RequestDigest), so you could always read that response header and update the form digest.

    Also, if you’re not using JavaScript but instead building an app using other frameworks, platforms, languages etc – you can always use the two aforementioned methods to update the token. Well, you actually need to do it since you don’t have any hidden input field :)

    How to do it the best and native way

    The drawbacks with the methods above is that you have to either request a new form digest all the time to make sure that it is up to date, or catch the exception and retry your query. And as we all know this will lead to bad performance and/or cluttered JavaScript code (like we don’t have enough of that already!).

    Fortunately there is a native method for refreshing the token built-in to the SharePoint JavaScript libraries. It’s a function called UpdateFormDigest(). It’s defined in INIT.js. The method takes two parameters, first of all the URL to the current site (remember the token is only valid for one site) and secondly it takes an update interval parameter. The update interval value is also already given to us, using a global constant called _spFormDigestRefreshInterval. And this is how you should use the function:

    UpdateFormDigest(_spPageContextInfo.webServerRelativeUrl, _spFormDigestRefreshInterval)
    As you can see, it’s very simple, only use built-in stuff and there’s no magic to it. Under the hood this method uses the /_vti_bin/sites.asmx method and it does it synchronously. This means that all you have to do is copy and paste this line into your own code just before your REST calls. The other smart thing about this method is that is uses the update interval and only updates the form digest when needed – so no extra calls.


    There you have it – no more security validation issues with your SPA applications in SharePoint 2013. All you have to do is copy and paste the line above and stay on the safe side.

  • Presenting at TechX Office 365 January 23-24 2014

    Tags: Conferences, Office 365

    imageThis year has barely started but the conference season is already running at full speed. The first conference for me of this year will be the TechX Office 365, here in Stockholm, Sweden.

    This is a conference organized by Microsoft with sole focus on Office 365. There will be national and international speakers of top class. I will do two presentations, one about Building Apps for SharePoint [Online] 2013 and one about Building Apps for Office  2013.

    The conference is held January 23rd to 24th at the Microsoft offices in Stockholm (Akalla). There are still a few seats left, so hurry over to get your ticket.

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...