ProfitPress Mega CDROM2 Shareware Freeware (MSDOS)(1992)(Eng)

home *** CD-ROM | disk | FTP | other *** search

/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / PROG / MISC / DRFRANK.ZIP / DRFRANK.TXT < prev next >

Wrap

Text File | 1992-01-16 | 33.3 KB | 791 lines

|=============================================================================| | Dr. Frank & Tools | |=============================================================================| PREVIOUS USERS: See the "What's New" and "DFA2" sections for a quick update on what's new and improved. ******** Table of sections ******** Quick Start (For those who can't stand to read the full documentation) Introduction (What is Dr. Frank & Tools) What can Dr. Frank show you??? Preparing your programs for Post-mortem debugging Running Dr. Frank Interpreting the results Post-processing the log file Logical Addresses DRFRANK BUILDSYM TMAPSYM EXEMAP DFA2 EXETDS What's new Support |=============================================================================| | Quick Start ( For those who can't stand to read the full documentation | |=============================================================================| If you can't bear to read the full documentation, here's how to use Dr. Frank. It's assumed you know what you're doing here. If these steps aren't clear, please read the actual documentation below. 1) Make sure you have the correct TOOLHELP.DLL installed, and in your path. 2) Run Windows, and run DRFRANK.EXE. 3) Do whatever makes the UAE occur. 4) Look at the log file (DRFRANK.LOG in the windows directory). 5) Go to the directory where the log file is, and run: "DFA2 DRFRANK.LOG DRFRANK.BIN" 6) Look at the DFA.OUT file. 7) Resolve to read the full documentation, because there's a lot you're missing. |=============================================================================| | Introduction | |=============================================================================| Dr. Frank (DRFRANK.EXE) is a program that will help you perform a post-mortem on your Unrecoverable Application Errors (UAE's) with Microsoft Windows. It is part of a suite of tools (described below) to assist programmers, and was written with the programmer in mind, rather then the non-programmer. When an exception occurs, Dr. Frank will intercept it, and write a file (or 2) to your disk with information helpful to finding the cause of the exception. Since Dr. Frank is oriented towards developers, it writes out a short, concise report by default. If however, you do want more information, there are several .INI file options which allow you to configure the report to your needs. Dr. Frank is similar to DRWATSON, and uses the same TOOLHELP.DLL, which is currently in beta testing. TOOLHELP.DLL is shipped with BC++ 3.0, and is also available on Compuserve. It can be found either with DRWTSN.ZIP or as TLLHLP.ZIP on WINADV. The names and locations may move around, so your best bet is to search across all libraries for TOOLHELP or WATSON. DRWATSON and TOOLHELP.DLL are Microsoft products. There are many features that are not discussed in the general "how-to" sections of this file. If you're so inclined, feel free to read the program reference sections to get a better idea of what Dr. Frank & Tools can do. |=============================================================================| | What can Dr. Frank show you??? | |=============================================================================| The most important feature of Dr. Frank is it's ability to show you the "call stack". The call stack shows you what calls your program was executing when the exception occured. Additionally, if you post-process the log file, you can obtain the names and values of your local and global variables (if you have TD debug information available). To the CPU, the call stack is just a series of addresses. However, with a little help from you, Dr. Frank can give you the names of the functions and procedures associated with the addresses, instead of just a series of addresses. With this information, you can very quickly pinpoint where the program is blowing up. Additionally, Dr. Frank can show you the CPU registers at the time of the exception, as well as a disassembly of the instruction that caused the exception. Dr. Frank can also display information concerning the state of Windows when the exception occurred. This includes things like available memory, which version of Windows, events in the programs message queue, etc... |=============================================================================| | Preparing your programs for Post mortem debugging | |=============================================================================| In order to get function names for the call stack, you need to provide symbolic information to Dr. Frank. Dr. Frank can work without any symbolic information, but you'll find that having symbolic information greatly enhances your ability to pinpoint the problem. There are 2 forms of symbolic information that Dr. Frank & Tools understand: 1) .SYM files. These are used by Dr. Frank at the time of the exception. 2) Turbo Debugger debug information. This is used after after the exception occurs. There are advantages to both: - .SYM files are used directly by Dr. Frank when the exception occurs. Thus, there is no need to run another utility afterwards. - .SYM files can be used by other programs, such as Dr. Watson, the Windows Debug Kernel, WDEB386, etc... - Turbo Debugger debug information contains line number information. In addition to giving you function/procedure names, it can also give you the source file and line number for call stack entries. You will also be able to see the names and values of your programs variables. - Turbo Debugger debug information can "find" static functions that .SYM files might not contain information for. There are utilities in Dr. Frank to create and use both kinds of debug information. ======== Creating .SYM files ======== - For your own programs, you first need to create a .MAP file, and then create a .SYM file from that. If you're using a Borland IDE, you should select the linker options that produces a .MAP file. If you're letting BCC invoke TLINK, use the "-M" option on the BCC command line. If you're invoking TLINK yourself, use the "/m" command line option, and make sure that you're not using "/x" (no map file). If you're using TPCW, use the /GD command line switch. If you're using another compiler, do whatever is necessary to create a .MAP file with Public symbols. Next, if your .MAP file is from a Borland product, use TMAPSYM to create the .SYM file for it. For instance: "TMAPSYM mymodule.map" will create MYMODULE.SYM in the current directory. If you're using another compiler, use MAPSYM, provided with the MS SDK to create the .SYM file. If your using a makefile, you can add TMAPSYM as another rule command after the link. - For programs that you don't have source to, i.e., USER.EXE, GDI.EXE, you can still create .SYM files The easiest way to do this is to use BUILDSYM. To do this, make sure that the programs that come with Dr. Frank are somewhere in your path. Next, go to the directory that contains the file(s) that you want to create .SYM files for, i.e., "C:\WINDOWS\SYSTEM" Lastly, type "BUILDSYM", followed by the file specification that you want to build .SYM files for. For instance: "BUILDSYM *.EXE" will create .SYM files for all the .EXE files in the current directory. You'll probably want to build .SYM files in the WINDOWS directory, as well as the SYSTEM subdirectory below it. If you have the SDK, you may wish to make sure you have backups of the SDK provided .SYM files, although the .SYM files created by BUILDSYM are usually superior to the SDK provided .SYM files. Note: The .SYM file must be in the same directory as the .EXE or .DLL that it corresponds to. ======== Creating Turbo Debugger information ======== - For your own programs, you should have the compiler/linker produce debug information. If you're using a Borland IDE, make sure that the option to generate debug info is on. If you're letting BCC invoke TLINK, specify the "-v" option in the BCC command line. If you're invoking TLINK yourself, specify the /V option. If you're using TPCW, use the /V switch. If you're using a compiler that generates CodeView information, and have a copy of Turbo Debugger that has TDCONVRT included, you may be able to convert the CodeView information to TD information with it. - For programs that you don't have source to, i.e., USER.EXE, GDI.EXE, you can still create TD debug information with EXETDS. Go to the directory that contains the file that you'll be creating TD info for, i.e., "C:\WINDOWS\SYSTEM". Enter "EXETDS", followed by the filename, i.e., "EXETDS GDI.EXE" Note: The .TDS file must be in the same directory as the .EXE or .DLL that it corresponds to. |=============================================================================| | Running Dr. Frank | |=============================================================================| The easiest way to use Dr. Frank is to put it in the "load=" section of your WIN.INI. Upon starting up, Dr. Frank will minimize itself. No additional interaction is required on your part. When an exception occurs, Dr. Frank will write it's report out to a log file. The default name for the file is "DRFRANK.LOG" in the Windows directory. Typically, this is "C:\WINDOWS\DRFRANK.LOG". Next, you will see the "Unrecoverable Application Error" box. Click on the "OK" button. Next, you will see a dialog box from Dr. Frank that tells you what happened. If you wish to stop Dr. Frank, you can select "close" from its system menu. |=============================================================================| | Interpreting the log file | |=============================================================================| Here is a sample Dr. Frank Failure report, followed by annotations enclosed in preceeded by [] -------- Dr. Frank failure report - 11/20/1991 21:25:07 Exception 13 at KERNEL 0001:6B35 (0105:6B35) (TASK=ABC) [] The first line contains the date and time that the exception occurred. [] [] The next line tells you an exception 13 occurred in the KERNEL module, [] at logical address 0001:6B35. The "(0105:6B35)" is the actual CS:IP [] of where the exception occured. See the "Logical Address" section of [] this file if you're not familiar with the concept. The task that was [] executing at the time was "ABC". Disassembly: 0105:6B35 REPNE SCASB 0105:6B37 MOV AX,CX 0105:6B39 NEG AX 0105:6B3B DEC AX 0105:6B3C DEC AX [] The first instruction is the instruction that the CPU was attempting [] to excute when the exception occcured. Stack Trace: 0 KERNEL LSTRLEN + 000D CS:IP 0001:6B35 (0105:6B35) SS:BP 096D:1964 C:\WINDOWS\SYSTEM\KRNL386.EXE 1 USER USER.733 + 00E9 CS:IP 0029:0672 (05ED:0672) SS:BP 096D:19D2 C:\WINDOWS\SYSTEM\USER.EXE 2 USER MESSAGEBOX + 008D CS:IP 0001:9232 (04AD:9232) SS:BP 096D:19F6 C:\WINDOWS\SYSTEM\USER.EXE 3 ABC function1(unsigned long,unsigned long,unsigned long) + 001B CS:IP 0001:01DA (0965:01DA) SS:BP 096D:1A0A C:\DRFRANK\ABC.EXE 4 ABC WINMAIN + 008A CS:IP 0001:02DC (0965:02DC) SS:BP 096D:1A9C C:\DRFRANK\ABC.EXE 5 ABC <no info> CS:IP 0001:00B3 (0965:00B3) SS:BP 096D:1AAA C:\DRFRANK\ABC.EXE [] The topmost entry is the function/proceedure that you were in when the [] exception/UAE occured. In this case, the CS:IP was 0Dh bytes past the [] start of the LSTRLEN function in the KRNL386 module. [] [] To read a stack trace, start at the bottom, and work your way to the top. [] in this case: [] [] Some unknown function in module ABC called WINMAIN. [] WINMAIN in module ABC called FUNCTION1 in module ABC [] FUNCTION1 in module ABC called MESSAGEBOX in module USER. [] MESSAGEBOX in module USER called the 733'rd entry point in module USER [] entry point 733 called LSTRLEN in module KERNEL. [] At that point, the exception 13 occured. [] [] Note: You'll only have function names if you have a .SYM file for [] that module. If you have the SDK, you should have .SYM files for USER [] KRNLx86, and GDI. If you don't, you can build them yourself with the [] BUILDSYM utility, described elsewhere. Registers: AX 0000 BX 14DC CX FFFF DX 0000 SI 0002 DI 0000 SP 14DC BP 1542 IP 6B35 FL 0246 CS 0105 Limit: 9A7F execute/read DS 06E5 Limit: 4A9F read/write ES 0000 Limit: 0000 NULL SS 0B9D Limit: 269F read/write Message Queue: No messages retrieved yet Waiting in queue: hWnd: 0000 msg: 1234 wParam: 0000 lParam: 00000001 [] If possible, Dr. Frank will tell you what the last message retrived [] from the message queue was, as well as tell you about any messages [] that were waiting to be prcessed. Heaps: USER Max Size: F42F Free CE92 (83%) GDI Max Size: F79F Free D73E (86%) System info: Running in enhanced mode under Windows 3.0 debug version CPU: 80386 Largest Free memory block: D80000 bytes Total linear memory space: f5f000 bytes Free linear memory space : d81000 bytes Swap file Pages: f5f (f5f000 bytes) -------- ======== Additional information: Note: The function name given must be taken with a grain of salt. Dr. Frank will look in the .SYM file for the closest symbol name that appears before the address in the call stack. Some .SYM files do not contain information for all functions. Thus, the function name appearing in the log file will be that of the closest function in the .SYM file thats address precedes the frame address. If the offset field appears too high, be suspicious. Note: What you see in the Message Queue display is not necessarily the last message the program received. Windows may bypass the message queue, i.e., SendMessage(), so keep that in mind when using this information. Also, the message queue structure is not documented to my knowledge, so please let me know if you see something out of the ordinary. ======== Advance Features The optional Verbose Stack Trace section is for people who wish to see what was on the stack at the time of the exception. For each stack frame that doesn't exceed 256 bytes, a hex dump is performed, starting at the SS:BP for that frame. This data can be used to get the values of parameters that were passed to the function. NOTE: It is usually easier to let DFA2 do the hard work of figuring out what your paramters here. However, there may be cases where you don't have TD debug information, so this feature remains. Example: MessageBox() takes 4 parameters, and is a FAR PASCAL function. On the stack, you will have: [BP+0] ; Previous BP, incremented by 1 [BP+2] ; Far return address [BP+6] ; wType [BP+8] ; lpCaption [BP+0C] ; lpText [BP+10] ; hWnd Here's an example of a verbose stack trace entry: -------- 2 USER CS:IP 058D:9232 SS:BP 0BA5:15D4 MESSAGEBOX + 008D 0000: E9 15 85 01 8D 0B 00 00 96 09 E5 06 00 00 00 00 0010: 00 00 3E 02 -------- which you can read as: [BP+0] -> 15E9 -> Previous BP, incremented by 1 [BP+2] -> 0B8D:0185 -> Far return address [BP+6] -> 0 -> wType [BP+8] -> 06E5:0996 -> lpCaption [BP+0C] -> 0000:0000 -> lpText [BP+10] -> 0 -> hWnd |=============================================================================| | Post-processing the log file | |=============================================================================| Although the Dr. Frank log file is oftentimes enough to help you locate the problem, you may also need the additional assistance of TD debug information. To read and interpret the TD debug information at the time of the exception would cause potential system stability problems. The system might crash before the information had been written to disk. Therefore, the TD debug information is merged with the exception report after the exception has been cleared away, and the system is in a more stable state. The post-processing utility for Dr. Frank is called DFA2.EXE (to distinguish it from an earlier, incompatible version called DFA.EXE). By default, after a Dr. Frank has written out the log file, it writes a second file called DRFRANK.BIN. This file will appear in the same directory as the log file. It contains binary information about the task that was running, including copies of the data segments at the time of the exception. DFA2 will take the log file, and the DRFRANK.BIN file, and produce an output file that contains a stack trace, a listing of what selectors were in use by the failed task, and the names and values of your global variables. To run DFA2, you simply specify the file names for it to process. Typically, you will type the following: DFA2 DRFRANK.LOG DRFRANK.BIN The output is written to a file called DFA.OUT. You do not have to specify the second file name, but you will only see the strack trace information in that case. DFA2 has options not described here. See the DFA2 section for more details. Note: There will only be 1 DRFRANK.BIN file written per windows session. It is therefore important that you post-process the file as soon as possible after the exception. In addition, it is a very good idea to either rename, or delete the log file after the post-processing. DFA2 "associates" the first entry in the log file with the DRFRANK.BIN file. If you have multiple entries in the log file, you may not get the results you expect. To alleviate this problem as much as possible, I have changed Dr. Frank from previous versions. It will now default to overwriting any existing log file the first time an exception occurs in a given Windows sessions. Subsequent exceptions in that session will be appended to the file. |=============================================================================| | Logical Addresses | |=============================================================================| To understand a Dr. Frank log file, it is important to understand the difference between a "logical" segment, and a selector. Windows .EXE files are called "New EXE" files, because they have a different format then traditional MS-DOS files. When New EXE files are linked, each segment is placed in a different section of the file. At the same time, a segment table is created, which allows Windows and other programs to quickly find the data for a particular segment. When referring to a particular segment, its position in the segment table is used. Thus, the first segment in the table is logical segment 1, the second is logical segment 2, etc... You can determine the number of segments, their size, and other information by running TDUMP (A Turbo Debugger utility) on the file. Alternatively, if you generate a .MAP file for your program, you can obtain the same information. When the program is loaded, Windows allocates space for each logical segment and assigns it a unique selector. The code for the logical segments is then read into memory, using the assigned selector. Note: For any given .EXE or .DLL, the logical segment that a procedure or function is in will never change. The selector value on the other hand, depends upon what selector Windows decided to allocate for the particular logical segment. In other words, the selector Windows uses for a particualar logical segment can change between different invocations of the .EXE or .DLL. A logical address is comprised of a module name, a logical segment, and an offset. For instance "USER 0001:65EA" means offset 65EA in the first segment of USER.EXE. Logical addresses are what is used in the Publics section of a .MAP file. A physical address is comprised of a selector and an offset. A typical physical address that windows might create would be 09CD:65EA. Physical addresses are what the CPU works with. In the log file, addresses are given in terms of the the logical addresses as well as physical address The logical address appears first, followed by the physical address in ()'s. |=============================================================================| | DRFRANK | |=============================================================================| Since exception can not occur in real mode, Dr. Frank will only run if used in Windows Standand and Enhanced modes. Options for Dr. Frank are specified in the WIN.INI file as follows: LogDir=[directory to put log file]. This defaults to the Windows directory if none is specified. LogFileName=[file name to put log file] There should not be any path information in this string. If you need to specify a log file directory, use the LogDir option. If LogFileName is not specified, DRFRANK.LOG is used. NewLog=0/1 Specifying 0 will cause Dr. Frank to always append reports to the previous log file. Specifying 1 will cause Dr. Frank to overwrite the previous .LOG file the first time an exception occurs. Subsequent exceptions that occur during the same Windows session will be appended to the .LOG file. The default is 1, or always create a new logfile when the first exception occurs. ShowSystemInfo=0/1 Specifying 1 will cause Dr. Frank to output the Task list, the Module list, and information about the USER & GDI heaps. This information is omitted from the report if 0 is specified. ShowSystemInfo=0 is the default. StackData=0/1 Specifying 1 will cause Dr. Frank to add a verbose stack trace display to the end of the log file. Each entry displays the memory at a positive offset from the SS:BP for that stack frame. If there are > 256 bytes between 2 successive stack frames, the memory display is omitted for that frame. Specifying 0 for the StackData will cause the verbose stack trace to not be generated. This is the default. AuxOut=0/1 Specifying 1 will cause Dr. Frank to write an abbreviated form of it's report to AUX when writing the .LOG file. To use this, you should have either be using a device driver that redirects AUX to a second monitor, or a terminal connected to STDAUX. The defualt is 0, or no output to AUX. Here is an example of my entry in the WIN.INI file: [DrFrank] logdir=C:\DRFRANK NewLog=1 StackData=1 ShowSystemInfo=0 AuxOut=1 |=============================================================================| | BUILDSYM | |=============================================================================| BUILDSYM.EXE was written to allow you to automate the process of building .SYM files. For instance, you may not have Microsoft Windows Software Development Kit. Thus, you do not have .SYM files for the Windows DLLs such as USER, GDI, KRNL286, and KRNL386. Or, you may have the SDK, but want the undocumented entry points to be included in your .SYM files. You could manually go in and EXEMAP each file, then TMAPSYM the .MAP file, and then delete the .MAP file. What a drudge... BUILDSYM will do all of that for you, and do it on multiple files. BUILDSYM has 1 command line argument, which is a filespec that can include wildcards. For instance, "BUILDSYM C:\WINDOWS\SYSTEM\*.*" will build .SYM files for all Windows EXE's, DLL's, DRV's, etc... in that directory. Before attempting to build .SYM files, BUILDSYM will first determine if the file is a valid New EXE file. If not, it does not EXEMAP/TMAPSYM it. Thus, you should not be concerned about using *.* as a filespec, although it might take a bit longer then if you used a more restrictive filespec. Note: Any .SYM files created will be placed in the current directory. Thus, you should be in the directory where you want to create .SYM files. In order for Dr. Frank and other utilities to find the .SYM files, they need to be in the same directory as the New EXE file. Note: TMAPSYM will overwrite any existing .SYM files with the same name. Thus, make sure you have backups of any existing .SYM files before using BUILDSYM or TMAPSYM. |=============================================================================| | TMAPSYM | |=============================================================================| TMAPSYM.EXE was written to create .SYM files from any BC++ or TPW created .MAP files. Other .MAP to .SYM file converters may not work properly with Borland .MAP files. For instance, C++ programs have both the function name, as well as it's argument list to the .MAP file. TMAPSYM properly handles this. TMAPSYM has one command line option, namely the name of the .MAP file to be processed. For instance: TMAPSYM mytest.map This will create a file called MYTEST.SYM in the current directory. It is generally faster to have TLINK generate a link map, and use TMAPSYM, then it is to use DFA. Also, by using TMAPSYM, you get an immediate symbolic stack trace, as opposed to having to manually run DFA after an exception occurs. Note: If you are using precompiled headers with BC++, the default extension of the precompiled headers file is .SYM. If you use TMAPSYM, you might inadvertantly overwrite the .SYM file from the compiler. Since other utilities, as well as the Windows debugging version will only look for .SYM files, I would recommend using the -H=filename option with BC++ to name the precompiled headers file to a non-conflicting name. One caveat when using TMAPSYM is that it will only be able to find functions that are in the entry table of the executable. Thus, public functions that are not exported will not be found. In general this is not a problem. |=============================================================================| | EXEMAP | |=============================================================================| EXEMAP was written to create .MAP files from New EXE file format files (.EXE, .DLL, .DRV, etc...) for which you do not have source code or a .MAP file for. .MAP files created from EXEMAP can be processed by TMAPSYM to create .SYM files. These .SYM files are then in turn used by Dr. Frank One particularly good use of EXEMAP is to create .MAP files for DLL's when a .SYM file is not provided. Another reason why EXEMAP was written is because many .SYM files are incomplete. Oftentimes undocumented functions do not appear in the .SYM files. Since EXEMAP works directly from the executable file, many additional function entry points can be found, and included in your .SYM files. The syntax for EXEMAP is: EXEMAP <executable filename> [output file name] The default output filename, if none is supplied, is the input filename, with a .MAP extension. |=============================================================================| | DFA2 | |=============================================================================| DFA.EXE (Dr. Frank Assistant) was written to allow symbolic stack traces and variable values to be obtained via Turbo Debugger symbol tables. DFA2 will give you a file that contains a stack trace similar to the one in the Dr. Frank log file, but with but with the addition of function names and line numbers, as well as local and global variables. Note: DFA2 will not work with log files from previous versions of Dr. Frank. You must use the new DRFANK.EXE with DFA2. The syntax for DFA2 is: DFA2 [options] <Dr. Frank .LOG file> [DRFRANK.BIN] Options: /O<output filename>. i.e., /Ogoober will send the output to "goober" /D - Forces DFA2 to write out a hex dump of the saved data segments You do not need to specify the DRFRANK.BIN file, but if you don't, the resulting output file will not contain the program variable information. NOTE: DFA2 takes the first entry in the Dr. Frank log file, and assumes that it corresponds to the data in the DRFRANK.BIN file. Also, you will only get 1 DRFRANK.BIN file per Window sessions. The upshot is that it's a good idea to post-process immediately after the exception occurs, and copy/rename the files if you wish to save the information. ======== How does DFA2 look for TD debug information? First, the filename that is specified in the log file is inspected for TD debug information. If none is found, the file extension is changed to .TDS. ======== Format of the DFA.OUT file If you have to ask... Seriously, it's pretty self explanatory. If you see something wrong, let me know. |=============================================================================| | EXETDS | |=============================================================================| EXETDS (EXE to TDS) was written to allow you to create Turbo Debugger symbol files (.TDS) from the information contained in the exports of an EXE or DLL file. DFA can use these files when processing a log file. Also, TDW (Turbo Debugger for Windows) can use these files to provide symbolic disassembly in the CPU window. The syntax for EXETDS is: EXETDS <executable filename> [output file name] The default output filename, if none is supplied, is the input filename, with a .TDS extension. ---- For Advanced users To see the symbolic disassembly in TDW, you need to go to the VIEW | MODULES dialog box, select the appropriate module name in the right-hand pane, and then select "Load symbol table". To posistion to the start of a function, you can either "GOTO" from the CPU disassembly pane, or select VIEW | VARIABLES. You should see a list of all the functions for the module. You should then be able to select one, and have the disassembly pane be updated to the start of the function. Note: For some reason, TDW will hang if you try to load a symbol table for KRNL386.EXE. KRNL286.EXE, and the other Windows files seem to work correctly. |=============================================================================| | What's New | |=============================================================================| --- ??? The post-processing program DFA.EXE has been replaced by DFA2.EXE. DFA2 gives you all the information DFA gave you, but adds the ability to display the values of your local and global variables. Hard Work!!! See DFA2 section for more info. DFA2 is not backwards compatible, so you must use the new DRFRANK.EXE. The format of the stack trace has changed in the DRFRANK.LOG file. Dr. Frank now defaults to always creating a new LOG file the first time an exception occurs in the Windows session. The ability to disable the display of the filename in the stack trace has been removed. --- 11/21/91 DFA now outputs the original line, as output in the log file, if there is no TD debug info for that entry. DFA will now process all of the stack trace sections in a log file, instead of just the first one. EXETDS is new for this release. --- 10/27/91 --- Dr. Frank now has displays for System information (Task list, Module list, Memory usage), and the Message queue. In addition, the "Exception XX in XXXXXXX" dialog now comes up after the UAE box. This seems to make it more robust in a few oddball situations. DFA now should handle larger symbol tables, and should handle BC++ static functions and functions in TPU's. EXEMAP now outputs the program entry point, and will abort gracefully if there are no segments in the New EXE file, i.e., .FON files. Also, symbol names up to 255 characters should be O.K. TMAPSYM will now process the program entry point from the .MAP file. Symbol names up to 255 characters should be O.K. BUILDSYM is new for this release. |=============================================================================| | Support for Dr. Frank and Tools | |=============================================================================| Dr. Frank is Freeware for the time being. All I ask is that you let me know what you think, and if you have suggestions, or think you have a bug, to let me know. My Compuserve ID is: 76117,1720 Also, my main hangouts on Compuserve are BPROGB, sections 3 & 8 (Debugger/ Profiler, Windows Programming), and WINSDK. Matt Pietrek ===== Legal Disclaimer === Windows, MS-DOS, DRWATSON, WDEB386, and TOOLHELP.DLL are trademarks of Microsoft Inc. Turbo Debugger, Borland C++, Turbo Pascal for Windows, TLINK and TDUMP are trademarks of Borland International. All other names are trademarks of their respective holders. I make no claims as to the usability of these programs, and am not liable for any damages, incidental or consequential arising out of the use of these programs. IANAL, so I hope I got this right...