| Product: | MicroStation | ||
| Version: | All | ||
| Environment: | N\A | ||
| Area: | Exception | ||
| Subarea: | N\A |
This discussion of MicroStation exception logs also applies to standalone MicroStation-based V8 generation products such as MicroStation PowerDraft, Bentley Redline, and Bentley View.
The information generated when MicroStation experiences a process exception or an access violation can be very helpful in diagnosing the cause, often minimizing the time it takes to correct it.
As an exception in MicroStation occurs, the details (processes and other programs that are running at the time of the exception, memory contents, and so on) are appended to the Exception.log file in the folder pointed to by MS_TMP. Since each exception generates approximately 240 KB of information, the size of Exception.log can grow substantially over time.
A Visual Basic script file manageExceptionLogs.vbs* is included in MicroStation v8.5.1 and above to help manage the exception logs, simplifying troubleshooting efforts. More information regarding managing exception logs can be found in the .
The exception log is an ASCII text file that can be opened by any text editor such as Notepad. It consists of sections containing information that can be used to help track down specific problems. Some of these sections may refer to similar processes or cross-reference other sections. For simplicity, only the sections highlighted in bold letters below are covered in this article:
* Machine registers
* Data registers
* Control registers
* Debug registers
* Floating point registers
* Segment registers
* Minidump location
* Stack dump
* Loaded DLLs
* Module load order
* Loaded MDL apps
* MDL call stack
* JMDL & Java VM states
* Loaded design files
* Loaded design library files
* Input queue history
* Thread name history
* Environment variable list
* Configuration variable list
* MDL application load history
* Visual Basic state and window message history
* Raw stack dump
Troubleshooting tips: Before reviewing an exception log, try running MicroStation without any custom workspaces, applications, VBA macros, third-party software, and so on. If an exception log is not generated without any add-on applications, tracking down the problem will be easier.
Always check to make sure you are looking at the most resent exception log by checking the date and time stamp in the file. The time stamp is the very last data recorded in the exception log and by default is sent to the ExceptionHistory-1 folder that is defined by the Visual Basic script file manageExceptionLogs.vbs
Exception 0xc0000005 at Mon Jan 02 08:37:22 2006
MicroStation version 08.05.02.35 Windows x86
Minidump location
A snapshot of MicroStation's process memory is written to the companion binary file MiniDump.dmp, which is rewritten with every exception. The size of this file will vary based on how the configuration variable MS_MiniDumpType is set and the amount of virtual memory occupied by MicroStation at the time of the fault. If MS_MiniDumpType is set to 4 (the default), MiniDump.dmp could be tens of kilobytes. If MS_MiniDumpType is set to 5, more information is collected and MiniDump.dmp could be on the order of one to ten megabytes. If MS_MiniDumpType is set to 7, much more information is collected and MiniDump.dmp could be as much as several hundred megabytes.
MiniDump.dmp is a binary file that must be opened with a dump-check utility. To load a dump file, Microsoft provides such a utility and explains the steps to read a .dmp file:
Microsoft Support
How to read the small memory dump filesthat Windows creates for debugging
Article ID: 315263
Link to utility: "Dump Check Utility"
The exception log is designed to help narrow down the source of an exception through process of elimination; you may find the minidump file to be more helpful in lower-level debugging.
Stack dump
The stack dump is the most informative section of the exception log. This section details what actions are being executed (in reverse order) at the time of the exception. Each row captures the function signature (e.g. "mdlLineStyle_query" or "mdlLineStyle_getWidthInUORs") being called by the DLLs. Each row begins with the hexadecimal value of the function signature, a unique name given to identify a command. The function signature includes the directory path of the DLL and the command being queried.
In this example, the function signature is executing an "mdlLineStyle_query" The function appears to be querying a line style. Is the line style being executed from a custom MDL and failing on a bad or missing resource? The input queue history may provide greater detail about the applications being executed that are causing the processor exception.
13: 0022cefc 5038e654 fffffffe 00000005 00000000 00000400
C:\Program Files\Bentley\Program\MicroStation\ustation.dll!mdlLineStyle_query+0x87e []
15: 0022cf30 502b75e2 0022d370 7fffffff 0022dac4 00000000 C:\Program Files\Bentley\Program\MicroStation\ustation.dll!mdlLineStyle_getWidthInUORs+0xa17 []
Troubleshooting tip: Some questions you should ask yourself in this section include the following: What types of functions are being loaded? Could the function be loaded from a custom workspace, applications, VBA macros, third-party software, and so on? Does the directory path for one of the functions lead to a different location than the others?
Loaded DLLs
The loaded DLLs section will identify the computer name, operating system, version number of the DLL, and the directory path to the DLL. Check each DLL version number to make sure they are up-to-date - is the current version of MicroStation running, or is it an older version? - or within your versioning standards. It's possible that an older, customized DLL is unintentionally being loaded in the newer installation of MicroStation.
This example shows that winopen.dll is listing a version that corresponds to the version of MicroStation currently installed:
6. 01c10000 + 22000 08.05.02.35
C:\Program Files\Bentley\Program\MicroStation\mdlsys\required\winopen.dll
This example shows textprocessor.dll is not corresponding with the current version of MicroStation installed. This version mismatch may indicate a version stamp discrepancy or an over-installation of MicroStation.
58. 593e0000 + 2c000 08.05.00.64 C:\Program Files\Bentley\Program \MicroStation\mdlsys\asneeded\textprocessor.dll
Troubleshooting tip: If you suspect that a DLL in this section is causing a problem, try temporarily disabling it and update it with a more recent copy. Rename the extension of the DLL to ".old" and run the Repair sequence in the MicroStation Installer.
Module load order
This section of information is the preferred address or load order of each module and the number of times the load library called each DLL. The preferred address is where the DLL prefers to live in memory. If a DLL doesn't get its preferred address, this can make MicroStation slow to start up.
The time stamp of each DLL reports the original installation date and can be helpful in identifying whether an incorrect DLL is loaded. Gathering the time stamp from this section and the version number from Loaded DLLs can provide additional information necessary in narrowing down the possible cause of the processor exception.
This example details Ustation.dll being called to load 244 times and shows the time stamp of Wed June 15. For basic troubleshooting, the time stamp may prove more useful, along with the version number in the Loaded DLLs section.
18. 50000000 +5c8000 503ad5e0 244 84004 0 Wed Jun 15 15:12:52 2005 (42b07db4) [MISC, 42b07db4 5c8000 "dll\ustation.dbg"] "C:\Program\Files\Bentley\MicroStation\ustation.dll"
Loaded MDL apps
This section is the list of MDL applications running. They are in reverse order, so the last one loaded is the first in the list. This list also provides version, date stamp, and directory location information, which is really helpful in identifying out-of-date or incorrect applications being loaded.
Here are some MDL applications commonly loaded by MicroStation:
1. IMIM 08.05.02.35 C:\Program Files\Bentley\Program\MicroStation\mdlsys\asneeded\IMIM.ma
2. RASTPRJ 08.05.02.35 C:\Program Files\Bentley\Program\MicroStation\mdlsys\asneeded\RASTPRJ.ma
Here is an example of a custom MDL being loaded:
8. CLOUD 08.05.02.35 M:\BentleyWorkspace\MicroStationV8\CustomMDL\cloud.ma
Troubleshooting tip: Look for custom MDL application running, out-of-date version stamps, or a directory structure that is pointing to a non-default location. Remove all custom MDL applications and retry the steps that led up to the exception.
Loaded design files:
Loaded design library files:
The next section in the exception log shows the environment at the time of the exception. It includes whether the application was running in high-security or normal mode and provides a list of the models, references, resources, DGNLibs, and cell libraries - with complete path specifications - that were being accessed in the session.
Troubleshooting tip: Retest the steps that initially produced an exception in a new design file, disable any DGNLibs and cell libraries that are being loaded prior to testing. If the exception only occurs in a specific design file, start breaking down the file by removing the reference file attachments and then move on to DGNLibs and cell libraries.
Input queue history
This section provides further detail about the commands being loaded along with some further time stamps. The commands will be within a set of quotes and may contain a familiar key-in string that was used by a custom macro or application. A list of up to the last 128 commands that were sent through the input queue will be recorded in this section. You can determine if the commands were sent by human input or a macro by looking at the time between any two commands.
Troubleshooting tip: Ask yourself whether some of the commands listed in the input queue history look familiar. It's possible that these commands are being loaded from a custom macro. Try removing these custom macros retry the steps that produced the exception.
This example is loading a line style "lstyle" & the Settings Manager "setmgr" utility. it's possible that a resource file being loaded has a bad definition. Try disabling the Settings Manager file that's loading the line style or the macro calling for these commands.
8:35:43.890 CMDNUM from MDL taskID = DEFAULT
"MDL SILENTLOAD lstyle" 0x79080000 0x6 USTN
8:35:43.609 CMDNUM from MDL taskID = DEFAULT
"MDL SILENTLOAD setmgr" 0x79080000 0x6 USTN
Operating system - environment variable list
These next two sections specify the system environment and configuration variables. The former is set by the host environment that MicroStation is running in and the latter are set or defined by configuration files. The level (e.g. predefined, user, system, site, etc.) determines when each variable was set.
5. COMPUTERNAME=USERCOMPUTERNAM
31. USERNAME=Joe.User
MicroStation - configuration variable list
9. MSDIR : system = C:\Program Files\Bentley\Program\MicroStation\
170. MS_USERPREF : site = C:\Program Files\Bentley\Home\prefs\examples.upf
MDL application load history
This section repeats the loaded MDL apps section, but with additional information. The very first character listed before the macro is an ‘L' or a ‘U', indicating if the application has been Loaded or Unloaded.
Troubleshooting Tip: Applications that are unloaded should be closely reviewed. It's possible that a command is attempting to reference an application during a process and is unable to do so. If the reference is not established, it could cause MicroStation to fail.
This example illustrates a loaded MDL:
L IMIM 8:37:21.765
"C:\Program Files\Bentley\Program\MicroStation\mdlsys\asneeded\IMIM.ma"
Type: 0, DLL 0, Lib 0, Priv 1, Stub 0/0, Sys 0, Started by: 0 -
This example illustrates an unloaded MDL:
U OLECNTR 8:37:08.171
"C:\Program Files\Bentley\Program\MicroStation\mdlsys\asneeded\olecntr.ma"
Exit: reason 65534, status 0, abort 0, excp 0, stub 0.
Raw stack dump
The final section is the raw stack dump of memory, which can help identify things like a problem loading a VBA application or another program. Information in this section is further detailed in the minidump file. Each row starts with four groups of hexadecimal values representing a memory address. Each group displays four bytes of memory and a total of 16 bytes per row. The hex values are read right to left and are read in groups of two.
Following the hex group is the interpreted character value, the character values are grouped within two colon ( : ) symbols.
The character values can display a directory path or variable being loaded. The example below shows four rows of data that make up a directory structure. These lines may prove useful in troubleshooting.
0022fdac : 00000000 505c3a43 72676f72 46206d61 : ....C:\P rogram F :
0022fdbc : 73656c69 6e65425c 79656c74 6f72505c : iles\Ben tley\Pro :
0022fdcc : 6d617267 63694d5c 74536f72 6f697461 : gram\Mic roStatio :
0022fddc : 53555c6e 49544154 45004e4f 00004558 : n\USTATI ON.EXE.. :
The exception logging that is included with the V8 generation is just one of the many behind-the-scenes improvements that have gone into Bentley products. The information provided in this article should help anyone track down specific problems that result in a process exception or access violation.
Note: If you run anti-virus software (e.g. Norton AntiVirus), you may be alerted that a "suspected virus" may be accessing the system when MicroStation creates the exception logs through the VBScript. However, workarounds may exist. For example, you can disable script blocking in Norton's AntiVirus as described here. Be sure to check with your system/computer administrator before disabling this setting.
Supplemental information regarding Dr. Watson log files can be found in the Microsoft KnowledgeBase articles "Using Dr. Watson" and "Overview of Dr. Watson". This is useful to anyone who encounters a Dr. Watson log or would like a better understanding of what is in one.
See also
Other language sources
| Original Author: | Bentley Technical Support Group |