Application Verifier (Windows 7 und Windows Server 2008 R2 Application Quality Cookbook)

  • Artikel

Betroffene Plattformen

Clients – Windows XP, Windows Vista, Windows 7
Server – Windows Server 2003, Windows Server 2008, Windows Server 2008 R2

Beschreibung

Förderung und Durchsetzung des Application Verifier als Qualitätssicherungsinstrument für die gesamte Entwicklung. Es umfasst mehrere Verbesserungen:

  • Wir haben zusätzliche Überprüfungen bereitgestellt, um Probleme zu beheben, die das Windows-Fehlerberichterstattungsteam während der Threadpoolnutzung entdeckt hat.
  • Wir haben 32- und 64-Bit-Versionen des Pakets kombiniert, um den Änderungen in Windows 7 Rechnung zu tragen, einschließlich der Notwendigkeit, 32-Bit-Komponenten unter einer 64-Bit-Version von Windows zu testen, sowie zur allgemeinen Vereinfachung.
  • Wir haben zusätzliche Überprüfungen für Multithreading-Anwendungen, die Ausführung von 32-Bit-Anwendungen unter 64-Bit-Windows sowie viele Fehlerkorrekturen eingebaut.

Diese Änderungen sollten keine negativen Auswirkungen auf Benutzer haben, welche die Thread-Überprüfungen nicht aktivieren. Diejenigen, die dies tun, sollten zusätzliche Unterstützung bei der Erkennung und Diagnose bestehender Probleme bei der Threadpoolnutzung erhalten. Unabhängig davon, ob Sie die Thread-Überprüfung aktivieren oder nicht, werden Sie von den anderen Verbesserungen und Fehlerbehebungen in diesem Dienst profitieren.

Bei der Nutzung dieses Dienstes kommt es zwar zu einer leichten Leistungseinbuße, doch sollte die Leistung akzeptabel bleiben, da er normalerweise nicht in Einzelhandelsumgebungen eingesetzt wird.

Verwendung

Allgemeine Informationen

So stellen Sie zuverlässige Windows-Anwendungen bereit:

  1. Testen Sie Anwendungen, die in nicht verwalteten (systemeigenen) Code mit Application Verifier unter dem Debugger und mit ganzseitigem Heap geschrieben wurden, bevor Sie diese für Kunden freigeben.
  2. Führen Sie die von Application Verifier bereitgestellten Schritte aus, um fehlerhafte Bedingungen zu beheben.
  3. Sobald Ihre Anwendung freigegeben ist, überwachen Sie regelmäßig die von der Windows-Fehlerberichterstattung erfassten Berichte über Anwendungsfehler.

Threadpoolüberprüfungen sind standardmäßig unter der Überschrift „Grundlagen“ aktiviert. Da dies in der Standardeinstellung enthalten ist, müssen die Benutzer nur Application Verifier mit den Standardeinstellungen für ihren Code ausführen, um die neuen Überprüfungen zu nutzen.

Details

Zumindest sollten Sie Application Verifier mit der Einstellung „Grundlagen“ ausführen. Dies ist für WinLogo und WinQual erforderlich. Die Einstellung „Grundlagen“ überprüft Folgendes:

  • Details zum Beenden von Ausnahmen – Stellt sicher, dass Anwendungen Zugriffsverletzungen nicht mithilfe der strukturierten Ausnahmebehandlung ausblenden
  • Handles-Beendigungsdetails – Tests, um sicherzustellen, dass die Anwendung nicht versucht, ungültige Handles zu verwenden
  • Heaps-Beendigungsdetails – Prüft auf Probleme mit Speicherbeschädigungen im Heap
  • Details zum Eingabe-/Ausgabestopp – Überwacht die Ausführung asynchroner E/A-Geräte und führt verschiedene Überprüfungen durch
  • Leak-Beendigungsdetails – Erkennt Lecks, indem die Ressourcen einer DLL nachverfolgt werden, die nicht zum Zeitpunkt des Entladens der DLL freigegeben wurden
  • Lock-Beendigungsdetails – Überprüft die richtige Verwendung für kritische Bereiche
  • Details zum Speicherstopp – Stellt sicher, dass APIs für Manipulationen im virtuellen Raum ordnungsgemäß verwendet werden (z. B. VirtualAlloc, MapViewOfFile)
  • TLS-Beendigungsdetails – Stellt sicher, dass Thread local Storage APIs ordnungsgemäß verwendet werden
  • Threadpool-Stoppdetails – Stellt die korrekte Verwendung von Threadpool-APIs sicher und erzwingt Konsistenzprüfungen für Workerthreadzustände nach einem Rückruf

Wenn Ihre Anwendung von einer „Pre-Vista“-Anwendung migriert wird, sollten Sie die „LuaPriv“ (auch als UAC-Prüfungen bezeichnet) nutzen. Der Benutzerkontensteuerungsrecht-Prädiktor (Limited User Account Privilege Predictor, LuaPriv) hat zwei Hauptziele:

  • Prädiktiv: Beim Ausführen einer Anwendung mit Administratorrechten können Sie vorhersagen, ob diese Anwendung auch dann funktioniert, wenn sie mit weniger Berechtigungen ausgeführt wird (im Allgemeinen als normaler Benutzer). Wenn die Anwendung beispielsweise in Dateien schreibt, auf die nur Administratoren zugreifen können, kann diese Anwendung nicht in dieselbe Datei schreiben, wenn sie nicht als Administrator ausgeführt wird.
  • Diagnose: Identifizieren Sie potenzielle Probleme, die möglicherweise bereits bei der aktuellen Ausführung vorhanden sind, während sie mit Nicht-Administratorrechten ausgeführt werden. Wenn die Anwendung versucht, in eine Datei zu schreiben, auf die nur Mitglieder der Gruppe „Administrator“ Zugriff haben, erhält sie einen ACCESS_DENIED-Fehler. Wenn die Anwendung nicht ordnungsgemäß funktioniert, kann dieser Vorgang der Grund dafür sein.

LuaPriv identifiziert die folgenden Arten von Problemen:

Potenzielle Probleme Beschreibung
Eingeschränkte Namespaces Das Erstellen eines benannten Synchronisierungsobjekts (Event, Semaphore, Mutex usw.) ohne einen Namespace kann die Ausführung ohne Berechtigungen auf einigen Betriebssystemen erschweren, da das Betriebssystem das Objekt möglicherweise in einem eingeschränkten Namespace platzieren möchte. Zum Erstellen eines solchen Objekts in einem eingeschränkten Namespace (z. B. dem globalen Namespace) ist SeCreateGlobalPrivilege erforderlich, das nur Administratoren gewährt wird.
LuaPriv kennzeichnet beide Probleme, wenn sie erkannt werden.
Strenge Administratorüberprüfungen Einige Anwendungen fragen das Sicherheitstoken des Benutzers ab, um herauszufinden, wie viele Berechtigungen er/sie hat. In diesen Fällen kann die Anwendung ihr Verhalten ändern, je nachdem, welche Befugnisse sie beim Benutzer vermutet.
LuaPriv kennzeichnet API-Aufrufe, die diese Informationen zurückgeben.
Anfordern von Berechtigungen Eine Anwendung kann versuchen, eine sicherheitsrelevante Berechtigung (z. B. SeTcbPrivilege oder SeSecurityPrivilege) zu aktivieren, bevor sie einen Vorgang ausführt, der dies erfordert.
LuaPriv kennzeichnet Versuche, sicherheitsrelevante Berechtigungen zu aktivieren.
Fehlende Berechtigungen Wenn eine Anwendung versucht, eine Berechtigung zu aktivieren, die der Benutzer nicht hat, signalisiert sie wahrscheinlich, dass die Anwendung die Berechtigung erwartet, was zu Verhaltensunterschieden führen kann.
LuaPriv kennzeichnet fehlgeschlagene Berechtigungsanfragen.
INI-Dateivorgänge Versuche, in zugeordnete INI-Dateien (WritePrivateProfileSection und ähnliche APIs) zu schreiben, können als Nicht-Administratorbenutzer fehlschlagen.
LuaPriv kennzeichnet solche Vorgänge.
Zugang verweigert Wenn die Anwendung versucht, auf ein Objekt zuzugreifen (Datei, Registrierungsschlüssel usw.), aber der Versuch aufgrund eines unzureichenden Zugriffs fehlschlägt, erwartet die Anwendung wahrscheinlich, dass sie mit mehr Berechtigungen ausgeführt wird, als sie hat.
LuaPriv kennzeichnet Objekt-Öffnungsversuche, die mit ACCESS_DENIED und ähnlichen Fehlern fehlschlagen.
AcEs verweigern Wenn ein Objekt ACEs in seiner DACL verweigert, verweigert es explizit den Zugriff auf bestimmte Entitäten.
Dies ist ungewöhnlich und macht die Vorhersage schwierig, daher kennzeichnet LuaPriv ACEs, wenn sie gefunden werden.
Zugriff eingeschränkt Wenn eine Anwendung versucht, ein Objekt mit Rechten zu öffnen, die normalen Benutzern nicht gewährt werden (z. B. wenn versucht wird, in eine Datei zu schreiben, die nur von Administratoren geschrieben werden kann), dann funktioniert die Anwendung wahrscheinlich nicht so, wenn sie unter einem normalen Benutzer ausgeführt wird.
LuaPriv kennzeichnet solche Vorgänge.
MAXIMUM_ALLOWED Wenn eine Anwendung ein Objekt für MAXIMUM_ALLOWED öffnet, erfolgt die tatsächliche Zugriffsüberprüfung für das Objekt an anderer Stelle. Der meiste Code, der dies tut, funktioniert nicht korrekt und wird mit ziemlicher Sicherheit anders funktionieren, wenn er ohne Berechtigung ausgeführt wird.
LuaPriv kennzeichnet somit alle Vorfälle von MAXIMUM_ALLOWED.

 

Häufig übersehene Probleme werden in den nebulösen Fehlprüfungen erfasst:

  • Beendigungsdetails gefährlicher APIs
  • Details zum Beenden von Dirty Stacks
  • Zeitrollover

Wir haben eine neue Print Verifier hinzugefügt. Diese Schicht hilft bei der Suche und Behebung von Problemen, die beim Aufruf des Drucksubsystems durch eine Anwendung auftreten können. Print Verifier zielt auf die beiden Schichten des Druck-Subsystems, die PrintAPI-Schicht und die PrintDriver-Schicht.

Druck-API-Schicht

Print Verifier testet die Schnittstelle zwischen einem Programm und Winspool.drv und prntvpt.dll und testet die Schnittstellen dieser DLLs. Sie können die Regeln für den Aufruf von Funktionen in dieser Schnittstelle im MSDN-Hilfeabschnitt für APIs, die von winspool.drv und prntvpt.dll exportiert werden, überprüfen.

Drucktreiberschicht

Print Verifier testet auch die Schnittstelle zwischen einem zentralen Druckertreiber wie UNIDRV.DLL, UNIDRUI.DLL, PSCRIPT5.DLL, PS5UI.DLL oder MXDWDRV.DLL und den Druckertreiber-Plug-ins. Informationen zu dieser Schnittstelle finden Sie in MSDN und WDK.

Beachten Sie, dass einige dieser Überprüfungen nur für Windows 7 gelten und andere einfach unter Windows 7 besser funktionieren.

Normalerweise führen nur Debug-Versionen den Application Verifier aus, so dass die Leistung im Allgemeinen kein Problem darstellt. Wenn bei der Verwendung dieser oder einer anderen Application Verifier-Prüfung Leistungsprobleme auftreten, führen Sie eine Überprüfung nach der anderen durch, bis Sie alle erforderlichen Überprüfungen durchgeführt haben.

Nahezu 10 % der Anwendungsabstürze auf Windows-Systemen sind auf eine Beschädigung des Heaps zurückzuführen. Diese Abstürze sind im Nachhinein fast unmöglich zu beheben. Am besten lassen sich diese Probleme vermeiden, wenn Sie mit den Page Heap-Funktionen von Application Verifier testen. Es gibt zwei Varianten von Page Heap: „Vollständig“ und „Leicht.“ „Vollständig“ ist der Standard. Er zwingt den Debugger zum sofortigen Anhalten, wenn er eine Beschädigung entdeckt. Diese Funktion muss während des Debuggers ausgeführt werden. Es ist jedoch auch die anspruchsvollste Ressource. Wenn ein Benutzer Probleme mit der Anzeigedauer hat und bereits ein Szenario unter „Vollständigem“ Page Heap ausgeführt hat, wird die Einstellung auf „Leicht“ diese Probleme wahrscheinlich beheben. Darüber hinaus stürzt Light Page Heap erst ab, wenn der Prozess beendet wird. Es liefert zwar der Speicherbelegung eine Stapelüberwachung, aber die Diagnose kann erheblich länger dauern als bei der Verwendung des vollständigen Gegenstücks.

Überwachen Sie den Zuverlässigkeitszustand der Anwendungen über das Winqual-Webportal. Dieses Portal zeigt die Fehlerberichte, welche über die Windows-Fehlerberichterstattung erhoben werden, sodass es einfach ist, die am häufigsten auftretenden Fehler zu erkennen. Weitere Informationen hierzu finden Sie unter Windows-Fehlerberichterstattung: Erste Schritte. Microsoft erhebt für diesen Dienst keine Gebühren.

Um WinQual nutzen zu können:

  1. Registrieren Sie Ihr Unternehmen für WinQual, für das eine VeriSign-ID erforderlich ist. Informationen zu WinQual für Windows 7 finden Sie im Entwicklerportal unter Windows Vista SP1\Windows Server 2008. Es verfügt bald über einen Windows 7-Speicherort.
  2. Ordnen Sie die ISV-Anwendungen einem Produktnamen und dem ISV-Namen zu, der die Fehlerberichte mit dem Unternehmen verknüpft. Andere ISVs können Ihre Fehlerberichte nicht anzeigen.
  3. Verwenden Sie das Portal, um die wichtigsten Probleme zu identifizieren. ISVs können auch Antworten erstellen, die Kunden darüber informieren, welche Schritte nach einem Fehler zu unternehmen sind. Das Antwortsystem unterstützt weltweit mehr als 10 Sprachen.

Ein weiterer Hinweis: Application Verifier ist nur so gut wie die Codepfade, für die Sie ihn ausführen. Der Wert der Kombination dieses Tools mit einem Code Coverage Tool kann nicht hoch genug eingeschätzt werden.

Debuggingtools für Windows:

Application Verifier:

WinQual: