Make a copy of svchost.exe in the System32 directory and call the copy �Mysvchost.exe�.

Using regedit, open HKLM\System\CurrentControlSet\Services\MyService.

Edit the value �ImagePath�, which will be something like �%SystemRoot%\system32\svchost.exe -k myservice� and change svchost.exe to �Mysvchost.exe�.

Add �Mysvchost.exe� to the AppVerifier list and check the tests desired.

Reboot.

Simple version: The golden rule for enabling verifier settings on a given application is to match the bit-ness of the tool and the target process. That is: use the 32-bit appverif.exe for a 32-bit application (both running under WoW64) and use the 64-bit AppVerif.exe for the native 64-bit native target.

Long Version: Application Verifier settings are the proper union of "core" settings and "shim" settings.

Core settings

Core settings are stored under Image File Execution Options.

The "Debugger" value is read from the launching application. So, if you want to have 32-bit devenv.exe launching 64-bit my.exe and have it running under debugger, you must use the 32-bit registry key under WoW6432Node. The other values, for a 32-bit process, are read from both places, both the native IFEO and the WoW6432Node.

The reasoning is the following: a 32-bit process running under WoW is a 64-bit process running the Wow64 emulation loop. So, each 32-bit process is first a 64-bit process, and then a 32-bit process. The 64-bit IFEO will enable verifier on the Wow64cpu.dll code, while the 32-bit IFEO will enable verifier on the 32-bit code.

From the end-user point of view, verifier.dll is loaded twice (once in the 64-bit world, once in the 32-bit world). Since most of the people do not care about verifying wow64cpu.dll, the most accepted behavior for 32-bit processes is to only verify the 32-bit part. That is why the golden rule of "always match the bit-ness" applies.

To debug a service that runs in a non-interactive window station, do the following (only applies if you�re using ntsd/windbg):

Add a key to the registry under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. The name of this key should be the name of the process (service.exe).

Create a REG_SZ value called Debugger and set this value to the path where your debugger resides. It must contain the full path, not just the name of the debugger. The command should include the �server option and a specific port or port range that the debugger should listen on. An example is c:\debuggers\ntsd.exe �server tcp:port=5500:5600 �g �G.

Connect to the debugger server by running the debugger with a �remote option. An example is: windbg.exe �remote tcp:=localhost,port=55xx where �xx� is some number from 00 to 99 if you used a range on the server.

Under Windows 7 and greater, there is a Leaks check option that will detect when a process leaks memory. Under earlier operating systems, AppVerifier does not test application for leak detection but looks for other memory issues.

• Heaps
  
  
• Handles
  
  
• Locks
  
  
• Stacks (only for services and important processes that can take machine down)
  
  

Keep in mind that ObsoleteAPICalls will just spit out a warning for every call it sees to an API that is listed as obsolete or deprecated in MSDN. You should decide on a case by case basis if it is important for your application to switch to the new APIs. Some of the APIs are dangerous, and some have merely been superseded by a newer API with more options. Take a look at the "Dangerous APIs" section of Writing Secure Code, 2nd addition for more.

For applications that need to be highly reliable, like services and server programs, you should also enable the Stacks check. This checks to see if the stack commit size is adequate, by disabling stack growth. If the application quits immediately with a stack overflow, that means the application needs to be recompiled with a larger stack commit size. If you're a tester, and encounter a problem with an application while using the Stacks check, file a bug, assign it to your developer, and keep on testing.