Unable to Display this Web Part

In this latest installment of my ongoing series about intermittent SharePoint issues, I have been working with Microsoft Premier support on this web part error for well over a month now (xslttransformtimeout).

The Issue

At random intervals, SharePoint list view web parts (XSLTListView) will display the following error message as soon as the containing page loads:

The end user can reproduce the message by loading the same page in alternate browsers (Firefox, Chrome, Safari, and IE 9 64-bit). Refreshing the page has no impact, nor does closing and restarting the web browser.

Troubleshooting

On the server side of things, ULS entries reveal a key error message:

Error while executing web part: System.InvalidProgramException: Common Language Runtime detected an invalid program.

XSLT Transform Timeout

When Microsoft duplicated our environment in a test lab, they encountered an additional ULS entry related to XSLT transform timeout:

Error while executing web part: System.StackOverflowException: Operation caused a stack overflow.

..but our enterprise XsltTransformTimeOut value was set to 5 (instead of the default 1) a long time ago. We even raised it from 5 to 10 when this web part issue first showed up several months ago. Unfortunately, that seemed to have little or no impact on its sporadic appearances.

XSL Stylesheets

Today we investigated the consistency of the XSL stylesheet files across all the enterprise farm web frontends (WFE) and application servers (I’ll just say that we have a number of these). The specific files in question reside at C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\XSL\. By design, the stylesheet files in this folder should remain consistent across all servers (same timestamp, size, and file contents).

We found 3 stylesheets on a handful of servers that had timestamps different than the out-of-the-box versions (based on the latest patch level applied to our farm). Oddly, though, the internal contents of the stylesheets matched — there was no difference in the sheets, just the varying timestamp.

SharePoint uses the timestamp of the files to validate XSLT rendering on-the-fly, by comparing the timestamp of the compiled XSLT in cache to that of the file on the current WFE. If there is a mismatch, SharePoint will recompile the XSLT and degrade performance. In theory, this mismatch should never occur and may cause odd/unknown behavior when rendering  XSLT.

Corrective Action(s)

So, solution to this possiblecause of our parent issue? Copy the affected stylesheets from a known “valid” server and overwrite the mismatched files so that all the stylesheets across all the farm’s WFEs have matching timestamps, file sizes, and contents. Lastly, perform an IISRESET and wait to see if the issue recurs.

And thus that is where I conclude my coverage of this issue for now. Perhaps I’ve banked adequate karma points to put this problem to bed.. but I am optimistically pessimistic by nature (so stay tuned for round 2!).

Update:Round 2 posted here!