No, Memory Validator inspects all of •C runtime heap (CRT) •Win32 heaps (HeapCreate etc) •GlobalAlloc() heap •LocalAlloc() heap
Any of these heaps can be monitored for memory allocations and deallocations.
If using a custom heap manager of your own design (or a 3rd party design) you can provide information via the API so its memory can be tracked.
|
Not using CreateProcess
The Inject and Wait for Application to Start functionality also use CreateRemoteThread to inject into an application.
As below, injection using CreateRemoteThread does not always work.
Common reasons for injection failure
•A missing DLL in your application
•The target application is a .NET application or .NET service
•A missing DLL in Memory Validator
•The application may have started and finished before the DLL could be injected
•The application security settings do not allow process handles to be opened
•The application is a service and is running with different privileges than Memory Validator
|
Some features such as the Thread Filter can use thread names to make things a bit more readable.
Fom within your application you can provide a name for use by a debugger or debugging tool by using the Win32 RaiseException() API.
Add the function below to your application. This is based on an example from Microsoft. There are other examples available on the web; some specify a buffer size of 8 characters and one terminator, others specify no strict buffer size limit.
After adding this function declaration you can call it from inside the thread procedure of any executing thread to name.
nameThread(-1, "example");
To name a thread from outside of the thread procedure pass the thread id instead of -1.
The example application shipped with Memory Validator demonstrates how to use nameThread.
|
To clear Memory Validator's in-memory symbol cache, delete all sessions first:
•Managers Menu Then flush the cache:
•Settings Menu
Flush Cache disabled? Delete all the sessions first.
You may also want to disable the on-disk cache of PDB file symbols:
•Settings Menu |
Memory Validator detects uninitialized memory debug C runtime heap allocations.
The debug C runtime heap initialises memory as follows
•all allocated memory with a signature byte of 0xCD •any uninitialised stack variables with a signature byte of 0xCC.
Memory Validator hooks all constructors of C++ objects and at the end of the constructor examines the object.
Any uninitialized data bytes are reported to the user.
Note that 0xCD and 0xCC are valid data bytes but is unusual to be found them as a WORD (eg 0xCDCD) or as a DWORD (eg 0xCCCCCCCC).
Because of the chance of false detection, it is up to the user to determine if uninitialized data reports are correct.
The method for hooking the object's constructors is the same as is used to hook COM objects.
|
COM objects are tracked by hooking the Win32 functions that return COM objects.
These objects are then queried for their QueryInterface, AddRef and Release function pointers.
Those functions are then hooked by rewriting the instruction stream using some proprietary code.
The hooks then examine the return values to detect the reference count or returned object.
Caveats:
Rewriting the instruction stream is not a generally recommended practice and the above method can sometimes fail, typically when the compiler optimises two functions to share some common code.
Memory Validator tries to detect when hooking will fail and refuses to hook any functions that it knows it cannot hook safely.
Some COM objects simply cannot be hooked safely - we have found that you can debug some COM objects using Memory Validator, and not others because of the internal structure of the COM objects.
About instruction stream rewriting:
The instruction stream rewriting concept has been around for years (early video games in the 1980s for the Commodore VIC 20 and Commodore 64 often rewrote their instructions on the fly to gain a speed advantage) and is used, in varying forms, by some of the competing products and complimentary products to Memory Validator, and by Microsoft®.
|
We have tried to add as many features to Memory Validator that we thought would be useful to our users.
In fact, every feature in Memory Validator has been used to solve problems and bugs for clients who consult us, and in our own business, so we know the features we have are useful.
However, maybe we overlooked a feature that you would find very useful, and which you cannot work out how to add to Memory Validator via an extension DLL.
We'll happily consider most ideas for new features to Memory Validator. But no Quake, FlightSim or Flappy Bird easter eggs though, sorry!
Please contact us to let us know your thoughts.
|
