4 Minute Video

Find memory leaks quickly and easily with Memory Validator.

Memory Validator is a memory leak detector for use by software developers, software quality assurance testers and customer support staff using .Net, .Net Core (C#, VB.Net, etc) and native language compilers (C, C++, Delphi, VB6, Fortran etc).

Use Memory Validator to:

• Monitor billions of allocations in your application.
• Detect memory leaks and handle leaks (GDI leaks, etc).
• Find memory and handle leaks in native, .Net and mixed-mode .Net applications.
• Find double deletes, double frees, calls to deleted objects and related memory errors.
• Find uninitialized memory in C++ objects.
• Automatically detect memory leaks using the command line API. (For use with Jenkins, etc).
• Improve your unit tests, smoke tests and regression tests by automatically adding memory leak support to the tests.

Drowning in data, where do I start?

A common problem when monitoring applications that allocate a lot of memory and handles is understanding what is happening.

You need to be able to get a handle on which statistics need further investigation without having to visit many different displays.

To make this easy, we’ve provided a summary display highlighting all the key statistics, from which you can easily jump to a display dedicated to that statistic.

You can split the dedicated displays several ways, splitting along the .Net/native divide, but we don’t think that provides a useful experience. Because of this, in some places, you’ll find data of just one type (say .Net), but in others, you’ll find .Net and native data side by side (for example, when looking at type and size statistics) because that makes more sense.

Get to work in minutes

You don’t need to modify your application, recompile your software or relink your application.

Just launch your application from Memory Validator and start collecting memory and handle allocation data immediately.

Memory Validator uses your software’s debug information to perform the instrumentation of your software. Supported debug formats are PDB, TDS, DWARF, STABS, and COFF. We can also use MAP files if line number information is present.

Working with a service or IIS/ISAPI?

You don’t need to modify your software unless you are writing a service or working with IIS.

If you’re working with a service or IIS there is a simple API you can use that you can “fit and forget”. It’s so easy to use you can leave the API linked into your release product – it will do nothing unless Memory Validator is present.

4 step memory leak detection

This simple 4-step process is how you detect memory leaks with Memory Validator.

1. Launch your application with Memory Validator.
2. Run your application as normal.
3. Close your application.
4. Examine the memory leaks that Memory Validator finds in your software.

Easy-to-read data displays show you all the errors in the order they occurred. The displays can be filtered to show you only the information that you want to work with.

Drill down to the data in the displays by expanding an entry in the display to display information about the memory leak: What type of object was allocated, what size, where (address, filename, line number<), thread id, allocation timestamp, lifetime and sequence id. Also displayed is a comprehensive callstack showing each class and method name, filename and line number. Each entry can be expanded to display the source code for that line.

GDI Handles

It’s not uncommon for GDI handle leaks to occur in code related to drawing images. Leak too many of these, and nothing will display properly.

GDI handles are reported with extra data relating to the type of GDI handle. Pens and brushes indicate their colour and the type of line or brush (solid, pattern etc.). Fonts indicate the font construction, and bitmaps indicate information about the bitmap. Often this information is enough for you to identify the handle before you even dig into the code.

Perhaps you’d like to see what the GDI handle looks like while your application runs. Not a problem – select the GDI handle on the Memory View, display the context menu and choose Show GDI Object… The GDI handle is shown in its own dedicated dialog. Here’s the font GDI handle from the callstack shown above.

It’s only natural that you’d want to be able to monitor GDI handles and User32 handles changing over time, which is why the timeline display provides dedicated timelines for GDI handles and User32 handles.

Watermarks

Watermarks allow you to identify points in the sequence of memory allocation events. Once you have two or more watermarks, you can filter the display only to show you data allocated between two of those points. This can be very useful for detecting if the number of objects allocated (and not deallocated) between two points is what you expected. Watermarks can be named, allowing you to use meaningful names for each watermark.

For example, imagine creating a boss in a 3D program, then putting a chamfer onto the boss and then deleting the boss. If, after the deletion, you still see the allocated boss and the allocated chamfer, you probably have a memory leak. Seeing these allocations among all the allocations at runtime is hard work. But if you place a watermark before the creation of the boss (named “beforeCreateBoss”) and another watermark after the deletion of the boss (named “afterDeleteBoss”), you can then change the watermark filters to the before and after watermarks and view the allocations between those watermarks. This allows you to interactively test features of your application and check expected application behaviour as you test.

If you’d rather place watermarks programmatically, we have an API for this. One of our customers uses this API to place watermarks around all their database transactions allowing them to determine very easily which transactions leak and which transactions don’t leak.

Tag Trackers

Tag trackers are a very useful tool that allows you to classify different allocations as part of a related unit. For example, you could classify a lion, a tiger and a cheetah as “big cats” and classify a wolf, a husky and a fox as “canids”. How useful would it be to view statistics on related groups of allocations as well as just statistics on allocations?

This is best explained with a simple code example.

   createAFish("Pike");                   // no tracker

   {
      svlDataTracker   tracker_cats("Cats");

      createAnAnimal("Lion");             // cats tracker
      createAnAnimal("Tiger");            // cats tracker
      createAnAnimal("Panther");          // cats tracker

      {
         svlDataTracker   tracker_flowers("Flowers");

         createAFlower("Daffodil");       // flowers tracker
         createAFlower("Rose");           // flowers tracker

         {
            svlDataTracker   tracker_trees("Trees");

            createATree("Oak");           // trees tracker
            createATree("Sycamore");      // trees tracker
            createATree("Ash");           // trees tracker
            createATree("Horse Chestnut");// trees tracker
         }

         createAFlower("Lily");           // flowers tracker
      }

      createAnAnimal("Leopard");          // cats tracker
      createAnAnimal("Cheetah");          // cats tracker
      createAnAnimal("Cougar");           // cats tracker
   }

   createAFish("Salmon");                 // no tracker

Data that has been classified with tag trackers can be viewed on the Memory, Statistics, Hotspots and Memory Query views, providing you with opportunities to drill down into the data.

Configurable

Memory Validator can be configured to collect all data or just the data you need. Powerful filters for collecting data and for displaying collected data give you maximum flexibility and control over how much CPU time is spent and how much memory is used collecting data allowing you to choose how much effort is put into a given task.

The default options of Memory Validator concentrate on all memory leak types for C, C++, Delphi and Fortran, plus Win32 handles. You can enable/disable leak detection by memory type (for example, HeapAlloc) or handle type if you wish only to track specific types of memory or handle leaks.

Additional capabilities include uninitialised data tracking, detection of the use of deleted C++ objects, memory corruption detection, and broken message map usage.

API

Memory Validator provides two APIs for controlling Memory Validator from your application:

• One API is for direct control of Memory Validator.
• The service API is for using Memory Validator with services for the case when Memory Validator cannot inject into an application/service/IIS because Windows security privileges prevent that. 

These APIs are designed so that you can leave them in your software if you want to – they will do nothing if Memory Validator is not present, allowing you to ship your software with the APIs intact. This means you don’t need to have additional build configurations for with API and without API.

HTML and XML export

Memory Validator provides powerful HTML and XML reporting capabilities, allowing you to produce overnight leak reports if you use Memory Validator as part of a testing strategy. In addition, because you can compare two sessions to discover regressions, you can also export the leak report from any regressed comparison to identify where regressions are happening in your tests.

Built to handle large data volumes

Unlike some of our competitors that struggle to handle even one million allocations, some of our customers are processing billions of allocations with Memory Validator.

Compatible

Memory Validator works with compilers from:

Vendor	Language	Compiler / IDE
Microsoft	C++, C, Visual Basic 6, C#, VB.Net, J#, F#, .Net, .Net Core	Visual Studio, Visual Studio Community Edition, Visual Studio Express
Intel	C++, C, Fortran	Intel Performance Compiler, Intel Fortran
Embarcadero	C++, C, Delphi	C++ Builder, Delphi, Rad Studio
MinGW	C++, C	g++ / gcc
Cygwin	C++, C	g++ / gcc
MSYS2	C++, C	g++ / gcc
LLVM	C++, C	Clang
Qt	C++, C	QtCreator
Metrowerks	C++, C	Code Warrior
Salford Software	Fortran 95	Fortran 95

We support many versions of Visual Studio: Visual Studio 2022, 2019, 2017, 2015, 2013, 2012, 2010, 2008, 2005, 2003, 2002 and Visual Studio 6 are supported. We also support Visual Studio Community Edition and Visual Studio Express.

All 32 bit and 64 bit (x64) Windows operating systems are supported, from Windows 11 to Windows XP.

.Net and .Net Core

If you’re using .Net and/or .Net Core, Memory Validator supports these technologies. All .Net versions are supported. All .Net Core versions are supported.

If you’re also using native code with your .Net applications, we’ve also got that covered, mixed mode applications are supported.

Applications, services, web servers

Memory Validator works with applications, services and IIS/Web Development Server, both native and mixed-mode .Net.

Regression test support

As well as the traditional interactive memory leak debugging role that Memory Validator performs, Memory Validator can be used to compare two recorded sessions to show the difference between the sessions. This allows you to determine if changes to your code have resulted in improvements (fewer memory leaks, fewer errors) or regressions (more memory leaks, more errors).

Command Line

Memory Validator also allows you to automate memory leak testing by launching Memory Validator from the command line.

A full range of command line options allows you to perform unattended runs of Memory Validator, complete with HTML export and XML export, to facilitate regression testing as part of your overnight builds.

Example 1 Launch a program with a specific startup directory, using two arguments, and save the session without showing the Memory Validator interface.

memoryValidator.exe -hideUI
                    -program c:\myProgram.exe
                    -directory c:\testbed
                    -arg " -macro c:\macros\testMacro1.vba"
                    -arg "secondArg"
                    -saveSession c:\results\testMacro1.mvm

Example 2 Launch a program with a specific startup directory, using two arguments, save the session, compare the recorded session with a known baseline and export the comparison results to HTML and XML. The Memory Validator interface is not shown.

memoryValidator.exe -hideUI
                    -program c:\myProgram.exe
                    -directory c:\testbed
                    -arg " -macro c:\macros\testMacro1.vba"
                    -arg "secondArg"
                    -saveSession c:\results\testMacro1.mvm
                    -baseline c:\baselines\testMacroBaseline.mvm
                    -sessionCompareHTML c:\regression\testMacro1.html
                    -sessionCompareXML c:\regression\testMacro1.xml

Memory Validator Feature List

Software Updates

We update our software tools on a regular basis – on average, about 26 updates per year. Updates are optional, and you only need to download the most recent update to be up-to-date.

You can set up automatic software updates using the credentials we supply to you when you purchase. Automatic software updates can be set up to check daily, weekly, monthly or never.