Office Web Apps 2013: Excel Web App ran into a problem - not rendering Excel files

Tags: Office Web Apps, WAC Server

Introduction

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.

Symptoms

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.

Resolution

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.

Summary

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…

1 Comment

  • Bigdaddycsi said

    This is a great article. It has saved my butt a couple times. The question is why does this occur? I have a system where it repeatedly must be applied.

Comments have been disabled for this content.

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...