| Product: | MicroStation | ||
| Version: | MicroStation/J and above | ||
| Environment: | N\A | ||
| Area: | Exception | ||
| Subarea: | N/A |
Overview
This article provides an introduction to MicroStation Exception logs to help anyone familiarize themselves with their usefulness and operation. It is not intended to be an exact step-by-step tutorial on how to decipher what is in an exception log (and accompanying MiniDump) or correlate that to the specific cause of the exception.
An exception is simply an error that a Windows application generates that it may or may not be able to recover from. The error could be the result of bad data passed to or used by an application or simply coding errors in that application. Application exceptions can range in severity from harmless to complete loss of data.
Any number of conditions can cause a Windows application to throw an exception. "General" exceptions include path related issues (i.e. missing or wrong version of .DLLs), application coding bugs, etc. MicroStation-specific exceptions can be file-related (e.g. design, resource, workspace, etc.) or related to 1st- or 3rd-party or custom applications.
MicroStation exception logs provide a lot of information particular to the MicroStation environment and conditions under which MicroStation was running -- all from a viewpoint within the user's environment. It is important to note that exceptions logs and exceptions are not specific and unique to Bentley products -- any Windows application can generate exceptions and exception logs, each varying with different amounts of data and information collected.
MicroStation exception logs consist of a text file (Exception.log) and an optional binary dump file (MiniDump.dmp). Exception logs can contain one or more exceptions and specific system details related to those exceptions. MicroStation/J and prior releases generate a single Exception.log file in:
- ..\MicroStation\temp
MicroStation V8 (prior to 08.05.01.25) generates an Exception.log and MiniDump.dmp file in:
- ..\MicroStation\temp
MicroStation V8 2004 Edition (08.05.##.## and higher) generates exception logs in separate directories:
- ..\Bentley\Program\MicroStation\temp\ExceptionHistory-1
- ..\Bentley\Program\MicroStation\temp\ExceptionHistory-1\Exception.log
- ..\Bentley\Program\MicroStation\temp\ExceptionHistory-1\MiniDump.dmp
MicroStation XM (08.09.##.##) or V8i (08.11.##.## ) generates exception logs under Windows TMP directories:
- In a DOS Command Shell window, type: C:>set tmp (you will see where your Windows TMP folder is)
- Set the TMP folder to current by typing in "cd %tmp%" in the Command Shell window (without the " double quotes)
- There will be subfolders under that, for example Bentley\MicroStation\8.11\7-MVP-obOL5iptQdzhwmJg\ExceptionHistory\ExceptionHistory-1 ("7-MVP-obOL5iptQdzhwmJg" will be different for every installation of MicroStation V8i or MicroStation V8 XM Edition)
NOTE: ExceptionHistory directories are renamed in a pattern where ExceptionHistory-1 always contains the most recent exception and up to ExceptionHistory-20 contains the oldest. This is "configurable" in manageexceptionlogs.vbs.
Almost all of the information contained in the Exception.log file is human readable. It provides a good understanding and more complete picture of the state of the environment under which MicroStation was running when the exception occurred. Having reliable information can be effective in troubleshooting, providing work-arounds, or even helping resolve an issue. Exception logs can provide key areas of insight into things like customizations that a user may or may not be aware they have loaded, actions a user may have been performing, etc.
Let's examine some of the most useful information found in all MicroStation exception logs:
- Date and time the exception happened
- Full MicroStation version
- Machine Registers (e.g. Data, Control, Debug, Floating Point, and Segment)
- Stack Dump (MicroStation/J and prior in binary format)
Exception log information added in MicroStation V8 2004 Edition:
- Exception numeric code
- Additional floating point register information
- Mini-dump file location
- Human readable call stack dump
- Loaded DLLs (by address)
- Computer Name
- Windows Version and Service pack level
- Number and type of processors
- Full path and versions of all .DLLs
- Loaded Modules (DLLs by load order)
- Reference count, image and load information
- Loaded MDL applications
- Full path and versions of all .MAs
- Loaded Design files (and Model References)
- Loaded DGNlibraries
- Cell Library
- Input queue history
- Up to the last 100 commands
- Operating System Environment variable list
- MicroStation Configuration variable list
- Variable Name, level, and fully resolved value
- Visual Basic state & window message history
- Dumping requests sent to the automation thread
The most important things to look for in a MicroStation Exception log are:
- Full MicroStation version being used
- Date and time matches the approximate time reported
- Quick look at the call stack to identify if exception is relevant to the issue described (e.g. font, resource, element, etc.)
- Quick review of the full path and versions of Loaded DLLs (Note: Versions and path should be identical or closely match the MicroStation version)
- Full Windows version being used
- Review the MDL application versions and locations
- Loaded Design file and model references
- Loaded Design Libraries
- Input queue
- Operating System environment variable list
- MicroStation environment variable list
Some additional things to consider (that the exception log may provide clues to):
- What exact steps did you take to receive the exception?
- Can you try to retrace the steps that you may have used leading up to the exception?
- Do you get the exception in one, some, or any file?
- Do you get the exception in a new MicroStation workspace?
- Can you create a new MicroStation workspace and design file and successfully create the exception?
- Are you running any 1st- or 3rd-party or custom MDL applications, macros, etc.?
See also
Other language sources
| Original Author: | Bentley Technical Support Group |