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.”
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:
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…