Generating Application Verifier logs for web applications

Application Verifier is a useful tool for capturing application bugs (mostly of the non-.NET variety) – things like heap corruption, resource leaks, invalid handle usage and the ignoring of exceptions by exception handlers to name a few.  It has a reasonably friendly GUI for configuring which applications you want to monitor, what you want to monitor them for and you can also view the log files that have been created from there as well:


Note: the Application Verifier page linked to above refers you to the download link for the tool on the Microsoft Download Center. At the time of writing that will get you version 4.0.665 of Application Verifier. However that is NOT the latest version. To get the latest version (4.0.0917 at the time of writing) you have to install the Windows 7 SDK . This is obviously a much bigger download but you can use the web based setup you can be quite selective about what bits of the SDK you do install and Application Verifier is identified clearly in the custom setup options:



If you are a web developer there a couple of “gotchas” that you might run into in relation to the logging that you should be aware of.

By default, logs are written to a location within the user profile path of the user account the application under test runs as. So for an interactive desktop application like Notepad it will write to something like this:


However if the process is running as some special account such as the NETWORK SERVICE account used for most IIS w3wp.exe application pool processes the profile based location may correspond to somewhere that the account does not have write access to:


(or for a 32-bit process on a 64-bit system, C:WindowsSysWow64configsystemprofileAppVerifierLogs).

Application Verifier does have a feature to cope with this; you can specify a log file path to be used by such “protected processes”:

AppVerif –sppath C:MyLogsLocation

Unfortunately, as I found out recently during a customer support case, there is a currently a bug in the logic for deciding that the alternate location should be used. The issue is this – if the “configsystemprofileAppVerifierLogs” location does not exist Application Verifier (or more specifically the vrfcore.dll component of Application Verifier that runs inside of the process being monitored) tries to create it. If the creation of that folder fails, it then reads the registry looking for this value:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution Options{ApplicationVerifierGlobalSettings} | ProtectedProcessLogPath (REG_SZ)

which it interprets as the alternate log location.

Unfortunately if the “configsystemprofileAppVerifierLogs” folder DOES exist but the process does not have write access within it (to create log files) then vrfcore.dll does not check for the alternate location. The result is that you just don’t get any log files. The best solution is to delete the “configsystemprofileAppVerifierLogs” folder (having first taken a copy of any existing log files you want to keep) and then follow the procedure for specifying an alternate location.

Once you have specified an alternate location using –sppath and ensure that Application Verifier does actually try to use it you still need to ensure that the process you are monitoring has write access to the specified log folder.

You can ensure that the w3wp.exe will have write access to the specified location by giving full control to one of three SIDs (security IDs):

MACHINENAMEIIS_IUSRS – this would give permission for any application pool [IIS7 and above or IIS_WPG on IIS6]

MACHINENAMENETWORK SERVICE – this should give permission for any application pool running under the default identity

IIS APPPOOLapplicationpoolname – this would give permission for the named application pool only  (Note: to give permission for this SID, you have to set MACHINENAME as the location when you are in the ‘Select Users or Groups’ dialog and then specify “IIS APPPOOLapplicationpoolname” as the user name ) [IIS7 and above]

A couple of reference sites useful for understanding application pool identities and accounts:


Note: in a situation where the logs do end up in the alternate location these logs do NOT appear listed in the Application Verifier GUI.

For that to happen, you need to manually move the log file from the alternate location to the location that would normally be used if you were doing an application verifier test on an interactive application running under your own login, e.g. C:UsersJohnAppVerifierLogs