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

MicroDEM 2011.9.13.6
Log from: 10/31/11 7:23:44 PM
EXE name: C:\microdem\microdem.exe

Windows XP/64 Service Pack 2 5.2 (Build 3790)
Physical Memory: 4.00 Gb
CPU speed: 3.0 Ghz
Processors: 4
Monitors: 2
Screen Resolution, Colors: 32 bits
Monitor 1 Horiz: 1920 Vert: 1200
Monitor 2 Horiz: 1920 Vert: 1200
Computer name: DAD

Debug log: c:\mapdata\temp\MicroDEM_debug_log.txt
Free space for MapData Dir: 78.79 Gb
Windows Temp Directory: c:\mapdata\temp\ Free space: 78.79 Gb

RecordPLSSProblems active in plss_converter
DrainageBasinStats active in Wmaindem
RecordUpdateProblem active in WMainDEM
RecordDEMconvert active in demcnvrt
RecordFileFilterProblems active in PETMAR
RecordTraceCrests active in DEMMapF
RecordLAS_subset active in demhandw
SlicerProblems active in slicer_3d
RecordPointCloudmemory active in point_cloud_memory
RecordLASfiles active in las_lidar
RecordLASfiles active in point_cloud_options
RecordNewDistricts active in DEMredistrict


Last revision 12/22/2017