Why “Package Load error 0xC0010014 in CPackage::LoadFromXML” error appears while trying to run an SSIS Package ?

As you know an SSIS package is an XML content regardless if you’re storing your SSIS package in file system (as a .dtsx file) or storing your SSIS package in MSDB (then your XML content inserted into sysdtspackages or sysdtspackages90 tables in MSDB)

Of course this XML content has its own schema and the SSIS Runtime and BIDS (Business Intelligence Development Studio) needs to parse the content of the XML.

“Package Load error 0xC0010014 in CPackage::LoadFromXML” error message is a generic error message when SSIS Runtime tried to parse the package. There could be various reasons for you to get this error message. But all of them refers to something wrong in your SSIS XML content.

The first thing that I will suggest you to overcome this issue will be minimizing the package step-by-step. I would suggest starting to remove the 3rd party components in the first hand.

Here’s a story about this…

One of our customers had experienced this issue. The environment was SQL Server 2008 x64 on a Win2k8 R2 x64 platform. The very first thing that I noticed was a 3rd party connection manager. It was a connection manager helping customer to connect to Oracle. Though we have the needed components coming as out-of-box in SSIS to connect Oracle, customer was preferring this 3rd party connection manager.

The thing that I noticed was the 3rd party connection manager was 32bit though the environment is 64bit. As the BIDS works as 32bit and recognizes 32bit connection manager easily, they would design their packages but it was failing when they tried to run. The problem here was simple their SSIS project was trying to run the package as 64bit which is by default for a 64bit OS. As the 64bit SSIS runtime cannot see 32bit components (including this 3rd party connection manager), it was failing with this CPackage:LoadXML error. This type of cryptic error message is very normal as this is a 3rd party component and the SSIS runtime does not aware of those components there in your package.

The solution for this scenario was asking customer change the debug option “Run64BitRuntime” from True to False as shown in the screenshot below :


With this “Run64BitRuntime=False” setting, all works as in 32bit mode.

Another possibility for this error to be appear could be using different DateTime values than the current OS regional settings have. Let’s say your current OS shows the datetime as 12/24/2010 but the value in your SSIS package is “24.12.2010” which is a wrong value. Again, to be sure that if that’s the reason you can snip out your SSIS datetime values just for testing purposes.

Comments (11)

  1. Travis says:

    Had exactly this issue with the Oracle Attunity SSIS connector.  Thanks for posting this.

  2. Faruk Celik says:

    Happy to hear that it helped Travis 🙂

  3. Venkatesh says:

    Exact same issue. Very helpful.

    The user had recently lease rolled desktop and had not installed all the software yet. Installed attunity driver on the desktop experienceing the issue. It opened successfully after the installation of attunity driver.


  4. Bernie says:

    Nice post. I have an ancient package using an Oracle connection.  Voila.

  5. Zamir says:

    That was it.  Once I changed the setting of 64-Bit to False it worked.  Thanks for your help.

  6. Ertan says:

    I was using the SharePoint Data source control from Pragmatic Works to get access to Lists on a SharePoint site ie their 'Task Factory' product. Your post from 4 years ago just keeps on giving. Thanks Faruk

  7. Mayara says:

    Thanks a lot

  8. VS2012 expert says:

    Thank you so much for Run64bitRuntime option.

    It resolved my XML error by setting to False.

  9. Ed [Belgium] says:

    You saved my day!

  10. Ed_______ says:

    You saved my day!!

  11. Shri says:

    Thanks for the article. I was able resolve my issue with your solution. Great work!!