Debugging the Loader
Revision as of 07:01, 19 May 2020 by Sam (talk | contribs) (Created page with "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= Use the Syslog.Server too...")
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
Use the Syslog.Server tool.
Les
To make sure the timings are OK, recompile the Load Status Monitor without the FINAL_RELEASE_BUILD predefined constant.
Execute Les with the --verbose Yes command line option.
This will result is 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.
