Application Verifier: Save your memory! Debug your apps! Also, hax.
Application verifier is a nifty application that Microsoft introduced for Windows XP around 2001. This testing tool is also useful for if you want to troubleshoot Windows applications. For example, if you notice a process that is getting out of hand with memory resources, you can simulate an environment where this application can’t allocate more than, say 500 MB of memory.
Getting application verifier
You can download 32 and 64-bit versions of application verifier from the Microsoft download center and can read some notes about application verifier on MSDN.
When you install application verifier and run it, you will see a screen like the following:
Not that exciting, yes? Well, let’s make it interesting. On the left side of the application is a list of the applications that you have configured to run with application verifier. We don’t have any configured yet, so let’s add one! Click File->Add application or press Ctrl+A:
I’ll add Adobe Reader 🙂 Once you have the application added to the list of applications, it will appear at left and you can do all sorts of stuff in the “tests” section of the application to constrain the application.
Right clicking on tests lets you set more properties on the tests, for example, you can set the specific resources that you are restricting as shown in the following screenshot:
Yeah, that’s right. You can limit an application’s heap size, explicitly set timeouts for triggering the “app is not responding” and all other sorts of magic.
** Update ** This may be incorrect. As mentioned in the comments, the ALLOC values do not correspond to limits on heaps but instead correspond to the error frequency – higher values mean more frequent allocation errors, lower values approach zero errors.
Why do I care?
Scenario 1: testing with application verifier
Application verifier is an excellent test tool for:
- Finding memory leaks early: simply crank down your application resources and run your app for a little bit.
- Seeing that your application plays nice when it’s not run as administrator
Scenario 2: application verifier hacks
This is the fun part 🙂 Let’s say you have an application, for simplicity, we’ll call it emorhc. So let’s say this application tends to get process and memory sizes that are a little out of hand. You can add it to application verifier, limit it’s heap, and like magic, it will not hoard your system memory.
Conclusions
Check out application verifier, it’s the bomb.
Very interesting points you have noted, appreciate it for putting up.
Hi Gus
Thanks for the post, this is a great idea I’d like to try. Please can you explain in more detail how the values such as HEAP_ALLOC etc can be used to impose the 500Mb limit on the selected application? What is the unit for HEAP_ALLOC, is it bytes? The Application Verifier documentation suggests to me that it is actually a percentage chance of hitting a heap allocation error, but then the default value of 20000 makes no sense in that case. Thanks.
A great way to understand low resource simulation is to create an application that leaks and wait for it to crash. The following example in C++ is a simple leaking app:
// heap_exploder.cpp : Defines the entry point for the console application.
//
#include “stdafx.h”
#include
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
int i=0;
while(true){
int *leak = new (int);
if (leak){
if (i%100 == 0)
cout << i << " : allocs " << endl;
i++;
}else{
cout << "Your heap is empty, there's a leak." << endl;
}
}
return 0;
}
Playing around with the HEAP_ALLOC value in the low resource simulation will cause the application to either crash or smoothly fail if memory can't be allocated. Note, and this is a big one, the Low Resource Simulation has 3 alloc fields. HEAP_ALLOC, VIRTUAL_ALLOC, and OLE_ALLOC. HEAP_ALLOC is your standard app-level heap, VIRTUAL_ALLOC is allocations on the virtual address space, OLE_ALLOC is the dynamically allocated memory from OLE calls (smart pointers do this and various libraries will be using this). If you want to disable one of these (e.g. you want no limit), you will need to set it to 0. Note also that each of these can allocate different amounts of memory so it can be difficult to really see the various heaps in taskmgr. It looks to me like the memory limits are in kb, little k, which is why 20000 is the default playing around a little more with my leaky example should let you determine exactly what this limit is, but I unfortunately can't get a definitive answer right now. What I have noticed while testing this out with various values in App verifier is that using a limit on OLE_ALLOC will generate inconsistent failures (presumably) because the OLE garbage collection is load bound for your PC. So, if you're having trouble playing around with this, try setting the OLE_ALLOC value to 0 and see if that helps.
@Adam Thanks for the comment, btw, this has actually started me on something of an investigation now.
I looked a little deeper into this, and it seems completely random where the application crashes when using my sample (due to a bad memory alloc). There are a lot of variables right now in my testing but it certainly seems like there is a race condition somewhere (either in app verifier itself or within my leaky app) that is causing this behavior. In short, I have no idea what these values actually mean, I will try and get to the bottom of it though.
@Adam and @gguuss: I was looking for this same information and found your blog first. Now that I have found (what I think is) the correct answer I thought I would respond here for the next time I search!
According to the help (“Low Resource Simulation Stops” page) it is “Heap_Alloc – A number [0 – 1000000] that indicates the fault probability for the Heap Allocation API.”
What I assume they mean is it is 0.0000% to 100.0000%. i.e. it is a percentage chance but to 4 decimal places. This allows you to use very low chances for programs that allocate lots of memory and want to fail very occasionally (a 1 in a 100 memory allocations failing is actually pretty high for most programs which allocate lots of memory).
@Richard – Thanks for the update! I’m guessing that I (and potentially whatever dead documentation I built my answer on) are incorrect here. SO .. what wold happen in these cases is not leaking memory but just bad allocations (malloc returning a bad value). Thank you for sharing!
Thanks for this article and the informative discussion!
So is it settled now that the Application Verifier only allows to test robustness against failed memory allocations, and not to set a hard limit on the heap size?
I’m asking because I’m investigating possibilities to run a certain legacy software on newer systems, and from all the experiments so far the application will only run if the system has 2 GB of main memory or less. I was hoping that maybe Application Verifier would be able to set a per-process hard limit, and possibly get the program to run. Although I guess it’s also highly possible that the application fails because of a memory detection algorithm that doesn’t scale, and wouldn’t be phased by simply having allocations denied.