This article will provide some information on CrashPlan's client log files:

  • Log file locations
  • Short descriptions of important log files
  • How to use logs to pinpoint common issues with the CrashPlan client

Log File Locations

  • Mac: /Library/Logs/CrashPlan
  • Windows Vista/7/8/2008: C:\ProgramData\CrashPlan\log
  • Windows XP/2003: C:\Documents and Settings\All Users\Application Data\CrashPlan\log
  • Linux: /usr/local/crashplan/log
  • Solaris: /opt/sfw/crashplan/log

Note: When you open up your log folder, you may notice multiple copies of each log file, e.g. service.log.0, service.log.1, service.log.2, etc. To keep log file sizes under control, logs "roll over" into a new logfile after they reach a certain size, and older logs are eventually purged.

The lower the number appended to the log name, the newer the log file is. i.e. service.log.0 is your most recent service log.

Log File Descriptions


App.log contains general configuration information about your computer and CrashPlan. Some information you can find in your app.log includes:

  • Operating system version
  • Java version
  • CrashPlan version
  • Licensing overview
  • CrashPlan application settings
  • Backup destination information


Service.log is the main logfile, written by the CrashPlan service as it goes about its business. It logs warnings and exceptions, so it is usually the main logfile used for troubleshooting.


Backup_files.log contains a list of files that CrashPlan has attempted to back up. Information found in backup_files.log includes:

  • Backup success or failure (an "I" means that the file backed up successfully; a "W" means that the file failed to back up)
  • Date and time
  • Destination GUID
  • File name and path
  • File size


Similar to backup_files.log, restore_files.log contains a list of file names and paths for each restore attempt.


History.log mirrors what you would see if you opened the CrashPlan client and clicked on the "History" tab. It contains a high-level overview of what the CrashPlan client has been doing, e.g.

  • Backups starting and stopping
  • File scans starting or stopping
  • Amount of data backed up
  • Backup speed

Troubleshooting the client using logs

To read the files, navigate to the log folder and open the log with a text editor. More advanced users may prefer to use the Command Line or Terminal.

When reading through the logs, you can search for WARN as a starting point.

Common Errors Found in service.log

Below, we'll provide sample log messages to illustrate how some common client issues appear in the logs.

Click on each header below to visit the corresponding Answers From Support article for additional troubleshooting information and fixes.

Unable to connect to the backup engine

If you see "Unable to connect to backup engine" when you try to open the client, and the below error appears in service.log on Windows:

  1. Open services.msc
  2. Open the CrashPlan Backup Service's properties pane
  3. Set the "Startup Type" to "Automatic (delayed start)."
[03.29.13 12:51:12.872 WARN    main                 com.backup42.service.CPService          ] Unexpected IO Exception constructing selector engine - Unable to establish loopback connection, java.lang.RuntimeException: Unexpected IO Exception constructing selector engine - Unable to establish loopback connection


One extremely common reason for "unable to connect to the backup engine" is that the backup engine is running out of memory.

[09.23.12 22:33:02.273 ERROR   QPub-BackupMgr       backup42.service.backup.BackupController] OutOfMemoryError occurred...RESTARTING! message=OutOfMemoryError in BackupQueue!

Client cache issues

Client cache issues can manifest themselves in a few different ways, including: some or all files missing from the Restore tab, stopped backups, incorrect reports, and incorrect file selection size.

[12.21.12 12:12:01.441 WARN    W964862003_BckpSel   m.code42.backup.manifest.ManifestManager] Exception initializing ManifestManager java.lang.IllegalArgumentException: Malformed \uxxxx encoding.; MM[BT 525528945129975616>42: openCount=1, initialized = false, = false, C:\ProgramData\CrashPlan\cache\42]
 [05.11.12 08:45:22.921 WARN    W471137477_ScanWrkr  com.code42.bplusj.BplusTreeIndexFile    ] Exception calling Commit() while closing [email protected][ path = C:\ProgramData\CrashPlan\cache\cpgft1x, keyLength = 20],
[05.16.12 13:03:06.109 INFO    MQ-Peer-1            com.code42.backup.BackupClient          ] BC[525528942342975616>42:: SYNC:: Manifest validation failed.
[05.16.12 13:03:06.110 WARN    MQ-Peer-1            com.code42.backup.BackupClient          ] BC[525528942342975616>42:: SYNC:: Replacing empty local target manifest files with remote server files!!

Real-time file watching fails


[08.30.12 17:13:27.274 WARN W202972748_SpotQW com.code42.os.mac.spotlight.Spotlight ] Exception in getStringFromCFStringRef(): 64bit, e=java.nio.BufferUnderflowException


12.06.10 04:29:40.426 WARNING W449507565_ScanWrkr ] Unable to add watch for path /home/erik/Desktop/, errno: 28

Identifying What Files Are Backed Up Using backup_files.log

Files are failing to back up

Look for a "W" at the beginning of a line to indicate a file which is failing to back up, or search backup_files.log for the string "Unable to backup".

A file that is failing to back up looks like this:

W 01/06/13 12:00PM 42  - C:\Users\John\Blackberry\Backup\BlackBerry Tour 9630-1.ipd

A file backing up successfully will have an "I" at the start of the line:

I 01/06/13 12:00PM 42 50cd0afdb853e65f1f47c31407ce9a4a 0 C:\Users\Jill\Documents\Outlook Files\outlook.pst (200483653) [1,0,200483653,0,0,0,0]
Did this answer your question?