May 16, 2019

Root Element Missing when connecting to SharePoint online via CSOM/Powershell on windows 10 machine

Hello friends,

Recently i got a situation where suddenly my csom code is stopped working . This CSOM code is to connect a SharePoint online site to fetch data from some list. The same code was running fine earlier.

Issue Description:

When connecting to SharePoint Online site using CSOM or Powershell(using Connect-SPOService command) from Windows 10 machine getting an error "Root Element Missing"

CSOM error : 

At context.ExecuteQuery it thrown "Root Element Missing" with below stack trace




Powershell Error :



Tried in different ways to fix this, like from changing the schema of my app config file, clearing VS cache , running on new version vs 2019 professional , by referring the new CSOM dlls ,clearing Nuget Package cache and finally formatting windows 10. But none of them helped me out.

also

1> The same code worked in other machine
2> The same code working for other online sites from same machine

I was so confused that, whether it is an issue from my machine or the SharePoint site. I noticed that, the stack trace is clearly showing there is an xml notation issue in SharePoint Client libraries.

Finally after troubleshooting for days i found that the issue is with my ISP( Internet Service Provider ) /internet settings.

Resolution :
Changing the DNS settings will resolve this issue. Here are the steps.

Go to Control Panel --> Network and Internet --> Change Adapter Settings --> Select the Network through which you are connecting to Internet



Right click on it and Select Properties. Then select Internet Protocol Version 4 (TCP/IPV4) and select properties



Then select the "Use the following DNS Server Addresses" instead obtain DNS server addresses automatically and give the DNS whatever you want. Here i gave the free DNS address which is offered by google.

Google public DNS addresses : 8.8.8.8 and 8.8.8.4 

Then say OK to apply these changes.

I ran the code again , both csom and powershell worked well without any issues.

References :
https://www.koskila.net/fixing-security-reasons-dtd-prohibited-xml-document-issue/
http://asp.net-hacker.rocks/2016/01/15/XML-parsing-problem-because-of-your-ISP.html
https://www.windowscentral.com/how-change-your-pcs-dns-settings-windows-10

Hope this helps somebody.

Thanks
Purna

9 comments:

  1. Thanks. After updating dns, it works on my window 10.

    ReplyDelete
  2. Late to the party, but I just ran into this issue inside a WPF app. In addition to pointing to Google's DNS addresses, I also had to disable IPv6 on my network connection. Hope this helps someone.

    ReplyDelete
  3. Can someone explain how this fixes it? I need to be able to justify changing the DNS.

    ReplyDelete
    Replies
    1. Hi Andy! I'm not sure if you received an answer yet but here's the answer as best I understand it. I ran into this when troubleshooting an issue with this same issue with a colleague's computer. When we upgraded from an older version of the SharePoint PowerShell module, the Connect-SPOService cmdlet broke. I found Purna's post (coincidentally I've worked with Purna and it was interesting that I ran across his very helpful post here). The newer versions of the SharePoint PowerShell module makes a couple requests during the execution of the Connect-SPOService cmdlet. One of those requests is to http://msoid.[tenantID].onmicrosoft.com/FPUrl.xml (replace [tenantID] with your tenant's ID) and the other to http://msoid.onmicrosoft.com/FPUrl.xml. I do not have any background on the purpose of these two calls but as it turns out and as far as I can tell, these calls fail to connect because the hostname(s) cannot be resolved in DNS. Some ISPs, when they see that you are trying to lookup a hostname that doesn't exist in DNS, instead of returning the error that the DNS lookup failed, will instead return the IP Address of a server on their network which will allow them to provide the user a friendly "not found" error page back to the browser. In this case, referring to the case where it's a PowerShell cmdlet making the request, the DNS lookup failure and/or connection failure is more preferable than the friendly error page. In my colleague's case, the browser loaded a blank page. In cases where the DNS server returns a name resolution error, the PowerShell module sees that the connection failed, it just continues on. But for those ISPs who redirect you to a friendly error page, you can imagine the page returned from the request is not an XML document as the request is expecting. But it tries to parse the XML and fails. Hence the "Root Element Missing" error which is an XML parsing error. If you look at the stacktrace of the error, you can see that it is an XML parsing error. Changing the DNS configuration to point to a DNS server which does not redirect you to a friendly error page, allowing the connection to properly fail, resolves the issue.

      Delete
  4. I can share this... I tested this code on my Parallels VM and I got the Root Element Missing error. I copied the code to my other Windows 10 box that is not a VM and it worked. I checked the DNS setting and it is and was set to "Obtain DNS server address automatically". I'll re-visit my VM but I just wanted to share this. I also want to thank Purna because it gave me clues and I found a way to insert to my SharePoint list. I'm just learning about SharePoint coding so I can't provide much more details.

    ReplyDelete
  5. We've recently had this error on two previously working customers. Your post pointed me in the right direction. In our case, it was caused by the server connecting to SharePoint being unable to resolve msoid.customerdomin.com. One was missing, the other had no entry on their internal DNS. Instead the DNS server returned an IP for msoid.com, which didn't return the expected XML document, and hence the error in your post. Hopefully that might help someone else who has just started seeing this error.

    ReplyDelete
  6. this worked for me like charm. Great post!

    ReplyDelete