How test a Delphi app with Application Verifier 4.0?

I download the Application V开发者_Python百科erifier 4.0 to test my App for check if could have problems on Vista/7.

I run from Delphi 2010 debugger, and stop in CPU view. Obviously, I don't understand anything about assembler!.

So, I try running directly from the windows explorer, and the App die.

(In fact, I don't understand well what exactly will do App Verifier: I expect some kind of friendly message).

This is what i get:

7C81A3E2 C3               ret 
7C81A3E3 90               nop 
7C81A3E4 8BFF             mov edi,edi
ntdll.DbgUserBreakPoint:
7C81A3E6 CC               int 3
7C81A3E7 C3               ret 
7C81A3E8 8BFF             mov edi,edi
7C81A3EA 8B442404         mov eax,[esp+$04]
7C81A3EE CC               int 3
7C81A3EF C20400           ret $0004
ntdll.NtCurrentTeb:
7C81A3F2 64A118000000     mov eax, fs:[$00000018]
7C81A3F8 C3               ret 
ntdll.RtlInitString:
7C81A3F9 57               push edi

Loading:

:7c81a3e2 ntdll.DbgBreakPoint + 0x1
:10003b68 ; C:\WINDOWS\system32\vrfcore.dll
:00396a9d ; C:\WINDOWS\system32\vfbasics.dll
:00397316 ; C:\WINDOWS\system32\vfbasics.dll
:7c84bcdb ; ntdll.dll
:7c8316f8 ; ntdll.dll
:7c83154f ; ntdll.dll
:7c82855e ntdll.KiUserExceptionDispatcher + 0xe
:0040aa00 GetUILanguages + $80
:0040b298 GetResourceModuleName + $124
:0040afde LoadResourceModule + $7A
:0040a134 DelayLoadResourceModule + $2C
:00406c40 @StartExe + $44
:77e6f23b ; C:\WINDOWS\system32\KERNEL32.dll

---

Application Verifier is a GUI wrapper around a bunch of registry settings.

When you add your application to Application Verifier, it tells Windows to do more checking when your application is running.

After you've added your application, you can close Application Verifier; the settings are saved.

Now, any time you run your application, Windows will do extra checking for various conditions (as specified via Application Verifier).

Some of the checks will result in DebugBreak() being called. (This is why your application dies when you run it under Windows Explorer.)

You must run your application under a debugger so that you can see where the problems occur.

I know very little about Delphi 2010; if it's creating managed code, you may have problems, as the breakpoints will occur in native code, and your debugger (Delphi's debugger) would need to be able to debug mixed native/managed code.

---

You can use it with windbg to debug the application. And go to the help of Application Verifier you will find all the commands how to debug the app and how to get the details of the error.

---

I tried various combinations of the app verifier the other day.
The 32 bit version just kept crashing. Then, having read a bit of the documentation, I found that there's no point in running the 32 bit version anyway because Microsoft are only interested in the results of the 64 bit test. The 32 bit is for your own reference only (and doesn't work!).
So I dumped my 32 bit Win7 virtual machine and created a 64 bit Win 7 VM, installed the 64 bit app verifier, read the README (an unusual step for us programmers I grant you :-) ), then printed out the README 'cos it's confusing! After that you follow the prompts and install/run your 32 bit app under the 64 bit OS. Works fine
...and then you go fix any warnings from the app verifier report.

---

I have no expierence with AppVerifier, but KiUserExceptionDispatcher is exception handler caller. There was exception in your application - call stack indicate that. That's probably why OS stops you at debugger.

I think that you're supposed to analyze why there was an exception here and get rid of it.

---

AppVerified generates log files that you can view from within AppVerifier itself. If your app crashes, try disabling some of the AppVerifier checks to find the culprit.

---

Running through the Delphi debugger, you will usually (possibly always) stop in CPU View when App Verifier issues occur. This is because the actual machine instructions that triggered the issue is higher up in the call stack from your line of code that indirectly triggered it.

The solution is (usually) simple:
Open your Call Stack Window, and look down the list of entry points until you find familiar code.

The only time so far that I haven't found this to work as well; is when your application is shutting down and has proceeded beyond a certain point in the shutdown process. I.e. The 'post-end-of-application-cleanup': unloading units, unloading statically linked DLLs, releasing memory from the memory manager, unloading the memory manager.