Difference between revisions of "Debugging the Loader"
Jump to navigation
Jump to search
(→Syslog) |
(→Les) |
||
| Line 8: | Line 8: | ||
=Les= | =Les= | ||
Execute Les with the <code>--verbose Yes</code> command line option. | Execute Les with the <code>--verbose Yes</code> command line option. | ||
| − | This will result | + | This will result in a large log file in the <code>StatusMonitorDump</code> file in <code>C:\ProgramData\Truxton\Status Monitor Dumps</code> |
=Log Files= | =Log Files= | ||
Revision as of 05:13, 23 August 2020
Debugging the Truxton loader sucks. Most of the time, loads get stuck. When that happens, you must find out what is clogging the pipes.
Syslog
Turn on and use the Syslog.Server tool.
Les
Execute Les with the --verbose Yes command line option.
This will result in a large log file in the StatusMonitorDump file in C:\ProgramData\Truxton\Status Monitor Dumps
Log Files
You can use these log files to help see what happened in the system during a T1 test:
TruxtonRoot\bin\TestingSyslog.txt- This contains all of the messages logged via syslog.C:\ProgramData\Truxton\Status Monitor Dumps\XXX_DebugDump.xml- This contains the current status of all ETLsC:\ProgramData\Truxton\Status Monitor Dumps\StatusMonitorLogXXX.txt- This contains a log of everything Les was thinking.
