The program creates a debug log when it runs called "microDEM-64_debug_log.txt",  in a subdirectory under the program directory ("c:\microdem\logs").  The log is closed after each entry, so that a program crash will not lose any debug information except perhaps the very last step. 

You can view the debug log inside the program with the "Help, View debug log" menu choice. You can save this log, or cut and paste it into email or another program. 

The debug log contains information about the build number, hardware, program execution steps, and any problems.  When you have difficulty, and cannot resolve them any other way, submit the debug log as a bug report, along with a description of the problem.

The complete installations of the program have a limited debug log capability built in.  These are carefully designed not to interfere with program execution; there are no logging events inside tight loops, and the exe and debug file sizes should not get very large.  This is designed to generally track your program choices, and to supply data about the most common problems.

Most problems will probably require additional debug information.  We will first try to verify the problem on the development systems, and often we can reproduce the problem and fix it.  Sometimes we cannot, and we must add more debug code and get you to rerun the program to pinpoint the problem.  The goal is to trace program execution module by module, and sometimes almost line by line, to see where things blow up.  Usually this kind of problem is the result of the interaction of several choices you have made, and until we discover the combination of choices responsible we cannot duplicate the problem.  Often your (and our) first guess about the cause of the problem is only half right, and we might require several iterations to fully identify the difficulty.

We have a number of predefined debug packages, which can be inserted into the code immediately.  These will be reported at the end of the debug log as a "RecordXXXXProblems active in CodeModule".  Some of these can degrade system performance, because sometimes the debug code must go inside a tight loop and be executed many times, each with a write to the file.  We strive to remove these debug options as soon as the problem is fixed.  If you think the program is running too slowly, you can:

In rare cases the problem will  be in the initial startup code, and happen before the debug log opens.  In that case we can compile a version of the program that records progress during initialization through a series of on screen messages.  While annoying, this is usually very effective.

Sample Debug Log

9:58:27 PM Opened Debug log: C:\microdem\logs\MicroDEM-64_debug_log.txt
Log from 12/17/18
EXE: C:\microdem\microdem.exe
Build: MicroDEM-64 2018.12.16.60
Compiled: Delphi 10.3 Rio
DB driver: tDBF
INI: C:\Users\NNN\AppData\Roaming\microdem\microdem.ini
9:58:27 PM GetHardware
Windows 10 (Version 10.0, Build 17134, 64-bit Edition)
Total Physical Memory: 16.0 Gb
Intel64 Family 6 Model 60 Stepping 3
CPU Speed: 3392 MHz
Processors: 8
Monitors: 2 Screen Resolution, Colors: 32 bits
Monitor 1: 1920x1200 Left=-1920 top=-103
Monitor 2: 3072x1728 Left=0 top=0
Printer resolution : 4900 x 6400 at 600 dpi
Computer name: MY_COMPUTER

9:58:30 PM GotHardware
9:58:30 PM Debug file opened
9:58:30 PM Start LoadMDdefaults ProgramMode=0
9:58:30 PM End LoadMDdefaults ProgramMode=0
9:58:30 PM No command line parameters
9:58:30 PM Microdem Temp Directory: C:\mapdata\temp\ Free space: 191.4 Gb
9:58:31 PM MDdef.AutoOpen=1 MDdef.ProgramOption=0 GDAL tool dir=C:\OSGeo4W64\bin\
9:58:31 PM MDdef.AutoOpen=1
9:58:37 PM MDdef.AutoOpen completed, Twmdem.FormActivate wsMaximized, width=3088 & height=1704
9:58:37 PM ending FormActivate, first time
9:59:15 PM DoGeoStatAnalysis in


Last revision 1/10/2019