locked
IE 11 update KB3049563 (replaced KB3038314 from April) breaks SSRS 2008R2 parameters RRS feed

  • Question

  • We're using IE 11 on Windows 7 and Reporting Services 2008R2;  both KB3038314 from last month and the replacement KB3049563 for IE11 released yesterday cause SSRS parameters to run abysmally slowly if one of the parameters presents the user a long pick-list and allow multi-select.

    If the number of values in the param list are decreased (say, less than 500), or if only a single value is allowed to be selected from the list, the param selection behaves normally.  But if there's a long multi-select picklist in the params (delay appears proportional to the number of choices in the list), it takes several minutes for the pick list to become active.  In the meantime, the entire parameter pane is disabled, causing most users to believe the report is frozen and they abort.

    Neither Chrome nor Firefox exhibit this behavior for the same report on the same report server.  Behavior is normal when the report is run in the Visual Studio development environment.  The undesirable behavior is specific to IE 11 (no idea whether earlier versions of IE might be affected).  Removal of the patch on the client workstation restores normal behavior.

    This is a serious problem in our environment, and the problem seems to be under-reported.  Is anyone at Microsoft actively investigating this issue and working on a resolution?

    Thursday, May 14, 2015 2:28 PM

All replies

  • Hi,

    f12>Emulation tab, which emulation mode is the browser running in?

    "Behavior is normal when the report is run in the Visual Studio development environment. " - the VS ide uses IE7 emulation.

    Announcing improvements to enterprise mode site discovery - MSEdge Blog


    Rob^_^

    • Proposed as answer by Deason Wu Tuesday, May 19, 2015 1:23 AM
    Friday, May 15, 2015 12:20 AM
  • Looks like SSRS chooses IE5 emulation.  IE appears to default to 'edge' for most web pages.

    I ran a trace from the point that I opened the report until the report execution was complete.  Parameter selection took about 2 minutes, and I think the big blocks of high CPU utilization were the places where we're waiting for the param list to paint (and collapse again after user selection is complete).  The 'Project Number' param is the long list that drives this behavior.  Actual report execution starts around the 2 minute mark.

    Friday, May 15, 2015 2:43 PM
  • Hi,

    thanks for the info...

    there is a fix for this in this months windows 7 updates. KB3021952 (issued 5-9-15)

    Regards.


    Rob^_^

    Saturday, May 16, 2015 12:32 AM
  • Rob,

    Thanks, but that's applied and doesn't correct the behavior that we've been experiencing.  We opened a case with Microsoft Support, and they confirmed that this is a bug.  Correction isn't anticipated for another month or two.

    In the meantime, we're recommending that affected users use Firefox to run these reports.  Along with Firefox, Chrome also resolves this specific problem, but has other issues with SSRS.

    We'd rather not require users to select different browsers for different apps, but this seems the only workable alternative for the time being.

    Frank

    • Proposed as answer by Deason Wu Thursday, May 28, 2015 1:53 AM
    Wednesday, May 27, 2015 3:19 PM
  • Frank,

    FWIW, it was a relief to me to find your post. We have the same issue right now after this update was pushed out to users in our environment, and I was running out of places to look for an explanation. We see the exact same behavior, and it started roughly the same week KB3049563 was released. We'll be watching closely for the fix ourselves.

    Alex

    Friday, June 12, 2015 7:31 PM
  • Was there ever a fix for this? We're still having this issue.
    Tuesday, February 23, 2016 3:37 PM