ReportViewer error - There is an error in the XML document. Request failed. RRS feed

  • Question



    I created a .NET C# application that uses the ReportViewer control to display the reports running on our remote SQL Server Database server.

    When I run the application on my development machine, everything works fine.  I am able to view the reports on the remote SQL Server with absolutely no issues.

    Now, when I deployed this application on our Web server, I get the following error:

    There is an error in the XML document (1, 222)
    Request failed.

    Initially, I did not have the ReportViewer DLLs on the web server, so the application would not run on the server.  Then I went ahead and installed the ReportViewer DLLs on the web server by running ReportViewer.exe.  However, the application still did not work.  So I created a Bin folder in my application on the web server and copied the DLLs there and then the application "worked" - I could get to the main login page of the application.  But when I login, it displays the above error message instead of displaying the report.

    Could there be something else that is missing on the web server that I have on my development machine?

    I really cannot figure out why it works perfectly on my development machine and not on the web server.

    I also found this on the Internet, and tried installing it, but it does not seem to apply to us.

    I appreciate any help in this matter.

    Thanks in advance.

    Friday, October 5, 2007 5:13 PM

All replies

  • Hi there,


    >> I also found this... but it does not seem to apply


    Although the specific KB article you found doesn't apply there are lots of reasons why an XML document might be unparseable at runtime, that error message is not at all specific to the reasons given in the KB.


    There might be something specific in your RDL that is screwing up its being de-serialized and used. The first thing I would ordinarily do in this situation is load it into any XML editor or viewer to see if it parses generally (is it well-formed, IOW). If it is well-formed XML, and not corrupted in any way, try validating it against the RDL schema.


    But, given that this works on your local machine, it is also possible that, somehow, some non-printable character is messing up on the server even though it might be well-formed and valid by the schema.  Are the regional defaults different for your local machine and the server, by any chance?


    Also -- I could be reading your message incorrectly -- is this an RDL or an RDLC? If the latter -- re "what could be missing" -- is how have you positioned the RDLC on the server?  Is it built in as a resource or is it an external file? How did you upload it, and how did you configure the reportviewer to "see" the appropriate RDLC?






    Sunday, October 7, 2007 3:34 PM

    Hi Lisa,


    Thanks a lot for your response in regards to this.


    I checked the following:

    - Regional Options and Languages

    On my development machine and the server, they are the same, except on my local machine I have both the options under Supplemental Language Support in the Languages tab checked: "Install files for complex script and right-to-left languages" and "Install files for East-Asian languages".  These two are not checked on the database server.


    - RDL file vaildation

    I installed XML Notepad 2007 on my development machine and opened the RDL files on the database server.  There were no errors in the RDL XML schema.


    - How I set up the report server

    I have RDL files that are located in a folder on the database server.  In the SQL Server Management Studio, I created the Data Source. Under Report Server, I then did a right click on Home -> Import File and imported the RDL files.


    - The .NET application

    I added the ReportViewer control to the web page.  I set the Database server name and the Report Name (for example: /New Accounts).  I then added the following code to the web page (basically using one ReportViewer control to display 4 reports on one web page based on the report selected in the navigation menu).


    Also note that the RptSvrPW has an & in it.  Im the web config file, I am putting &amp;.  I also tried with another login without any "illegal" XML characters, and that also works on my development machine, but not on the database server.  So I can rule this out as a cause.


    Thanks again for looking in to this and I hope I can get this to work soon.


    - Sazkin



    Code Block

    using System;
    using System.Data;
    using System.Configuration;
    using System.Web;
    using System.Web.Security;
    using System.Web.UI;
    using System.Web.UI.WebControls;
    using System.Web.UI.WebControls.WebParts;
    using System.Web.UI.HtmlControls;
    using Microsoft.Reporting.WebForms;
    using System.Net;
    using System.Security.Principal;

    public partial class _Default : System.Web.UI.Page
        protected string strReportName;
        protected void Page_Init(object sender, EventArgs e)
            if (!Logged())
            ReportViewer1.ServerReport.ReportServerCredentials =
                new MyReportServerCredentials();
            ReportViewer1.ServerReport.ReportPath = GetReportPath();        


        protected void Page_Load(object sender, EventArgs e)
            if (!Logged())

        private string GetReportPath()
            strReportName = Request.QueryString["ReportName"];
            if (strReportName == String.Empty || strReportName == null)
                return "/NewPayments";
                return "/" + strReportName;

        private bool Logged()
            bool blnLogged;
            if (Session["LoggedIn"] != null)
            return blnLogged;


    public sealed class MyReportServerCredentials :
        public WindowsIdentity ImpersonationUser
                // Use the default Windows user.  Credentials will be
                // provided by the NetworkCredentials property.
                return null;

        public ICredentials NetworkCredentials
                // Read the user information from the Web.config file. 
                // By reading the information on demand instead of
                // storing it, the credentials will not be stored in
                // session, reducing the vulnerable surface area to the
                // Web.config file, which can be secured with an ACL.

                // User name
                string userName =

                if (string.IsNullOrEmpty(userName))
                    throw new Exception(
                        "Missing user name from web.config file");

                // Password
                string password =

                if (string.IsNullOrEmpty(password))
                    throw new Exception(
                        "Missing password from web.config file");

                // Domain
                //string domain =
                //    ConfigurationManager.AppSettings
                //        ["MyReportViewerDomain"];

                //if (string.IsNullOrEmpty(domain))
                //    throw new Exception(
                //        "Missing domain from web.config file");

                //return new NetworkCredential(userName, password, domain);
                return new NetworkCredential(userName, password);



    Monday, October 8, 2007 5:57 PM
  • Hi there,


    I may be misinterpreting something, but you say:



    Also note that the RptSvrPW has an & in it.  Im the web config file, I am putting &amp;.  I also tried with another login without any "illegal" XML characters, and that also works on my development machine, but not on the database server.  So I can rule this out as a cause.



    Why do you rule this out as a cause if it, also, works on your development server but not on the database server?  Oh I think I see -- you're saying that you changed the database server pw and it made no difference.  Right?


    This is probably a false trail also, but just in case: have you tried using a path/name for the report that does not contain a space in it? I do see "NewPayments" rather than "New Account" in your posted code, so you probably already checked this out.


    I am willing to take a look at your RDL if you want.  I don't need your data.  There really is a good chance that  you have used some character in (say) a textbox name that is okay on your development server because of the extra scripts installed but not okay on the prod server.  I don't know if I will spot it, but it could be something like that and it might work differently on my box.  My e-mail is on my site, which is in my sig here.



    Monday, October 8, 2007 11:57 PM
  • Hi Lisa,

    I really appreciate your help in this matter.  I will email you my RDL files first thing in the morning from work (however, read below about our RDL testing).

    Well, we could not figure this out so we decided to call the paid Microsoft Phone Tech Support today.  After a grueling 5 straight hours on the phone and after various trials/tests, they could not figure out what is causing this error.  They had control of my desktop environment and could see for themselves our entire set up but they had no clue what is causing this error.  They did everything from looking at the report server log files to the IIS log files on my development laptop (where the application works) and on the web server (where the application does not work) and database server (both remote) among other tests.

    We uninstalled the ReportViewer assemblies from the remote web server GAC and reinstalled them, but to no avail. 

    We even went ahead and created simple RDL files and tested those on my development laptop and on the remote web server.

    For example, we created one RDL file that only grabs the FileUploadID column from the FileUpload table.  This is an Integer data type PK column of the table and thus contains no "funny" characters.  The RDL is on the remote database server and it works perfectly on my development laptop when viewed in the application using the ReportViewer control.  View the report using the same application from the remote web server, and it is the exact same error message.

    Then we created a simpler RDL file that has no database connection, but just a textbox with some text in it.  Again, the results were the same.  So, now we are stumped as to what is causing this XML error message. 

    Also, on the remote web server, when we view the reports directly in the browser, the reports show up properly on the web server. That is: http://<DB Server IP address>/<Report Server Name>/ or$DBServerName/

    From the above test, it seems to be a ReportViewer control issue, but we are not quite sure yet.

    One other thing we noticed that was different on my development laptop and the web server was: my laptop (Win XP Pro, which has VS 2005 installed) has 6 ReportServer related assemblies in the GAC.  The ReportViewer.exe that installs the ReportViewer assemblies on the web server installs only 4 of these assemblies in the GAC.  The assemblies it does not install are:
    - Microsoft.ReportViewer.Design
    - Microsoft.ReportViewer.WebDesign

    The tech support personnel said these were not required in a production environment, since these assemblies are used in design time in the VS IDE.

    Finally, MSFT tech personnel have suggested one option for now:
    - Install VS 2005 on the web server.  Create the same application from scratch (no copy-paste) there itself - so the regional settings are the ones that are on the web server.  Deploy and test the application to see if it works.

    The other thing I am going to do is deploy this application on another web server in our data center and see if it works from there. 

    I will be in touch with MSFT tech personnel these next few days. 

    Once again, thanks for looking in to this.


    von Sazkin

    Tuesday, October 9, 2007 6:56 AM
  • hi there,


    [I have put some numbers next to paragraphs representing questions to answer  or actions to take -- as opposed to general comments of various types]


    From what you say I'm pretty sure that I won't see the error in your RDL. 


    1) That being said, I work with slightly different tools than MS support and sometimes see XML-related stuff that they would not -- so I'd still like to see it <s>. There is a slight chance that I might see something by looking at the file at a lower level.


    Although I understand why you think it is a ReportViewer control issue, I don't think this is the most likely suspect.  I think there is a better chance that some XML-relevant libraries in the "wider" .NET framework world, which are being leveraged by these report-centric components, are involved.


    2) Have you checked to see which versions of the .NET framework are installed on each machine (not just if they each have a particular one, but also if one box also has earlier versions while the other does not)?  You probably have -- I can't believe they wouldn't have asked this -- but just in case. 


    3) Even if they are both exactly the same, II would want to know exactly which versions of .NET framework are installed in each case, and also which version is specified for your web application, because the latter might be critical.  Is it the same as the one as in use by Report Manager?


    4) Also -- you may have said this previously, if so I apologize -- what is the OS of the web server?


    It is really possible that the regional settings *are* involved, but I am sort-of shocked that they would suggest installing VS 2005 on the web server to resolve this. 


    OTOH, what you have planned to do -- install on a different web server -- makes good sense to me. 


    5) The items above -- which .NET framework version is in place on the box, which is used by the web app, regional settings of the new server  -- would still be critical in each case, so please note each one of these things as part of your new install for a good test. <s>


    6) One more thing: do you know much about the history of this web server, how IIS and .NET framework were installed, in what order, etc?


    I wish I could do more to help,




    Tuesday, October 9, 2007 4:19 PM
  • Hi Lisa,


    I have emailed you the RDL files and the information you asked in the above post from my GMail account.  The email title is: Question on MSDN Forums - ReportViewer control. 


    I hope I have given you all the information.  Please let me know if you require any further information.


    Microsoft Tech Support will be contacting me today again.  I know they don't have a clue about this but are going to show me another way to display the reports on the web server (without using the ReportViewer control).  I suppose the same: http://<IP Address>/<ReportServer$ReportServerName>/Pages/... but with added "security"...


    Thanks again for your help.


    von Sazkin

    Wednesday, October 10, 2007 3:51 PM
  • Hi there,


    There are certainly other ways to display the reports without using the ReportViewer control .  I think they are probably going to show you requesting the report through a SOAP or URL Access call and then re-displaying it.


    This would definitely be an option for you but does not tell us why your current methods don't work.


    I have received your files and information.  I will look at the files tonight, but want to clarify a few points from your message:


    1) You say this: >>The application was built using .NET framework 2.0 (MS Visual Studio 2005 Professional Edition).  No third party components/controls are used in this application.


    ... But I need to be sure not of how it was built but how it is configured in IIS: when you look in the IIS ASP.NET configuration information on both your laptop and the servers, which .NET version is the *application* actually set to use? 


    2) The  reason I asked what order things were installed in (in your case, IIS first and .NET second) is that sometimes the libraries that become default are different depending on which order they are installed.  FWIW the order in which you think they were installed on this server box is *not* optimal, in my experience, and sometimes results in a lot of cleanup before things will work at all.  See below.


    3) Have we absolutely ascertained, in your case, that only *one* set of ReportViewer dlls is on each box and that they are exactly the same version? (because there were patches for these guys as well, and the redist patches came out *later* than the dev versions.


    4) I am also a little concerned that it looks like your various machines have different levels of patches for the XML components. Believe if or not this is significant.  Please read this and notice that there is a patch discussed about halfway down in the comments.  Because this thread is pretty old I have no idea whether your servers could still have the bug, but it bothers me that your machines appear to have different KBs applied to the different machines.  See below for some tests.


    5) By reading this particular set of messages, you may also understand why I want to look at your RDLs directly, because how they were encoded and serialized might make a difference. I may or may not be able to "see" this.


    OK. Here's a suggestion that should be pretty painless for testing further on your boxes:


    It is sometimes possible to write a little ASPX page to test what the server sees and what is default.  I don't know if this will help us in this case if the problem is in the way the ReportViewer control references the classes.


    Here is a really simple example I put together to show you what I mean.  Notice that I am testing both the MSXML COM libraries, I grabbed some very old code for this (which should be obvious from the ON ERROR handling!), and then I added some info about one dot net class  -- you can pick whatever things you want to instance and check out what the application "thinks". 


    You can do this, on the server, within the context of the ReportManager application and your own web app.  Do you get different results on your dev box and the servers? 


    Code Block


    <%@ Page Language="VB" AutoEventWireup="false"  %>

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"


    <html xmlns="" >
    <head runat="server">
        <title>Untitled Page</title>

    On Error Resume Next

       Dim oXML As Object
       oXML = Server.CreateObject("Microsoft.FreeThreadedXMLDOM")
       If Err.Number <> 0 Then
          Response.Write("MSXML 2.x or above is not available.")
          Response.Write("MSXML 2.x or above is available.<BR>")
          oXML = Server.CreateObject("MSXML2.DOMDocument.3.0")
          If Err.Number <> 0 Then
             Response.Write("MSXML 3.x or above is not available." & _
                              " (" & Err.Source & " " & Err.Description & ")")
             Response.Write("MSXML 3.x or above is available.<BR>")
             oXML = Server.CreateObject("Microsoft.XMLDOM")
             oxml.setProperty ("ServerHTTPRequest", true )
             If Err.Number <> 0 Then
                Response.Write ("MSXML 3 or above is not default." & _
                               " (" & Err.Source & " " & Err.Description & ")" )
                Response.Write( "MSXML 3 or above is default.")
             End If
          End If
       End If
       oXML = Nothing
       Dim oXMLDotNet As New System.Xml.XmlDocument, oType As System.Type
       oType = oXMLDotNet.GetType()
       Response.Write("<br/><br/>DotNet xmlDocument: <br/>" & _

       Response.Write(oType.Module.FullyQualifiedName & "<br/>")
       Response.Write(oType.Module.Assembly.ImageRuntimeVersion & "<br/>")
       oType = Nothing
       oXMLDotNet = Nothing







    Again, we don't know right off the bat what classes to test, which should be classes ReportViewer is using internally. But we can add code to this simple test page to try to load your RDLs, using different .NET classes, and see what happens. 


    Also there might be something in the callstack of your errrors that might give us ideas of exactly what classes to try.  I'm going to guess that we try XMLReader, but even if we get that right it might be something about how the instance is created (XmlReaderSettings) -- so who knows. 


    This is how I tend to try to track this type of cr*p down, at any rate. Maybe reading it will give you, or somebody else, some ideas...




    Wednesday, October 10, 2007 6:12 PM
  • Hi again,


    I have gone as far as I could tonight, and probably won't have much time tomorrow.  Here are some observations in addition to the stuff I have already written in my last message about testing XML classes, now that I've looked at the RDLs:


    * -- they are very definitely marked UTF-8 explicitly, in case this turns out to make any difference.  I saw nothing that indicated font-related issues.


    * -- the only weird thing I noticed in your RDLs was that the second "simple" one you sent (Report2, I think it was called) was clearly mal-formed.  It had the following contents, which are *not* normal.  This is the whole thing.  Notice two sets of "InitialDimensions", which can't be right, and there's nothing else:


    Code Block

    <?xml version="1.0" encoding="utf-8"?>
    <Report xmlns="" xmlns:rd="">



    * -- Your Report1 (the other "simple" one) had a data source that looked like it was pulling file names, which means there *might* be a chance of characters that messed up a server that didn't have extended charsets installed.


    * -- I concentrated on CreditAccounts in my tests. Obviously I had to fake your data -- which may be significant to the outcome. See below.


    * --  I had no trouble putting it on two different web servers and no trouble, in two different environments invoking it through ReportViewer.ServerReport.  I made sure that in one case there was a space in the path, etc.


    * -- I used integrated auth, which might also be significant, who knows.


    * -- I was using a *very* simple ASPX page.  I forgot to ask you about this before, but make sure you're not using a master page or anything else when you're testing this stuff, along with verifying the version of the .NET framework assigned to your specific web app.


    Mine was literally this simple:


    Code Block


    <%@ Page AutoEventWireup="false" %><%@ Register TagPrefix="rsweb" Namespace="Microsoft.Reporting.WebForms" Assembly="Microsoft.ReportViewer.WebForms, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" %>
       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

    <html xmlns="" >
    <head runat="server">
        <title>Untitled Page</title>
        <form id="form1" runat="server">
            <rsweb:reportviewer id="ReportViewer1" runat="server" font-names="Verdana"
                font-size="8pt" height="400px" processingmode="Remote" width="400px">
    <ServerReport ReportPath="/Report Project1/CreditAccounts"></ServerReport>




    * -- All three of your "real" reports used a query-driven parameter that looked like this:


    select dbo.F_GetOrgName(@OrgID) as BranchName


    ... it is possible that the user coming in to fetch this parameter doesn't have rights to the udf on the other two servers, I suppose.


    It is also possible that the reasons I didn't have any problems is that I faked yoru data.  Since you're supplying a parameter list as a drop down that comes from data, your version might well have high-ascii characters that the other two servers, without the extended character sets you've installed on yours, aren't interpreting correctly. 


    Although we know that it works okay in Report Manager with your data, again (see that thread I pointed you to last time) there could be a reader *class* that isn't reading this data properly at some point where the viewer is trying to render those params. 


    * -- I'd be happy to compare notes on any specific aspects of installation on the errant servers with mine if you like.  Of particular interest might be: what's on the Application page of the ASP.NET configuration applet, specifically with regard to encoding and globalization settings?  How does this relate to the way ReportManager and ReportServer webapps are set up?


    HTH, bye for now,





    Thursday, October 11, 2007 2:49 AM
  • Hi Lisa,


    I very much appreciate your help in this matter.  I have emailed you at your email address instead of here for obvious reasons.


    Once again, thanks.


    von Sazkin

    Thursday, October 11, 2007 2:54 AM