|

Unable to Display this Web Part – Round 2

As a continuation of my previous post on this issue, further investigation of my XSLTTransformTimeout issues points to farm-level performance issues with the SQL cluster.

Since the last post and the corrective action of copying known “valid” XSL stylesheets to those frontend servers with mismatched files, the web part issue eventually recurred (just as we secretly expected). The next action plan from Microsoft was to increase the XSLTTransformTimeout value from 10 seconds to a whopping 30 seconds!

The farm-wide performance impacts aside, my admins caved and raised the timeout value. For about a week, things seemed to normalize and behave correctly… but then one morning, BAM! The web part issue returned, yet again.

System.InvalidProgramException: Common Language Runtime detected an invalid program.
System.InvalidProgramException: Common Language Runtime detected an invalid program.

So now with the timeout value at 30 seconds, XSL stylesheets consistent and manually verified across all the frontends, and the April 2014 CU applied, we were out of options.

The web part issue now ties directly back to larger performance issues on our farm, as a result of an overloaded SQL cluster. The only long-term resolution is to add additional SQL hardware (cue the bureaucratic red tape!).

Similar Posts

5 Comments

  1. Did this continue or did you find a solution? Have this occuring sporadically on our 2010 foundation with several webparts using xlst.
    thank you. Bill

    1. Hey Bill — so unfortunately the issue has continued even after upgrading the farm. We added a new SQL 2012 cluster and migrated some heavy-use site collections to that new cluster (which in theory would also reduce the load on the existing web app and cluster). The web part issue still crops out routinely, but I’ve trained my end-users to empty their browser caches and restart the browser, to work around it. I also built some new frontend pages that use SPServices to digest and consume data, allowing us to minimize our interaction with the OoTB webparts.

      Not a great solution.. but will work for my purposes until we migrate our business data to custom applications.

  2. Hey Kyle, sorry to comment on such an old post, but did you ever find a resolution to this other than recycling app pools or having users clear caches? We are having this issue in our farm and MS support isn’t helping us much.

    1. Hey Logan — no worries about the comment, and sorry for the delay (you got caught in the spam queue). Beyond what you mentioned, I did not find a better workaround unfortunately. Wherever I could, I ended up using a combination of SPServices and DataTables to build my own replacements for the OotB list webparts.. but there are some use cases where that is not feasible nor maintainable.

      I finally migrated the most extensive business dataset away from SharePoint last year, so this has been less of a concern for me since. It’s a tough situation to manage — best of luck!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.