Svchost.exe exécute NSI service des fuites de mémoire et la fuite de mémoire non paginée balise NSpc

Scénario 1

Si une application, tel que ping.exe force arrêté, il est possible que la fonction de IcmpCloseHandle n’est pas appelé. Dans ce cas, le service NSI peut détecter qu’un client est disponible. Par conséquent, le service s’envoyer une notification sur tous les messages ICMP. Dans la mesure où le client n’existe pas, la liste de notification continue à augmenter. La liste ne pas obtenir nettoyée jusqu'à ce que le service NSI est arrêté.

Pour envoyer une commande ping, vous devez ouvrir la poignée ICMP et ensuite utiliser les autres fonctions d’assistance IP pour envoyer et recevoir des données ICMP :

Fonction de IcmpCreateFile

Fonction de ICMPCreateFile

Fonction de IcmpSendEcho2Ex

Une fois que l’application envoie la commande ping, il doit appeler la fonction de IcmpCloseHandle pour fermer le handle ICMP.

Scénario 2

Un développeur crée une application pour envoyer et recevoir des messages ICMP à l’aide de IPHlelper APIs. Si seule une poignée ICMP est utilisée pour envoyer des messages ICMP pour plusieurs clients et dans ce cas le fait à un débit très élevé, l’API les qui est averti de la réception d’un message ne peut pas maintenir la vitesse. Dans ce cas, vous remarquez que la mémoire du service NSI continue à croître de manière exponentielle. En outre, vous constatez une utilisation élevée de l’UC par le service NSI (nsisvc.dll).

Scénario 3

Vous avez une application ou un service qui utilise des fonctions d’assistance des IPdirectement ou indirectement. L’application s’arrête ou est arrêté, et elle ne se ferme pas correctement lors de chaque enregistrement de notification n’est pas annulé (CancelMibChangeNotify2). Dans ce cas, le serveur NSI conserve l’enregistrement en attente pour le processus est arrêté. S’il existe plusieurs instances de l’arrêt de l’application, le service NSI aura de nombreux enregistrements en attente. Un état d’async RPC et d’autres informations est maintenu pour chaque enregistrement. Cela ajoute à l’utilisation de la mémoire. En règle générale, ces enregistrements sont effectuées pour une modification de l’interface ou d’une modification de l’adresse Unicast IP. Si aucune modification n’est à l’état, ces enregistrements sont conservés.

Les fonctions de Notification suivantes sont utilisées pendant le processus d’inscription :

• NotifyAddrChange 

• NotifyIpInterfaceChange 

• NotifyRouteChange 

• NotifyRouteChange2 

• NotifyUnicastIpAddressChange

La raison que de nombreuses applications ne pas appeler (CancelMibChangeNotify2) ou arrêter le processus est décrit dans la rubrique de fonction de NotifyIpInterfaceChange sur le site Web de Microsoft Developer Network.

Après l’appel de la fonction de NotifyIpInterfaceChange pour vous inscrire pour les notifications de modifications, ces notifications continueront d’être envoyées jusqu'à ce que l’application annule l’inscription pour recevoir des notifications de modification ou de l’arrêt de l’application. Si l’application s’arrête, le système annule automatiquement toute inscription pour les notifications de modification. Nous vous recommandons de configurer une application explicitement, annuler son enregistrement pour les notifications de modification avant de s’arrêter.

Pour toute inscription pour la notification, vous apportez également allouer de la mémoire non paginée (NPP) de la laBalise de NSpc.

Informations sur le correctif logiciel

Un correctif pris en charge est disponible auprès du Support Microsoft. Toutefois, ce correctif vise à corriger uniquement le problème décrit dans cet article. Appliquez ce correctif uniquement aux systèmes qui rencontrent le problème décrit dans cet article. Ce correctif va peut-être subir des tests supplémentaires. Par conséquent, si vous n'êtes pas sérieusement concerné par ce problème, nous vous recommandons d'attendre la prochaine mise à jour logicielle qui contiendra ce correctif.

Si le correctif est disponible pour le téléchargement, il existe une section « Téléchargement de correctif logiciel disponible » au début de cet article de la Base de connaissances. Si cette section n'apparaît pas, contactez le Service clientèle et Support de Microsoft pour obtenir le correctif.

Remarque Si des problèmes supplémentaires se produisent ou si des procédures de dépannage sont nécessaires, vous devrez peut-être formuler une demande de service distincte. Les coûts habituels du support technique s'appliqueront aux questions et problèmes qui ne relèvent pas de ce correctif logiciel. Pour une liste complète des numéros de téléphone service clientèle de Microsoft ou pour créer une demande de service distincte, accédez au site Web de Microsoft suivant :

http://support.microsoft.com/contactus/?ws=support

Remarque Le formulaire « Téléchargement de correctif logiciel disponible » affiche les langues pour lesquelles le correctif est disponible. Si vous ne voyez pas votre langue, c'est parce qu'il n'y a pas de correctif disponible pour cette langue.

Solution de contournement

Pour contourner ce problème, utilisez une des solutions de contournement suivantes en fonction de votre situation.

Solution de contournement pour le scénario 1

Assurez-vous que l’application, tels que ping.exe, n’est pas arrêtée force. Au lieu de cela, laissez l’application normalement arrêt.

Vous pouvez également mettre à niveau vers Windows Server 2012. Ce problème est résolu dans Windows Server 2012. Ce correctif empêche le service NSI à partir d’une fuite de mémoire, quelle que soit la façon dont l’application est arrêtée.

Solution de contournement pour le scénario 2

Un développeur logiciel doit créer plusieurs handles ICMP pour envoyer des requêtes ICMP. Si vous devez envoyer un grand nombre de paquets ICMP, utilisez des sockets bruts et directement envoyer et recevoir des paquets ICMP sur le socket brut. Vous obtiendrez des performances plus rapides.

Solution de contournement pour un scénario 3

Dans ce scénario, si vous désactivez et activez la carte réseau, l’utilisation de la mémoire immédiatement réduit mais a un court pic d’utilisation du processeur.

Cela se produit car lorsqu’une modification se produit dans l’adresse IP ou l’interface, le service NSI est informé par le noyau. Le service NSI essaie ensuite d’indiquer tous les clients qui sont inscrits pour la notification. Lorsque le service tente de notifier un processus client qui n’existe pas, le RPC signale une erreur. Par conséquent, le service NSI supprime toutes les informations d’état qui a été enregistrées pour ce processus client. Après cela, cette mémoire est libérée.

Dans ce cas, plusieurs centaines de milliers notifications sont enregistrées. Une fois que l’événement se produit, toute la mémoire pour ces clients non valides est libérée.

Ce problème est résolu dans Windows 8.