Problembehandlung und Debuggen von Netzwerkverbindungen (Windows-Runtime-Apps)

  • Artikel

[ Dieser Artikel richtet sich an Windows 8.x- und Windows Phone 8.x-Entwickler, die Windows-Runtime-Apps schreiben. Wenn Sie für Windows 10 entwickeln, finden Sie weitere Informationen unter neueste Dokumentation]

Netzwerkprobleme können dazu führen, dass Apps nicht mehr reagieren oder abstürzen. Es kann auch passieren, dass den Benutzern Dialogfelder, in denen keine Aktionen möglich sind, und verwirrende Fehlermeldungen angezeigt werden. Das Behandeln und Debuggen dieser Fehler kann sich als schwierig erweisen, da sie überall im Netzwerkstapel auftreten können.

Welche Apps sind davon betroffen?

Alle Windows-Runtime-Apps, die das Netzwerk direkt (z. B. mit Sockets) oder indirekt (mit einer API, die das Netzwerk irgendwann verwendet) nutzen, sind potenziell von Netzwerkproblemen betroffen. Im Idealfall behandelt das Betriebssystem Fehler automatisch im Auftrag der App. Sollte dies nicht funktionieren, müssen Apps Fehler selbst behandeln können.

Auswählen der richtigen Netzwerkfunktionen

Damit eine Windows-Runtime-App auf das Netzwerk zugreifen kann, müssen bestimmte Netzwerkisolationsfunktionen im Manifest der App aktiviert werden. Diese Funktionen werden normalerweise beim Entwickeln der App mit Microsoft Visual Studio 2013 konfiguriert. Die Verwendung dieser Funktionen wird von Windows erzwungen. Falls die entsprechende Netzwerkfunktion nicht aktiviert wurde, wird der Netzwerkzugriff u. U. blockiert.

Beim Behandeln von Netzwerkproblemen überprüfen Sie daher als Erstes, ob die richtigen Netzwerkfunktionen für die App konfiguriert wurden.

Netzwerkfunktion Beschreibung

privateNetworkClientServer

  • Hierbei handelt es sich in der Regel um ein privates "Profil", das das lokale Subnetz und eine Loopbackfunktion enthält. In einer Unternehmensumgebung würde dieses Profil das lokale Subnetz und außerdem den Active Directory-Standort bzw. die Active Directory-Domäne enthalten.

  • Durch das Aktivieren dieser Einstellung geben Sie, dass eine App für die Verwendung in einem privaten Heimnetzwerk oder einem privaten Netzwerk am Arbeitsplatz vorgesehen ist.

internetClient

  • Diese Funktion ermöglicht die Kommunikation mit Diensten im Internet (ggf. über einen Proxy). Diese Funktion ähnelt "internetClientServer", der einzige Unterschied besteht darin, dass die gesamte Kommunikation vom Client initiiert werden muss. Der Client lauscht nicht auf Verbindungen von anderen Hosts. Verbindungen mit dem lokalen Subnetz oder Loopback sind nicht zulässig.

internetClientServer

  • Diese Funktion ermöglicht die Kommunikation mit Diensten im Internet (ggf. über einen Proxy). Sie ermöglicht sowohl eingehende Konnektivität/Erreichbarkeit vom Internet als auch vom Client initiierte ausgehende Vorgänge.

Hinweis  Diese Funktion ermöglicht die eingehende Kommunikation zwar, garantiert sie aber nicht. Die eingehende Kommunikation kann in einem Unternehmensnetzwerk immer noch durch Edgeproxys und Firewalls blockiert werden.
 

Näherung

Diese Funktion ermöglicht es zwei PCs, die sich in unmittelbarer Nähe befinden (max. 30 cm), mithilfe der Windows.Networking.Proximity-Namespacefeatures miteinander zu kommunizieren.

 

Nachdem Sie den erforderlichen Netzwerkzugriff für die App bestimmt haben, müssen Sie sicherstellen, dass die entsprechenden Netzwerkfunktionen konfiguriert wurden. Andernfalls wird der Netzwerkzugriff blockiert.

Informationen zum Aktivieren von Loopback für den Netzwerkzugriff und zum Behandeln von Netzwerkisolationsproblemen finden Sie unter Aktivieren von Loopback und Debuggen der Netzwerkisolation.

Reagieren auf Änderungen des Netzwerkstatus

Wenn Windows 8.1, Windows Phone 8.1 oder Windows Server 2012 R2 neue Netzwerke erkennt, werden automatisch neue Konnektivitätsoptionen bereitgestellt. Falls ein Benutzer z. B. sein 3G-Netzwerk benutzt, um Daten zu streamen, und später in die Reichweite eines WLAN-Netzwerks kommt, ist die neue Konnektivitätsoption für die App verfügbar, sofern dies sinnvoll ist.

In einem Szenario mit mobilen Geräten können Verbindungen mit Netzwerken laufend aufgebaut und getrennt werden. Die Reichweite eines 3G-Netzwerks könnte am Wohn- oder Arbeitsort eines Benutzers verlassen werden, während WiFi weiterhin verfügbar ist. Ebenso könnte ein WiFi-Netzwerk nicht mehr erreichbar sein, wenn ein Benutzer seine Wohnung oder seinen Arbeitsplatz verlässt. Darüber hinaus kann es vorkommen, dass gelegentlich kein Netzwerk verfügbar ist. Angesichts der Verbreitung von WiFi und mobilen Breitbandnetzwerken treten solche Netzwerkänderungen (Netzwerke werden zugänglich, Verbindungen werden getrennt, oder es ist kein Netzwerk verfügbar) sehr häufig auf. Das Umschalten von Verbindungen zu einem neuen Netzwerk erfolgt nicht automatisch nahtlos; hierbei ist das Eingreifen der Anwendung erforderlich. Beachten Sie, dass gemäß der Standardrichtlinie in Windows 8.1, Windows Phone 8.1 und Windows Server 2012 R2 das uneingeschränkte Netzwerk anstelle des getakteten Netzwerks und das schnellere Netzwerk anstelle des langsameren Netzwerks ausgewählt wird.

Wenn Netzwerkänderungen vorgenommen werden, kann der Netzwerkzugriff davon betroffen sein. Eine App kann für Benachrichtigungen über Änderungen des Netzwerkstatus registriert werden (onNetworkStatusChanged), damit sie benachrichtigt wird, wenn solche Netzwerkänderungen stattfinden. Falls die von der App verwendete Verbindung nicht mehr verfügbar ist (was durch einen Fehler angezeigt wird), muss die App mit einer der folgenden Aktionen reagieren:

  • Sie wiederholt den Vorgang. Sollte dies nicht funktionieren, wartet sie auf eine weitere NetworkStatusChanged-Benachrichtigung.
  • Sie überprüft die Netzwerkkosten und versucht, eine Verbindung mit einem anderen Netzwerk herzustellen.

Grundlegende Richtlinien für die Problembehandlung

Windows-Runtime-Apps müssen die folgenden Aktionen ausführen:

  • Führen Sie bei Auftreten eines Netzwerkfehlers den Vorgang ggf. erneut aus. Der Vorgang sollte z. B. nicht wiederholt werden, wenn die Authentifizierung fehlschlägt. Falls ein Drahtlosnetzwerk, mit dem Sie verbunden waren, nicht mehr angezeigt wird, sollte er dagegen wiederholt werden, weil ein anderes Drahtlosnetzwerk verfügbar sein kann. Viele Fehler verschwinden einfach, wenn der Vorgang wiederholt wird. Befolgen Sie beim Wiederholen des Vorgangs die unter Reagieren auf Änderungen des Netzwerkstatus erläuterten Richtlinien.

  • Vergewissern Sie sich, dass asynchrone APIs verwendet werden, sodass kein Blockieraufruf im UI-Thread erfolgt. Wenn ein Netzwerkvorgang viel Zeit in Anspruch nimmt oder ein Fehler auftritt, sollte dies nicht dazu führen, dass die App nicht mehr reagiert. Emulieren Sie kein synchrones Verhalten zusätzlich zum asynchronen Verhalten der Windows-Runtime.

  • Planen Sie vorab ein Modell für die Behandlung von Fehlern. Überlegen Sie beim Entwerfen der App, wie Fehlerinformationen für Benutzer verfügbar gemacht werden sollen. In Outlook wird beispielsweise eine dezente Netzwerkanzeige verwendet; Communicator verfügt über ein Schema zum Ersetzen der gesamten Benutzeroberfläche; Internet Explorer enthält ein aufgabenorientiertes Dialogfeld für Downloads, in dem Netzwerkfehler angezeigt werden. Fangen Sie Fehler und Ausnahmen ab. Machen Sie sich mit der Bedeutung der Fehlerzeichenfolgen vertraut, und informieren Sie den Benutzer entsprechend.

  • Testen Sie Ihre App in verschiedenen Netzwerkumgebungen mit Aktivitäten wie dem Trennen und erneuten Herstellen der Netzwerkverbindung, Anhalten und Fortsetzen oder Wechseln zwischen Netzwerken.

  • Wenn Sie beim Testen der App Fehler finden, die nicht sofort offensichtlich sind, können Sie die ETW-Ablaufverfolgung aktivieren, um mehr Details zum Problem zu sammeln.

Verwandte Themen

Hinzufügen von Unterstützung für Netzwerke

ETW-Ablaufverfolgung

Konfigurieren von Netzwerkisolationsfunktionen

Aktivieren von Loopback und Debuggen der Netzwerkisolation.