The Basics verification layer within Application Verifier require that you run your application under a debugger. If you do not have a debugger associated to the application prior to selecting the test, you will receive a dialog reminding you that you will need to run your application under a debugger in order to obtain the logged information.

See the Debugger install and setup topic. If this doesn't address your question, visit http://go.microsoft.com/fwlink/?linkid=8708.

Visit http://go.microsoft.com/fwlink/?linkid=8708.

In general, stack expansion should be really tested in isolation from other verification layers, including heap. The reason is the following: each verification layers "thunks" an API or an exported point with some routine.

For example, a call to CreateFileA, will be a call to appvocre!NS_SecurityChecks::CreateFileA, that might call appvcore!NS_FillePaths::CreateFileA that might call kernel32!CreateFileA, that might call verifier!AVrfpNtCreateFile, that will call ntdll!NtCreateFile. You can see that the instrumentation has added 3 more "stacked" function calls, each one of them may and will consume more stack.

In the case below, the LH-verifier.dll is "thunking" every DllMain, and the "instrumented" heap code path will add more stack usage. Since the injected thread from the debugger does not use the IMAGE_NT_HEADERS defaults, the initially committed stack will not be enough to complete the APC state of a thread (a thread in the APC state executed the initialization code).

If you want to use Stack-Ckecs, probably the only other verification layer you should use if FirstChanceAccessViolation.

I turned the stack check on for my service. I am able to start and stop the service. But if I start a remote and connect a client to the remote and hit ctrl-brk to stop in the client debugger I get an overflow stop with the stack. Why?

Microsoft Windows XP does not have a fix for DbgUiIssueRemoteBreakin to create the injected thread with a big enough stack for the page-heap code.

Instead, you can do one of the following:

• Use a more modern operating system.
  
  
• Test the stack expansion without any other instrumentation (recommended, since superimposition of effects is non linear).
  
  
• Debug from KD, where there is no need to inject a thread to break in the debugger.
  
  
• Use suspensive non-invasive debugging.
  
  

The complete error received:

Application verifier is not enabled for this process. Use appverif.exe tool to enable it.

You probably have just the shim verification layers enabled and/or the heap in "pure" mode enabled. These are some of the possible causes.

Without any detail of what exactly was enabled before and what was enabled after the change (and what the change was), it is not possible to say anything meaningful.