1. Understanding Rotating Logs
2. Main CET Logs - log[0-4].cmtxt
   • How to Diagnose
   • Issues Regarding Updates
   • Other Common Scenarios
     • Graphics Issues
     • Directories / Network Drive issues
3. CETLaunchLogs - launchlog[0-4].cmtxt
4. Update Download Logs - transferlog + CETDownloader.log
5. Catalog Logs - Catalog[0-4].cmtxt
6. Save Logs
7. Local Rendering Logs - CETRenderServer_log[0-4]
8. BITS Logs - BITS_logs[0-4].cmtxt
9. redsdk_error.txt

This guide aims to explain the most common kinds of CET log files, their purpose, how they help in diagnosing issues with CET, where to find them, and when to include them.

Reading log files is our primary way of figuring out what has gone wrong when an end-user has a problem. If you are a user running a CET build, the file contains stack dumps when CET has crashed, or if you are running it from Emacs in developer mode, the file contains all the traces normally shown in the compilation buffer in Emacs.

Understanding Rotating Logs

When it comes to CET log files, usually up to four 5 most recent logs are kept on a rotating basis, with 0 being the most recent/current one and 4 being the oldest. When CET is restarted, the previous log0 is renamed to log1 (and log1 is renamed to log2 and so on so forth). While most of the time relevant records to the issue the user is facing can be found in the most recent log0, sometimes they can appear in log1 and beyond due to restarts. Hence it is important to provide a copy of the log file as soon as the issue occurs.

Unnumbered log files (e.g. log.cmtxt) is the live log file being written during program execution. It's contents are copied to "log0.cmtxt" when a bug report is made, and before that we shift log1 -> log2 and log0 -> log1.

Main CET Logs - log[0-4].cmtxt

These are the main CET logs that record the events occurring in CET at any given time if developers have implemented the relevant traces. Crashes and the occurring locations will also automatically be recorded in the logs.

The log files are usually stored in the CET Data folder (Build) or the write folder (Develop Mode), and up to the 5 most recent logs are kept on a rotating basis, as mentioned above.

The logs are named:

• log.cmtxt
• log0.cmtxt
• log1.cmtxt
• ....  log4.cmtxt

And they are found here in Windows 10:

• C:\Users\user\AppData\Local\CET Data\VersionNumber

These logs are usually structured in such format and hence can be read as such:

1. Booting the environment, loading extensions, actually starting CET Designer. You may also find system specifications information here. Some extensions may do some more work after the first step, e.g. start downloading catalogues or scan for distributed render servers. CET is never really fully idle.
2. Then users may load a drawing or start doing work, which then you might notice some traces that are related to those actions.
3. In the event it crashes, then you will notice a long chain of text starting with a red header, most of the time with the keywords of "access violation" or "stack overflow" or "exception". These are called Stack Traces, and signifies the location of the crash.

How to Diagnose

For example, you may see the trace as:

  access violation: custom/steelcase/steelcaseCore/steelcase/viaPanel/table.cm
  snapping() pos=1245"

When you see an access violation, this probably means the crash occurred in the Steelcase SmartTools: Via Panel extension when the system is trying to do snapping action with the table. An understanding of the code may be required at this point to further diagnose the issue, but this is often a good starting point to direct the issue to relevant parties.

Sometimes, the log may contain multiple access violations, and it is important to determine which one is relevant to the time of occurrence of the issue or based on the order of occurrence.

For example, if a user is complaining that CET crashes after loading a drawing file, then you may try to search for the drawing name in the logfile and observe the first access violation that occurs after the load, instead of other potential red errors that occurred in the same session hours before or after.

Issues Regarding Updates

When it comes to diagnosing update issues, it is very important to first determine the update session ID in which the issue occurred (e.g. bgInstall0008), as well as the time of occurrence.

Look for "Check for updates" in the CET log file, and it should provide something similar to below:

[19:08:51.308] *** Update check status report (automatic update check, report contains limited data)
[19:08:51.308] Updates checked for version: 11-5-54-64-bit, user: John.Doe@configura.com, session id: gfw93ffsfk231dsafda
[19:08:51.308] Number of info file url:s received: 168.
[19:08:51.308] First url is: UpdateCheckEntry(https:\\cdn-eu.configura.com\live\a624d96676facd15b831febf66bdd256\custom.fika.startup.11.5.26.0-win64.cmext)
[19:08:51.308] Received update info for 168 extensions. There were 1 new updates.
[19:08:51.308] New updates:
[19:08:51.308] Configura CET Designer (cet.designer.11.5.26.0-win64.cmext)
[19:08:51.308]
[19:08:51.308] *** End of update check status report ***

This is the part where CET checks for updates and provides information on what files are available on the server, and what CET thinks are new updates.

Shortly after this section, there should be some traces about "Beginning background install for files", and there it will specify which installation ID this update belongs to.

[19:08:51.859] Beginning background install for files: (BgInstallHost)
[19:08:51.859] targetSubWriteDir=c:\Users\johdo\AppData\Local\CET Data\64-bit\#sub\bgInstall0007\

In this example, bgInstall0007 is the installation ID. And hence, any installation issues related to this update must be reported with the corresponding bgInstall0007 logs in the /CET Data/#sub directory. For example, /CET Data/#sub/bgInstall0007 would contain two logs:

• log1.cmtxt - Contains information related to the first stage of installation (Extracting files)
• log0.cmtxt - This would contain information related to the second stage of installation (verification of startup)

Another tip when dealing with installation issues is also to look into Extension startup traces. If you look for "Start Extensions" or "Set damaged", you may also be able to identify precisely which extension has crashed on startup and hence messed with the update/installation.

Also, see the next sections related to Background Install Logs and CETLaunchLogs. Sometimes these three kinds of logs have to be read in conjunction with one another to fully determine the extent of the problem.

Other Common Scenarios

Graphics Issues

Sometimes graphics issues can be caused by GPU configuration (e.g. integrated graphics or outdated drivers), and you may look for information related by searching for "active GPU", and it should show you something like the following, which includes PC specs and other system information:

Directories / Network Drive issues

In cases where the user is complaining that loading the drawing is slow, this might perhaps be the user is loading the drawing from a network drive, and you should be able to see where the user is loading the drawing file from if you search for the drawing file name:

CETLaunchLogs - launchlog[0-4].cmtxt

These logs contain information for the CET Launcher. CET Launcher is used to identify the latest installation of CET (especially the #sub folders) on the machine so the user may always start the latest version.

CET Launcher does the following things on startup, and each step is reflected in the logs:

• Look for the latest CETLauncher
• If there's a newer copy of CETLauncher, start that one instead
• Look for the latest CET installation snapshot
• Copy critical DLL files during startup
• Finally start CET with the latest snapshot and files.

These logs are very useful for diagnosing startup issues, e.g. CET unable to start, or complaining about missing DLLs.

These logs are usually automatically included in error reports.

Update Download Logs - transferlog + CETDownloader.log

These files contain information on the download process of CET updates as well as extension channel files. You may be able to identify which extension file has failed to download, for what reason, and their URLs.

These logs are usually automatically included in error reports.

Catalog Logs - Catalog[0-4].cmtxt

These are catalogue related logs, which documents information related to starting up of catalogue extensions and downloads. These may help if the user is facing issues related to catalogue downloads or permissions.

Automatically included in most error reports.

Here's a separate article going into the details of catalog log files.

Save Logs

Located under /CET Data/tmp/save/, these files are created and records happenings during the save process. Usually automatically removed unless something went wrong badly during the save process.

Usually named as DrawingName_cm_Number.cmlog.tmp. May be useful if CET has trouble saving all drawings.

Local Rendering Logs - CETRenderServer_log[0-4]

Contains information related to the local render server process whenever the user renders something in CET (Photo Lab or Movie Studio). May pinpoint the user's GPU configuration and driver installed, the progress of the render, and failure point if any.

Automatically included in most error reports.

BITS Logs - BITS_logs[0-4].cmtxt

Contains information related to the BITS service interface. Usually not required or useful unless CET is stuck initializing BITS service.

redsdk_error.txt

May contain information related to RED graphics engine crashes or driver errors.