Does the Core Service create logs on the server where it is hosted? Looking at just the fault exception it's hard to determine the right issue.

For example, below a simple Copy method is giving null exception. _Client is being initialized properly.

RepositoryLocalObjectData objData= _Client.Copy(TCMUriOfPageToCopy, 

As shown in image

enter image description here

  • 1
    No callstack = no answer. Check all the parameters for null Commented Jul 21, 2015 at 15:13
  • Hi Andrey, I verified parameters are identifiable Object in CMS using core service. Added the stack trace snap. Commented Jul 21, 2015 at 15:22
  • Can you check if there's an error in Event viewer of CM server? BTW, it's better to insert text rather than screenshots. Commented Jul 21, 2015 at 15:23
  • I tried to copy the page manually in CMS and getting the same sort of error (80040356) Object reference not set to an instance of an object. Object reference not set to an instance of an object. Object reference not set to an instance of an object. <br/> I will try to copy some different page. Commented Jul 21, 2015 at 15:29
  • 1
    Do you have an event system? Commented Jul 21, 2015 at 15:30

2 Answers 2


To answer your basic question, the logs are created where you want them to be created from the consumer application which is using the CoreService. You can create in log files on the servers where your consumer application is hosted using log4net or you can create eventsource and write it to any event log(Tridion or any other).

Also, if the code also invokes event system or any other Tridion module, then the respective logging will also be available via that system.

Like, if you create a page using CoreService and if you have event system code on page creation, that module will get executed and you will see logs for the same as well (depends on where you are logging from the same) or if you publish a page via CoreService, you will see templating logs as well, just as an example. So, based on your use case, you will have to look for different avenues, but the primary source will be the consumer application as that is where you expect to catch exceptions (if any) or log appropriately to figure out success or failure.


I fully expect there to be a possibility to enable some form of debug logging for the Core Service. I also fully expect this to be an internal use feature only (that is: internal to SDL R&D) as one would only ever need to debug the core service itself if the product was broken.

The fact that the NullPointerException happens on the side of the core service itself doesn't mean the core service is at fault; one of the parameters you passed contains invalid data (not a valid folder tcmuri, not a valid item tcmuri, invalid readoptions) or the core service client itself is no longer in a valid state (it may have been closed by another thread, server application got recycled, etc).

If you really are interested in logs generated by CoreService then there are two types of logging you can enable (they're not enabled by default):

WCF tracing
Uncomment the comment out nodes below <system.diagnostics><sources>; this will cause WCF to dump heaps of information about requests and responses.

The location of the logfile is configured in the <sharedListeners> node in the initializeData property of the child <add> node.

Application logging
Under <loggingConfiguration><specialSources> find the <allEvents> node. Set it's switchValue property to "All". Change the <listener> child node's Name property from "Tridion Event Log" to "Log File"

The default file location for the log file is "C:\Program Files (x86)\Tridion\log\TcmServiceHost.log"; you can change this in the <loggingConfiguration><listeners><add name="Log File"> node by changing the fileName property.

Note that by default the application logs all informational and higher level messages to the event log.

Also note that if you connect to Core Service via HTTP/HTTPS instead of Net.TCP then the configuration file to modify is webservices\web.config as opposed to bin\TcmServiceHost.exe.config as explained in the answer here

  • There's indeed core service logging and it's not internal. Feel free to turn it on in the app.config of you CoreService. It has commented out example, but be aware that it will affect performance a lot. In this case, message from CM event viewer should be enough to see the problem. I would be very surprised if core service would throw null ref, even with completely wrong parameters. Commented Jul 22, 2015 at 7:05
  • My point is: if you think the solution is to debug core service itself than you don't understand the problem well enough (or you should create a ticket for SDL support but that's an edge case). Commented Jul 22, 2015 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.