# DD4T publishing error: ComponentPresentationBuilder: exception while deserializing into CP

I have a DD4T page that I'm publishing out of Tridion 2013sp1. I'm using the .net version of DD4T.

My page templates are using this source in the compound template:

 <CompoundTemplate xmlns="http://www.tridion.com/ContentManager/5.3/CompoundTemplate">
<TemplateInvocation>
<TemplateParameters>
<Parameters xmlns="DD4T.Templates.Schemas.DynamicDeliveryParameters">
</Parameters>
</TemplateParameters>
</TemplateInvocation>
<TemplateInvocation>
</TemplateInvocation>
</CompoundTemplate>


My component templates have this:

<CompoundTemplate xmlns="http://www.tridion.com/ContentManager/5.3/CompoundTemplate">
<TemplateInvocation>
<TemplateParameters>
<Parameters xmlns="DD4T.Templates.Schemas.DynamicDeliveryParameters">
</Parameters>
</TemplateParameters>
</TemplateInvocation>
<TemplateInvocation>
</TemplateInvocation>
</CompoundTemplate>


When I publish the page, it fails in the "Committing Deployment" phase with this error message:

Phase: Deployment Commit Phase failed. Commit failed for transaction: tcm:0-1037-66560

I looked in the event logs and I see this:

ComponentPresentationBuilder: exception while deserializing into CP: There is an error in XML document (2, 2).

Component: Templating Errorcode: 0 User: NT AUTHORITY\SYSTEM

I think I understand this to mean that there's an issue with some XML ... somewhere.

I have restarted IIS, Com+, and the Tridion Services. All component templates on the page are DD4T and marked as "publish dynamically".

Could someone share some insights as to what the problem is and how I could fix it?

• Is it JAVA or .NET? And which TBB's are on your Component- and Page Template? – Albert Romkes Nov 7 '14 at 8:27
• I'm using the .net version. I also updated my question with the source from the component templates and page templates. – paceaux Nov 7 '14 at 15:40
• The error in the Eventlog and the error in the 'Committing Deployment' seem unrelated. The error in the Eventlog would prevent you from getting there at all. And this render error is a typical .NET error when one tries to deserialize an object into the 'wrong' format. (and that's what DD4T does here). Is there (somehow) something (a custom C#/DWT TBB) on your CT/PT or in your system that would output invalid DD4T XML? – Albert Romkes Nov 7 '14 at 18:56

There could be some special characters in your Component data which is causing this, to check just capture the package via setting Cleanup=false in cd_deployer_conf.configand validate XML

<Queue>
<Location Path="F:\tridion\environment\incoming" WindowSize="20" Workers="10" Cleanup="false" Interval="2s"/>
</Queue>


@ incoming\Failed folder select and unzip the package and open desired page XmL from Pages folder and valdiate it with XMLSpy, VisualStudio or any XML tool.

• This was helpful for my issue. – Aman Feb 2 '16 at 13:10

The error:

ComponentPresentationBuilder: exception while deserializing into CP: There is an error in XML document (2, 2).

happens on the rendering side of things and in my experience can be one of three things:

1. The generated output of the template is not XML at all, because something was not configured right on the template, eg. the proper DD4T was not added in the right place or order in the template. Generating the final output XML for DD4T usually means that the generate dynamic page / component TBBs have to be put after all other TBBs which also mess with the Output package variable
2. Right before deserializing the generated XML, DD4T actually renders the Component Presentation through an engine.RenderComponentPresentation action. The result of that has to be valid XML.

The simplest solution to this problem is to add a logging TBB to your CT to output the actual content for every step in the TBB. Alternatively, you can add logging to the DD4T TBBs. Then, simply use Template Builder, with the Log Level set to Debug to see where it goes wrong.

The message:

Phase: Deployment Commit Phase failed.

is something entirely different. The best way to solve this is to raise the Log level of the deployer to DEBUG and then by checking the cd_core.log and cd_deployer.log files to see what actually happens.