Weryfikator aplikacji — testowanie aplikacji

Application Verifier (AppVerifier) to narzędzie do weryfikacji środowiska uruchomieniowego dla niezarządzanego kodu, które pomaga w znajdowaniu subtelnych błędów programowania, problemów z zabezpieczeniami i ograniczonych problemów z uprawnieniami kont użytkowników, które mogą być trudne do zidentyfikowania przy użyciu normalnych technik testowania aplikacji.

Aby dostarczać niezawodne aplikacje systemu Windows:

1. Aplikacje testowe napisane w kodzie niezarządzanym (natywnym) za pomocą narzędzia Application Verifier w debugerze i z stosem pełnostronicowym przed udostępnieniem go klientom.
2. Wykonaj kroki podane przez weryfikatora aplikacji, aby rozwiązać błędne warunki.
3. Po wydaniu aplikacji regularnie monitoruj zebrane raporty o błędach aplikacji, na przykład przez raportowanie błędów systemu Windows, jeśli są dostępne.

Kontrole puli wątków są domyślnie włączone w nagłówku sprawdzania "Podstawy". Ponieważ jest to uwzględnione w ustawieniu domyślnym, użytkownicy muszą uruchamiać tylko weryfikatora aplikacji w kodzie z ustawieniami domyślnymi, aby korzystać z tych i innych ważnych testów.

Konfigurowanie weryfikatora aplikacji

Konfiguracja debugera

Zweryfikowana aplikacja powinna działać w debugerze w trybie użytkownika lub system powinien działać w debugerze jądra, ponieważ w razie wystąpienia błędu nastąpi włamanie do debugera. Aby uzyskać więcej informacji, zobacz Application Verifier — debugowanie weryfikatora aplikacji zatrzymuje.

Ustawienia

Nie można włączyć weryfikatora aplikacji dla uruchomionego procesu. W związku z tym należy wprowadzić ustawienia zgodnie z poniższym opisem, a następnie uruchomić aplikację. Ustawienia są trwałe do momentu jawnego usunięcia. W związku z tym niezależnie od tego, ile razy uruchamiasz aplikację, zostanie ona uruchomiona z włączonym elementem AppVerifier do momentu usunięcia ustawień.

Korzystanie z testu podstawowego weryfikatora aplikacji

W poniższych scenariuszach przedstawiono zalecane opcje wiersza polecenia i interfejsu użytkownika. Powinny one być uruchamiane podczas wszystkich testów, które wykonują kod, aby zapewnić pełne pokrycie. Oczekiwanie na te scenariusze polega na tym, że aplikacja nie dzieli się na debuger, a wszystkie testy przechodzą z taką samą szybkością przekazywania, jak w przypadku uruchomienia bez włączonego elementu AppVerifier.

Włącz weryfikatora dla aplikacji, których chcesz przetestować. W wierszu polecenia: appverif /verify MyApp.exe.

W interfejsie użytkownika: Dodaj aplikację, klikając prawym przyciskiem myszy w obszarze Aplikacje i wybierając pozycję Dodaj aplikację. Wybierz pozycję Podstawowe w obszarze Testy. Kliknij przycisk Zapisz.

Notatki:

/verify włączy testy podstawowe

Jeśli testujesz bibliotekę DLL, weryfikator aplikacji musi być włączony dla testowego pliku wykonywalnego wykonującego bibliotekę DLL.

Uruchom warstwy weryfikacji oddzielnie. Na przykład w jednej sesji włącz wszystkie podstawowe i na drugim włącz wszystkie kontrole LuaPriv.

Uruchom wszystkie testy wykonujące aplikację.

Przeanalizuj napotkane przerwy debugera. Jeśli wystąpi przerwa, musisz go zrozumieć i naprawić. UWAGA: Zawartość pomocy zawiera szczegółowe informacje na temat podziałów i sposobu ich badania.

Po zakończeniu usuń wszystkie ustawienia. W wierszu polecenia: appverif /n MyApp.exe.

W interfejsie użytkownika usuń aplikację, klikając prawym przyciskiem myszy w obszarze Aplikacje i wybierając pozycję Usuń aplikację. Następnie kliknij przycisk Zapisz.

Uszkodzenie stert

Prawie 10% awarii aplikacji w systemach Windows wynika z uszkodzenia stert. Te awarie są prawie niemożliwe do debugowania po fakcie. Najlepszym sposobem uniknięcia tych problemów jest przetestowanie funkcji stert strony znalezionych w weryfikatorze aplikacji. Istnieją dwa smaki sterta strony: "Full" i "Light". Pełna jest wartością domyślną; wymusi natychmiastowe zatrzymanie debugera po wykryciu uszkodzenia. Ta funkcja musi być uruchamiana w ramach debugera. Jednak jest to również najbardziej wymagający zasób. Jeśli użytkownik ma problemy z chronometrażem i uruchamia już scenariusz w obszarze Sterta "Pełna" strona, ustawienie go na wartość "Light" prawdopodobnie rozwiąże te problemy. Ponadto sterta light page nie ulega awarii, dopóki proces nie zakończy się. Zapewnia on ślad stosu alokacji, ale diagnozowanie może trwać znacznie dłużej niż korzystanie z jego pełnego odpowiednika.

Korzystanie z symulacji niskiej ilości zasobów w aplikacji AppVerifier (wstrzykiwanie błędów)

Oczekiwanie na ten scenariusz polega na tym, że aplikacja nie dzieli się na debuger. Nie dzieląc debugera, oznacza, że nie ma żadnych błędów, które należy rozwiązać.

Częstotliwość przekazywania testów może znacznie się zmniejszyć, ponieważ wstrzyknięcia losowych błędów są wprowadzane do normalnego działania.

Włącz symulację niskiego zasobu weryfikatora aplikacji (wstrzyknięcie błędów) dla aplikacji. W wierszu polecenia: Appverif /verify MyApp.exe /faults. W interfejsie użytkownika: Dodaj aplikację, klikając prawym przyciskiem myszy w obszarze Aplikacje i wybierając pozycję Dodaj aplikację . Wybierz symulację niskich zasobów w obszarze Testy. Kliknij przycisk Zapisz.

Uwaga: Jeśli testujesz bibliotekę DLL, możesz zastosować symulację niskiego zasobu (iniekcję błędów) w określonej biblioteki DLL zamiast całego procesu. Format wiersza polecenia to:

appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]

Przykład:

appverif /verify mytest.exe /faults 50000 1000 d3d9.dll

Uruchamianie wszystkich testów wykonujących aplikację

Przeanalizuj napotkane przerwy debugera. Jeśli wystąpi przerwa, musisz go zrozumieć i naprawić.

Po zakończeniu usuń wszystkie ustawienia. Z wiersza polecenia: appverif /n MyApp.exe. Z interfejsu użytkownika: usuń aplikację, klikając prawym przyciskiem myszy w obszarze Aplikacje i wybierając polecenie Usuń aplikację, klikając przycisk Zapisz.

Uwaga: Uruchamianie z użyciem i bez iniekcji błędów wykonuje w dużej mierze różne ścieżki kodu w aplikacji i dlatego oba scenariusze muszą być uruchamiane, aby uzyskać pełną korzyść z aplikacji AppVerifier.

Używanie weryfikatora aplikacji z aplikacją WOW64

Możesz użyć 32-bitowej lub 64-bitowej wersji narzędzia Application Verifyr, aby zweryfikować aplikację 32-bitową działającą w systemie WOW64.

Analizowanie danych programu AppVerifier

Wszystkie dane utworzone podczas analizy appverifier są przechowywane w folderze %USERPROFILE%\AppVerifierLogs w formacie binarnym. Te dzienniki można następnie przekonwertować na kod XML za pośrednictwem interfejsu użytkownika lub wiersza polecenia w celu dalszej analizy.

Aby wyświetlić pliki XML, możesz użyć dowolnego narzędzia do wyświetlania kodu XML, na przykład importowania do programu Microsoft Excel — importowanie pliku XML do programu Excel i używanie filtrów lub tabel przestawnych w celu reorganizacji i analizowania zebranych danych.

Korzystanie z wiersza polecenia

Weryfikator aplikacji może być używany za pośrednictwem interfejsu użytkownika lub za pomocą opcji wiersza polecenia.

Poniżej przedstawiono przykłady korzystania z wiersza polecenia (poniżej przedstawiono szczegóły):

appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]

appverif /verify notepad

appverif -enable LAYER … -for TARGET ... [-with [LAYER].PROPERTY=[VALUE] …] 

appverif -disable LAYER ... -for TARGET ...

appverif -query LAYER ... -for TARGET ...

appverif –configure STOP ... -for TARGET ... [-with STOPPROPERTY=[VALUE] …]

appverif –logtofile {enable|disable}

Aby włączyć weryfikator aplikacji dla określonej warstwy weryfikacji dla dwóch aplikacji:

appverif –enable Heaps Locks –for notepad.exe iexplore.exe

Aby włączyć dwie warstwy o nazwach X i Y dla test.exe docelowych z właściwościami X.DebugLevel i Y.DebugLevel:

appverif –enable X Y –for test.exe –with X.DebugLevel=1 Y.DebugLevel=2

Aby wyłączyć wszystkie testy uruchamiane w aplikacji:

appverif -disable * -for notepad.exe

LUB

appverif -delete settings -for notepad.exe

Aby globalnie włączyć lub wyłączyć rejestrowanie weryfikatora aplikacji dla wszystkich procesów:

appverif –logtofile enable

appverif –logtofile disable

Rejestrowanie jest domyślnie włączone dla wszystkich procesów.

Składnia wiersza polecenia weryfikatora aplikacji

Użycie wiersza polecenia weryfikatora aplikacji:

-enable TEST ... -for TARGET ... [-with [TEST.]PROPERTY=VALUE ...]
-disable TEST ... -for TARGET ...
-query TEST ... -for TARGET ...
-configure STOP ... -for TARGET ... -with PROPERTY=VALUE...
-verify TARGET [-faults [PROBABILITY [TIMEOUT [DLL ...]]]]
-export log -for TARGET -with To=XML_FILE [Symbols=SYMBOL_PATH] [StampFrom=LOG_STAMP] [StampTo=LOG_STAMP] [Log=RELATIVE_TO_LAST_INDEX]
-delete {logs|settings} -for TARGET ...
-stamp log -for TARGET -with Stamp=LOG_STAMP [Log=RELATIVE_TO_LAST_INDEX]
-logtoxml LOGFILE XMLFILE
-installprovider PROVIDERBINARY
-sppath [PROTECTED_PROCESS_LOG_PATH]
-cppath
-logtofile [enable | disable]

Składnia wiersza polecenia akceptuje co najmniej jedną warstwę i stosuje je do jednego lub większej liczby obiektów docelowych z opcjonalnymi specyfikatorami właściwości dla warstw.

appverif -enable LAYER ... -for TARGET ... [-with [LAYER].PROPERTY=[VALUE] …] appverif -disable LAYER ... -for TARGET ... appverif -query LAYER ... -for TARGET ... appverif –configure STOP ... -for TARGET ... [-with STOPPROPERTY=[VALUE] …]

gdzie:

LAYER to standardowa nazwa warstwy weryfikacji. Jeśli jest zainstalowany nowy dostawca weryfikatora, spowoduje to uwidocznienie nowej nazwy warstwy weryfikacji do użycia w wierszu polecenia. Przykładowe warstwy to sterta, uchwyty lub blokady.

Możesz ustawić wartość LAYER na * , aby określić, że polecenie ma zastosowanie do wszystkich warstw.

TARGET to nazwa binarna (np. notepad.exe). Jest to ustawienie statyczne, które jest utrwalane w rejestrze i będzie brane pod uwagę przy każdym uruchomieniu aplikacji. W przypadku polecenia appverif –disable można ustawić wartość TARGET na * w celu określenia, że wszystkie obiekty docelowe powinny być wyłączone.

WŁAŚCIWOŚĆ to nazwa właściwości specyficzna dla warstwy wymienionej w wierszu polecenia. Na przykład warstwa Handles ma ślady jako właściwość.

VALUE jest wartością właściwości . Typ wartości zależy od typu skojarzonego z właściwością i zostanie wymuszony. Obsługiwane typy to teraz: wartość logiczna (prawda/fałsz), liczba całkowita (dziesiętna/ósemkowa/szesnastkowa w notacji C), ciąg i wiele ciągów (zawierających \0’ between strings and being terminated by \0\0'). Jeśli wartość nie jest określona, oznacza to, że użytkownik chce usunąć właściwość i przywrócić zachowanie do wartości domyślnej właściwości.

STOP to liczba (dziesiętna lub szesnastkowa w notacji C) problemu zatrzymania weryfikatora do skonfigurowania. Kody zatrzymania muszą być unikatowe (żadne dwie warstwy nie mogą używać tego samego kodu zatrzymania, dlatego samo narzędzie określi warstwę, do której należy zatrzymanie)

STOPPROPERTY to nazwa właściwości, która jest akceptowalna dla zatrzymań weryfikatora. Jeśli wartość nie zostanie określona, zakłada się, że właściwość musi zostać usunięta. Dozwolone właściwości zatrzymania to (zobacz Konfigurowanie zatrzymań weryfikatora poniżej, aby uzyskać więcej informacji):

• Raport o błędach
• Dotkliwość
• Smak

Właściwości mogą być opcjonalnie kwalifikowane przez warstwę, do której należą. Nie jest to jednak konieczne, jeśli wiersz polecenia włącza tylko jedną warstwę. Aby na przykład włączyć dwie warstwy o nazwach X i Y dla test.exe docelowych z właściwościami X.DebugLevel i Y.DebugLevel, polecenie to:

appverif –enable X Y –for test.exe –with X.DebugLevel=1 Y.DebugLevel=2

Jeśli jednak warstwa X jest włączona, można użyć niekwalifikowanej nazwy właściwości:

appverif –enable X –for test.exe –with DebugLevel=1

Znak separatora między nazwą właściwości a wartością może być = (znak równości) lub : (dwukropek).

Różne polecenia

appverif –query providers

appverif –delete logs –for TARGET ...

appverif –delete settings –for TARGET ...

Wyczyść całkowicie element TARGET z rejestru.

appverif –stamp log –for Target –with Stamp=”LOG_STAMP”[Log= RELATIVE_TO_LAST_INDEX]

To polecenie spowoduje oznaczenie dziennika LOG_STAMP. Ta sygnatura jest przydatna do identyfikowania tylko sekcji dziennika jako istotnej podczas wyświetlania dziennika w formularzu XML.

appverif –export log –for TARGET –with To=XML_FILE[Symbols=SYMBOL_PATH][Stamp=LOG_STAMP][StampTo=LOG_STAMP][Log=RELATIVE_TO_LAST_INDEX]

Powyższe polecenie spowoduje wyeksportowanie dziennika binarnego do pliku XML. Opcjonalna właściwość Stamp służy do identyfikowania, która część dziennika powinna zostać wyeksportowana do formatu XML. Jeśli nie zostanie określony, cały dziennik zostanie przekonwertowany. Właściwość Log ma ujemną liczbę całkowitą jako możliwą i określa, jaki plik dziennika należy przekonwertować, zaczynając od ostatniego (zakłada się, że właściwość nie istnieje). Na przykład uruchom notepad.exe trzy razy z rzędu. Aby uzyskać dostęp do pierwszego utworzonego dziennika, określ wartość Log=-2 w wierszu polecenia.

Skróty dla wiersza polecenia

Poniżej przedstawiono skróty:

appverif /verify TARGET [/faults [PROBABILITY [TIMEOUT [DLL …]]]]

gdzie:

Element TARGET ma takie samo znaczenie, jak opisano powyżej.

PRAWDOPODOBIEŃSTWO jest prawdopodobieństwem wstrzykiwania błędów. Musi być wartością w zakresie 0..1000000. Jeśli nie określono wartości domyślnej to 5%.

TIMEOUT to interwał czasu w milisekundach podczas uruchamiania procesu, gdy nie ma iniekcji błędów. Jest to wykonywane w celu umożliwienia prawidłowego uruchomienia procesu przed występowaniem błędów. Jeśli nie określono wartości to 500 ms.

BIBLIOTEKA DLL to nazwa modułu, który jest ładowany w procesie. Zazwyczaj jest to nazwa biblioteki dynamicznej (rozszerzenie .dll), ale może to być activeX (rozszerzenie ocx) lub inny moduł ładowalny.

Przykłady:

appverif /verify notepad.exe /faults 100000 1000 msvcrt.dll

Włącz iniekcję błędów dla notepad.exe (za każdym razem, gdy zostanie uruchomiona). Błędy powinny wystąpić z prawdopodobieństwem 10%, tylko 1000 ms po uruchomieniu procesu i tylko dla operacji zainicjowanych z msvcrt.dll.

Włączanie szczegółów iniekcji błędów

Użycie /faults wiersza polecenia włączy wstrzyknięcie błędów tylko dla OLE_ALLOC i HEAP_ALLOC. Można jednak użyć wiersza polecenia, aby skonfigurować typ iniekcji błędów, który chcesz włączyć. Jeśli na przykład chcesz wstrzyknąć błąd do rejestru lub interfejsu API plików jako 2%, użyj wiersza polecenia:

appverif -enable lowres -for hello.exe -with registry=20000 file=20000

Inny przykład:

appverif -query lowres -for hello.exe

Settings for hello.exe:
Test [lowres] enabled.

Include = *
Exclude =
TimeOut = 2000 (0x7D0)
WAIT = 0 (0x0)
HEAP_ALLOC = 20000 (0x4E20)
VIRTUAL_ALLOC = 0 (0x0)
REGISTRY = 20000 (0x4E20)
FILE = 20000 (0x4E20)
EVENT = 0 (0x0)
MAP_VIEW = 0 (0x0)
OLE_ALLOC = 20000 (0x4E20)
STACKS = false

Konfigurowanie zatrzymania weryfikatora

Za pomocą wiersza polecenia (lub interfejsu użytkownika) można skonfigurować zatrzymania weryfikatora. Poniżej przedstawiono przykłady wykorzystania:

Appverif -configure STOP ... -for TARGET ... -with PROPERTY=VALUE ...

Stop to kod zatrzymania, taki jak 0x200 0x201

TARGET to nazwa aplikacji, taka jak foo.exe

WŁAŚCIWOŚĆ może być jedną z wartości "ErrorReport", "Ważność" i "Flavor"

W przypadku elementu ErrorReport wartość może być kombinacją następujących wartości.

0x00000001 oznacza, że zatrzymanie jest aktywne. (Jeśli ten bit ma wartość zero, oznacza to, że zatrzymanie jest wyłączone)

0x00000020 oznacza, że przerwanie w debugerze przy użyciu punktu przerwania.

0x00000040 oznacza przerwanie debugera przez wygenerowanie wyjątku weryfikatora.

0x00000080 oznacza, że zatrzymanie zostanie zarejestrowane w pliku dziennika.

0x00000100 oznacza, że ślad stosu dla tego zatrzymania zostanie zarejestrowany w pliku dziennika.

W przypadku ważności wartość może być jedną z następujących wartości.

0x00000003 zatrzymanie informacyjne.

0x0000000F ostrzeżenie.

0x0000003F błąd.

Dla parametru Flavor wartość może być kombinacją następujących wartości.

0x00000002 niewstrzymalny przystanek.

0x00000010 ten przystanek będzie wyświetlany tylko raz. Zostanie on zignorowany w następnym czasie w ramach przebiegu testu.

Na przykład wyłącz 0x2700, 0x2701 dla foo.exe

Appverif –configure 0x2700 0x2701 –for foo.exe –with ErrorReport=0

Skonfiguruj kod zatrzymania 0x2700 jako włamanie do debugera (domyślnie jest wyłączony), zapisywanie dziennika bez śladu stosu i uniemożliwianie jego ciągłego śledzenia

Appverif –configure 0x2700 –for foo.exe –with ErrorReport=0xA1 Flavor=0x2

Opcje zatrzymania weryfikatora — ustawienia zaawansowane

Weryfikator aplikacji ma zaawansowane ustawienia, takie jak Inactivate, które można zmienić na zatrzymanie weryfikatora.

Opcje zatrzymania weryfikatora dostępu — opcje zatrzymania weryfikatora są zmieniane w oknie dialogowym z listą dostępnych opcji. Aby uzyskać dostęp do opcji zatrzymania weryfikatora:

1. Wybierz nazwę testu w okienku Testy.
2. W menu Edycja wybierz pozycję Opcje zatrzymania weryfikatora lub kliknij prawym przyciskiem myszy test i wybierz pozycję Opcje zatrzymania weryfikatora.

Opcje zatrzymania weryfikatora

Możesz zmienić następujące elementy na zatrzymanie weryfikatora wymienione przez kliknięcie kodu zatrzymania (zwróć uwagę, że po kliknięciu zostanie wyświetlony opis zatrzymania).

Nieaktywne to pole wyboru, które po wybraniu spowoduje dezaktywowanie uruchamianego kodu zatrzymania weryfikatora.

Ważność określa, w jaki sposób weryfikator powinien zostać oflagowany:

• Ignoruj
• Informacja
• Ostrzeżenie
• Błąd

Raportowanie błędów określa, jak chcesz, aby określony weryfikator przestał być zgłaszany/rejestrowany:

Zaloguj się do pliku — pole wyboru, które po wybraniu spowoduje zalogowanie się do wyznaczonego pliku.

Śledzenie stosu dzienników — pole wyboru, które po wybraniu spowoduje zarejestrowanie śladów stosu, gdy są dostępne.

Brak przerwy — opcja nie przerywania debugera.

Wyjątek — opcja bez przerwania i punktu przerwania

Punkt przerwania — opcja bez przerwania ani wyjątku.

Różne dostępne są dwie opcje

Zatrzymaj raz — pole wyboru, które po wybraniu zostanie zatrzymane tylko po wystąpieniu tego błędu podczas testowania aplikacji.

Nie można kontynuować — pole wyboru, które po wybraniu nie pozwoli na kontynuowanie bez badania.

Zobacz też

Application Verifier — omówienie

Application Verifier — funkcje

Application Verifier — testy w Weryfikatora aplikacji

Application Verifier — kody zatrzymania i definicje

Application Verifier — debugowanie weryfikatora aplikacji zatrzymuje

Application Verifier — często zadawane pytania