Posted by on June 9, 2014

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

Comments

  1. Bill Sabey
    January 29, 2015

    Leave a Reply

    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

    • Kyle
      April 22, 2015

      Leave a Reply

      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. Logan
    June 15, 2017

    Leave a Reply

    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.

    • Kyle
      June 19, 2017

      Leave a Reply

      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!

  1. Unable to Display this Web Part - fkylewright.com - […] Update:Round 2 posted here! […]

Leave a Reply

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

%d bloggers like this: