The following assumes your crash is one that only happens when using Memory Validator.
Here's a number of scenarios in which your program might crash:
•COM Reference Counting hooks are installed
These hooks rewrite the instruction stream, which sometimes doesn't work because some object code produced by the optimising compiler, or hand written assembly code shares common routines.
Try turning off the COM Reference Counting hooks and trying again.
•Uninitialised Data hooks are installed
These also rewrite the instruction stream (see above).
Try turning off Uninitialised Data hooks and trying again.
•Stub or User Interface extensions are being used
Remove all Stub extensions and User Interface extensions and try again.
•Third party DLLs are using system wide hooks
Some DLLs from third party vendors use system wide hooks and do not interact with Memory Validator and the target program very well.
If you can identify such DLLs, prevent them being hooked by adding the DLL name to the Hooked DLLs page of the global settings dialog as in the example below.
•Third party DLLs are using global hooks
A global hook DLL from a third party vendor could be adversely affecting Memory Validator when hooking your program.
Read about handling global hooks on the Global Hooks page of the settings dialog.
Judging by multiple independent error reports, we believe there may be an incompatibility between Memory Validator and the global hooks that come with the Matrox G400 and the Matrox Millenium II PCI video cards released in the late 1990's.
•There may be a bug in Memory Validator
It happens. We've tried to make Memory Validator as robust as possible, but bugs and new scenarios do occur.
First, ensure that the crash never happens if you are not using Memory Validator.
Second, check all the suggestions above.
Then drop us a line sending details of the error and we'll try to reproduce the crash with a view to fixing any bugs found in as timely a manner as possible.
|
Possible causes of release only crashes include:
•Uninitialised data
In debug mode, uninitialized data on the heap is filled with the value 0xCD.
This means that any code testing for TRUE or FALSE, always chooses TRUE when it reads uninitialized data in debug mode.
In release mode, the potential for uninitialised data to contain 0x00 means there's a 1 in 256 chance the value is FALSE, leading to hard-to-reproduce bugs.
Read more on how to detect uninitialized data using Memory Validator.
•An MFC Message Map bug
In debug mode, errors made when typing function prototypes for functions called by the MFC message maps cause no problems.
The same code, when run in release mode can corrupt stacks and crash.
Read about how to detect MFC message map errors using Memory Validator.
•Data Corruption
The debug and release CRT heaps are very different in structure.
The debug CRT heap has a lot of extra data in it, whereas the release CRT heap is compact.
A data corruption bug in debug mode may go unnoticed and only show up in release mode, or vice versa.
Data corruption bugs are unpredictable, alter data values; damaging data structures used to hold your data; or damaging the integrity of the CRT heap.
Read more about finding data corruption using Memory Validator.
|
The Memory Validator Unrecoverable Error dialog is displayed when an unexpected internal error means Memory Validator cannot continue to execute.
A stack trace and register dump is shown and you can Copy to Clipboard so that the data can be sent to us with a description of the activities that caused the error.
We'll aim to fix any problems in as timely manner as possible.
The data shown in the dialog is also written to c:\users\<username>\AppData\Roaming\Software Verify\Memory Validator\mvExceptionLogUI.txt .
The picture below shows an artificial exception report for a stack overflow error.
|
In the event of a crash in the Memory Validator user interface, the file c:\users\<username>\AppData\Roaming\Software Verify\Memory Validator\mvExceptionLogUI.txt contains information that identifies where Memory Validator was executing when Memory Validator crashed.
In the event of a crash in the target program, the file c:\users\<username>\AppData\Roaming\Software Verify\Memory Validator\mvExceptionLog.txt contains information that identifies where Memory Validator was executing when the target program crashed. This crash may have been caused by Memory Validator's instrumentation or by an error in the target application.
The file contains a stack trace and register dump and is the same information that is displayed in the Unrecoverable Error dialog when a crash occurred.
The file contains only the data for the most recent exception.
|
