Issue Reporting:

When reporting issues to the FM2 newsgroups, please refrain from using general subjects.

Example: Another trap with the latest source code.

Use a more descriptive subject such as

Drive bar trap at fm3dll 0002:00046a01 with changeset 883.

This tells us where the exception occurred and for which current source the exception occurred. It gives us a basic idea of what the code was doing at the time of the trap. It is also not an inordinately long subject line.

Next, give a detailed description of what you were doing at the time of the trap. Don't give a general description. Tell the group what you were doing step by step at the time of the trap. Is the trap reproducable?

---

Capturing (Logging) Error Messages:

Fm3.exe is crashing for no apparent reason. You may be asked to capture a log and post its contents to the FM2 newsgroups. FM/2 writes all popup error messages stderr.

Logging from Command Prompt:

1. From a command prompt, change to your FM2 directory. Normally, this would be

cd <drive>:\tools\fm2

2. Execute fm3.exe from the command line with

fm3 2>&1 >fm3.log

or

fm3 2>&1 | tee fm2.log

Logging from the FM/2 Program Object:

The default FM/2 program object propterties will have to be modified.

1. Right click on the FM/2 program object and select properties.

2. Under the Program tab, replace the "Path and file name"

<drive>:\tools\fm2\fm3.exe

with an

*

Note: Replace <drive> with the drive letter of the drive FM/2 is installed on.

3. Change the Parameters field from

%*

to

<drive>:\tools\fm2\fm3.exe /BC 2>>STDERR.LOG

Note: Replace <drive> with the drive letter of the drive FM/2 is installed on.

4. Close Properties and double click program object to execute.

When FM/2 terminates for no apparent reason, locate the fm3.log file in the fm2 directory. Copy the contents to the fm2user newsgroup.

---

Creating Dump Files:

Based on what the log file indicates, you may be asked to do a dump file.

1. Locate the fm2dump.cmd file in the fm2 directory.

2. With a text editor, find and edit the following lines.

Edit this to point to existing directory on drive with sufficient free space

set D=U:\Dump

Edit this to name process to be dumped - .exe is optional

set P=fm3

3. Save the modified fm2dump.cmd.

4. Start the dump facility (fm2dump.cmd) from within the fm2 directory at command prompt.

5. Start FM/2.

6. When problem (issue) occurs, change to the directory where the dump file is stored.

7. Zip up the dump file along with all the *.map files from the sources used to build FM2 and the rest of it files.

1. Name the zip file so it is easy to know what the zip contains and who it is from.

example: dwg_fm2dump_drivebar_2007_09_10.zip

This example tells us who is is from, that is is a FM/2 dump file, where the problem occurred, and the date of the dump file.

8. Upload the zip file to Netlabs Incoming.

[ftp:\\ftp.netlabs.org\incoming]

9. Notify the development group after the file has been uploaded to Netlabs Incoming.

---

Debugging:

It is best to build FM/2 with the debug files and then install for debugging. Refer to Building FileManager/2 (FM/2)
on building a FM/2 debugged version. Then

1. Open to a full screen session (command prompt) in the directory where fm3.exe is to be run from.

2. Start the Open Watcom debugger with

wd fm3.exe

3. From the modules window on the lower right, select the file that needs to be debugged.

Example: Defview

Note: The modules window will not list Defview or the file one needs to debug as one of its choices if the needed file was not built with debug info.

This can be easily fixed by switching the Fm2\dll directory and running the following from a command prompt.

        set debug=1
	wmake -a defview.obj
	wmake

Then start with step 1 again.

4. RMB and select Source.

5. From the menu, select Action -> Show -> Line and enter the a line number to begin the debug operation.

6. Continue to select Run -> Run. The debugger should continue to the next breakpoint.

7. Each time you get a breakpoint, note where the code stopped and tell the debugger to run. Eventually, you will get an exception.

---

How can I get better scan performance with Netdrive drives?

Netdrive drives tend to be slow particularly on initial scan. If you avoid "root directory" mount points the scan speed is greatly enhanced. This can be forced by a setting in the Netdrive configuration file. The drive information scan can also be very slow. You can fix the speed by configuring netdrive to return "fake" information about the drive. The down side is the drive size free space etc are not the actual sizes. This is also a setting in the Netdrive configuration file.