Je suis le créateur d’iolys, un assistant IA pour Visual Studio. Sa page sur le Visual Studio Marketplace fait donc partie des pages que j’ouvre souvent.
C’est en la consultant que j’ai remarqué un comportement étrange : le chargement échouait, puis une redirection automatique était suivie d’un nouvel essai. La page finissait par s’afficher correctement, sans intervention de ma part. Le problème revenait pourtant lors d’autres visites.
Cette instabilité était frustrante, surtout pour une page vers laquelle j’envoyais les utilisateurs d’iolys. L’URL n’avait pas changé, et je n’avais rien modifié dans l’extension qui puisse expliquer ces échecs.
À force de voir la page échouer puis revenir toute seule, j’ai eu envie de me glisser dans la peau d’un enquêteur. Une petite enquête à la Patrick Jane, le héros de The Mentalist, avec des indices à relever, des suspects à examiner et quelques fausses pistes en perspective. Pour le sourire mystérieux, je ferais de mon mieux. Pour les preuves, j’avais des traces réseau.
Au départ, je pensais trouver un problème sur les serveurs de Microsoft. Mon objectif était de comprendre la panne et de leur transmettre un diagnostic utile. J’avais donc déjà un suspect, ce qui était peut-être un peu rapide pour quelqu’un qui venait de s’improviser Patrick Jane. Je ne m’attendais pas à la conclusion qui allait suivre.
Un peu de thé, et l’enquête peut commencer. — Source : Tenor.
Je reprends ici le fil de cette enquête, menée sur mon PC le 29 septembre 2026. Les scripts sont des versions adaptées de mes tests. Les chiffres correspondent à cette installation ; ils ne décrivent pas le comportement du Marketplace pour tous ses utilisateurs.
1. Comprendre pourquoi le chargement de la page est instable
Pour commencer mon enquête façon Patrick Jane, il me fallait reconstituer les faits. Je voyais la page de mon extension commencer à se charger, puis échouer. Après une redirection automatique, elle se chargeait à nouveau et finissait par s’afficher correctement.
L’ensemble pouvait prendre jusqu’à huit secondes, sans que je touche à quoi que ce soit. Je trouvais ce comportement vraiment étrange : pourquoi fallait-il passer par un échec avant de pouvoir accéder à la page ?
Parmi les pistes à explorer, je me suis demandé : les serveurs de Microsoft géraient-ils mal les connexions IPv6 ?
Pour vérifier cette piste, j’ai testé la même URL avec curl, en forçant d’abord les connexions IPv4, puis les connexions IPv6. Je pouvais ainsi comparer les résultats sans dépendre de ce que faisait le navigateur après un échec.
| Connexion | Chargements réussis | Échecs |
|---|---|---|
| IPv4 | 🟢 7 / 7 | 🟢 0 |
| IPv6 | 🟢 1 / 7 | 🔴 6 |
Voici une version simplifiée de ces premiers tests. J’utilise curl.exe pour éviter l’alias curl de Windows PowerShell. Chaque appel lance un nouveau processus et ouvre une nouvelle connexion.
$url = 'https://marketplace.visualstudio.com/items?itemName=iolys.iolys-visual-studio'
foreach ($family in @('-4', '-6')) {
foreach ($attempt in 1..7) {
Write-Host "$family essai=$attempt"
& curl.exe $family --silent --show-error --output NUL `
--connect-timeout 5 --max-time 12 `
--write-out 'http=%{http_code} remote=%{remote_ip} tcp=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' `
$url
Write-Host "curl_exit=$LASTEXITCODE"
}
}
Au-delà du nombre d’échecs, je voulais savoir à quel moment les requêtes s’arrêtaient. Les temps renvoyés par curl, tous mesurés depuis le début de la requête, m’aidaient à suivre leur progression. Je les rapprochais du code de sortie et du message d’erreur.
Quand curl affichait http=000, il n’avait reçu aucun statut HTTP. Ce résultat ne donnait pas, à lui seul, la cause de l’échec. C’était l’erreur associée qui m’aidait à comprendre ce qui s’était passé. Le manuel de curl détaille ces indicateurs.
J’ai également écarté des essais lancés dans un environnement qui bloquait l’accès au réseau. Toutes les destinations y échouaient, quelle que soit la connexion choisie. J’ai repris ces tests sur le même PC, avec l’accès réseau nécessaire : ces restrictions ne devaient pas fausser le diagnostic.
Ces résultats étaient prometteurs : la connexion au Marketplace semblait bien défaillante en IPv6. Dans ma tête, la suite était toute trouvée : contacter Microsoft, leur transmettre mes résultats et voir avec eux comment régler le problème. Affaire classée… ou presque.
Mais je m’étais glissé dans la peau de Patrick Jane. Pas question de désigner un coupable au premier indice ! Avant de contacter Microsoft, je devais avancer dans l’ordre :
- Vérifier si les échecs concernaient uniquement les connexions aux serveurs de Microsoft, en testant d’autres sites en IPv6.
- Si cette piste se confirmait, vérifier ensuite si mon routeur pouvait expliquer ces échecs. Un problème limité à certaines destinations ne suffirait pas à le mettre hors de cause.
2. Google, Cloudflare, Microsoft : tester les connexions IPv6
J’ai d’abord testé la page d’accueil du Marketplace : elle échouait elle aussi en IPv6, avant même que son contenu soit reçu.
La description et les images d’iolys devenaient des causes peu probables. Pour élargir la comparaison, j’ai ensuite essayé plusieurs autres sites.
| Destination | Résultat des essais HTTPS en IPv6 | Ce que cela apporte |
|---|---|---|
| 🟢 3 réussites sur 3 | IPv6 peut fonctionner sur cette machine | |
| Cloudflare | 🟢 3 réussites sur 3 | Une autre destination fonctionne aussi |
| Microsoft.com | 🟠 2 réussites sur 3 | L’échec restant survient après TLS, en attendant HTTP |
| Marketplace | 🔴 Échecs répétés, y compris sur l’accueil | Le problème ne dépend pas de la fiche iolys |
Les résultats étaient contrastés. Google et Cloudflare fonctionnaient, alors qu’un essai sur Microsoft.com dépassait le délai prévu. Cet échec survenait toutefois après la négociation TLS, pendant l’attente de la réponse HTTP. Sur le Marketplace, je voyais plutôt des connexions réinitialisées, ou resets.
Je n’avais donc pas de raison de regrouper tous ces échecs sous une même cause. Je pouvais seulement constater qu’IPv6 fonctionnait vers certaines destinations. Cela laissait ouvertes les pistes d’un problème de chemin réseau ou d’un logiciel intervenant dans les connexions.
Google et Cloudflare avaient un alibi pour ces quelques essais. Mon épisode du Mentalist était pourtant loin du générique : une autre piste restait à examiner.
Et si une seule adresse du Marketplace posait problème ?
Le Marketplace avait plusieurs adresses IP derrière un même nom. Voilà de quoi organiser une petite séance d’identification des suspects. Une seule adresse défaillante aurait pu expliquer les résultats variables ; je les ai donc testées séparément.
| Famille | Adresses observées pendant l’enquête | Réussites | Échecs |
|---|---|---|---|
| IPv4 | 150.171.73.16, 150.171.74.16 |
🟢 10 / 10 | 🟢 0 / 10 |
| IPv6 | 2603:1061:10::16, 2603:1061:10:1::16 |
🟢 3 / 10 | 🔴 7 / 10 |
Les échecs touchaient les deux adresses IPv6. Passer de l’une à l’autre ne réglait donc pas le problème.
Pour imposer une destination, j’ai utilisé l’option --resolve de curl. Elle permet de choisir l’adresse IP tout en conservant le nom du site pour HTTP et TLS, notamment SNI et la vérification du certificat.
Resolve-DnsName marketplace.visualstudio.com -Type AAAA
curl.exe -6 --resolve 'marketplace.visualstudio.com:443:[2603:1061:10::16]' `
--silent --show-error --output NUL --connect-timeout 5 --max-time 12 `
--write-out 'http=%{http_code} tcp=%{time_connect} tls=%{time_appconnect}\n' `
'https://marketplace.visualstudio.com/items?itemName=iolys.iolys-visual-studio'
3. Trouver à quel moment la connexion échoue
À ce stade, je savais que le problème dépassait la fiche iolys et touchait plusieurs adresses IPv6 du Marketplace. Il me restait à comprendre ce qui échouait pendant l’échange.
Bon. À quel moment ça coince ? — Source : Tenor.
Dans les cas habituels, curl renvoyait le code 35 et signalait une connexion réinitialisée. La connexion TCP avait été établie, mais la négociation TLS n’était pas terminée. J’ai d’abord exploré cette piste en imposant TLS 1.2, sans faire disparaître les échecs.
J’ai aussi essayé des requêtes HTTP sans TLS, sur le port 80. Elles échouaient par moments elles aussi. Cela m’a conduit à simplifier encore le test : ouvrir une connexion TCP sur le port 443, ne rien envoyer et attendre une demi-seconde.
$address = [Net.IPAddress]::Parse('2603:1061:10::16')
$client = [Net.Sockets.TcpClient]::new($address.AddressFamily)
try {
$connect = $client.ConnectAsync($address, 443)
if (-not $connect.Wait(4000)) { throw 'Connexion TCP trop longue.' }
if ($client.Client.Poll(500000, [Net.Sockets.SelectMode]::SelectRead)) {
$count = $client.Client.Receive(
[byte[]]::new(1), [Net.Sockets.SocketFlags]::Peek)
Write-Host "Socket lisible ; octets disponibles : $count"
} else {
Write-Host 'Toujours ouverte après 500 ms, sans données reçues.'
}
} catch {
Write-Host $_.Exception.GetBaseException().Message
} finally {
$client.Dispose()
}
J’attends jusqu’à 500 ms pour voir si la connexion reçoit des données, se ferme ou rencontre une erreur.
Sur dix connexions IPv6, sept ont été réinitialisées avant tout envoi de données par le programme. Aucun message TLS ni aucune requête HTTP n’avait encore été envoyé. Je pouvais désormais situer certains échecs avant ces étapes.
La connexion acceptait la poignée de main, puis me fermait la porte avant la première question. Même Patrick Jane aurait eu du mal à mener cet interrogatoire.
J’avais repéré le moment de la coupure. Il me restait à en trouver la cause.
4. Et si le problème venait de mon PC ?
J’avais situé la coupure, mais le responsable restait hors champ. Il était temps de faire ce que j’imaginais être le tour de la pièce à la Patrick Jane : regarder aussi ce qui se trouvait juste devant moi. J’ai examiné la configuration réseau de mon PC.
La connexion passait par le Wi-Fi. J’ai vérifié la route IPv6 par défaut, les logiciels réseau installés et les paramètres de proxy consultables. Aucun proxy n’était configuré dans ces paramètres.
Le traceroute ne m’a pas apporté d’explication. Plusieurs routeurs répondaient, d’autres restaient silencieux, mais cela ne permettait pas de localiser l’origine des resets. L’absence de réponse à un traceroute ne suffisait pas non plus à conclure que les paquets HTTPS étaient perdus.
Un autre détail a retenu mon attention : l’interface Wi-Fi de mon PC possédait deux adresses IPv6 globales, une stable et une temporaire. J’ai donc imposé l’adresse source pour comparer leur comportement.
- Avec l’adresse temporaire, certaines connexions fonctionnaient, tandis que d’autres étaient coupées presque aussitôt.
- Avec l’adresse stable, cinq connexions TCP étaient restées ouvertes pendant le court test sans données. Les requêtes HTTPS échouaient pourtant toujours, généralement après environ 2,8 secondes.
L’adresse stable semblait prometteuse au premier regard. Mais elle échouait aussi lors des essais HTTPS vers Google. Le test TCP avait seulement montré qu’une connexion pouvait rester ouverte un court instant. Il n’avait pas démontré que la page pouvait se charger.
J’ai donc rangé mon « Et voilà ! » prématuré. J’en étais encore à la fausse piste du milieu de l’épisode.
J’y ai cru… il va falloir continuer à chercher. — Source : Tenor.
Cette piste ne m’apportait donc pas de solution. En revanche, le changement de symptômes selon l’adresse source méritait d’être compris. Les « témoignages » de curl avaient atteint leurs limites ; je voulais maintenant les confronter aux traces laissées par les paquets.
5. Observer les échanges avec PktMon
À défaut de lire les expressions d’un suspect comme Patrick Jane, j’allais examiner les en-têtes des paquets. C’était moins télégénique, mais j’espérais y trouver l’indice qui me manquait.
J’ai choisi Packet Monitor, ou PktMon, un outil de diagnostic réseau intégré aux versions modernes de Windows.
Il permet de capturer les paquets à plusieurs endroits de la pile réseau et de recueillir des informations sur leur abandon. La documentation Microsoft présente ces fonctions.
Son intérêt était concret pour cette enquête : je pouvais comparer ce qui se passait dans Windows avec les échanges visibles sur la carte Wi-Fi. Je cherchais notamment à savoir si les resets arrivaient du réseau et si les paquets sortants gardaient les mêmes adresses.
J’ai limité la capture aux adresses du Marketplace et au port TCP 443. Les 128 premiers octets de chaque paquet suffisaient pour examiner les en-têtes utiles. Même ainsi, les fichiers contenaient des adresses et des informations réseau. J’ai donc masqué les adresses locales dans les exemples publics.
Préparer une capture ciblée
Pour faire parler les paquets, je devais d’abord préparer la scène. Mon dispositif avait moins d’allure qu’une mise en scène de Patrick Jane : un PowerShell ouvert en administrateur et deux commandes pour vérifier l’état de PktMon et ses filtres.
pktmon status
pktmon filter list
Le script ci-dessous suppose que PktMon est arrêté et que la liste des filtres est vide. Il crée sa propre session, puis supprime ses filtres à la fin. Si une capture ou des filtres existent déjà, je dois les préserver avant d’aller plus loin : pktmon filter remove supprime tous les filtres.
$ErrorActionPreference = 'Stop'
$targetHost = 'marketplace.visualstudio.com'
$url = "https://$targetHost/items?itemName=iolys.iolys-visual-studio"
$addresses = @([Net.Dns]::GetHostAddresses($targetHost))
if ($addresses.Count -eq 0) { throw 'Aucune adresse résolue.' }
$captureDir = Join-Path $env:TEMP ('marketplace-' + (Get-Date -Format 'yyyyMMdd-HHmmss'))
New-Item -ItemType Directory -Path $captureDir | Out-Null
$started = $false
$filtersAdded = $false
try {
$index = 0
foreach ($address in $addresses) {
$index++
& pktmon filter add "marketplace-$index" -i $address.IPAddressToString -t TCP -p 443
if ($LASTEXITCODE -ne 0) { throw 'Ajout du filtre impossible.' }
$filtersAdded = $true
}
& pktmon start --capture --comp all --pkt-size 128 `
--file-size 128 --log-mode multi-file `
--file-name (Join-Path $captureDir 'capture.etl')
if ($LASTEXITCODE -ne 0) { throw 'Démarrage de la capture impossible.' }
$started = $true
foreach ($family in @('-4', '-6')) {
foreach ($attempt in 1..5) {
& curl.exe $family --silent --output NUL `
--connect-timeout 3 --max-time 6 `
--write-out "$family essai=$attempt http=%{http_code} erreur=%{errormsg}\n" `
$url | Tee-Object -FilePath (Join-Path $captureDir 'requests.txt') -Append
}
}
} finally {
if ($started) {
& pktmon stop
if ($LASTEXITCODE -ne 0) {
throw 'Arrêt PktMon non confirmé : vérifier son état avant toute autre capture.'
}
}
if ($filtersAdded) { & pktmon filter remove }
}
# Conserver et convertir tous les fichiers produits en mode multi-file.
Get-ChildItem -LiteralPath $captureDir -Filter 'capture*.etl' | ForEach-Object {
& pktmon etl2txt $_.FullName --out (Join-Path $captureDir ($_.BaseName + '.txt')) --verbose --hex
& pktmon etl2pcap $_.FullName --out (Join-Path $captureDir ($_.BaseName + '.pcapng'))
if ($LASTEXITCODE -ne 0) { throw 'Conversion PCAPNG en échec.' }
}
Write-Host "Fichiers : $captureDir"
Cet exemple reprend une partie du diagnostic. Le script complet comparait aussi les adresses IP de destination et les adresses sources. La sortie texte permet d’examiner les événements PktMon ; le fichier PCAPNG peut être ouvert dans un lecteur de captures.
Les options de capture et la gestion des filtres sont décrites dans la documentation Microsoft.
6. Le détail qui change la direction de l’enquête
J’avais enfin les traces nécessaires pour rejouer la scène. C’était le moment de chercher le petit détail qui ferait lever un sourcil à Patrick Jane. J’ai commencé par suivre une connexion TCP qui n’envoyait aucune donnée applicative. Sur la carte Wi-Fi, l’échange se déroulait ainsi :
| Heure locale, le 29 septembre | Sens | Paquet |
|---|---|---|
| 03:33:47.639 | PC → réseau | SYN : demande d’ouverture TCP |
| 03:33:47.652 | Réseau → PC | SYN-ACK : réponse à cette demande |
| 03:33:47.654 | PC → réseau | ACK : confirmation de l’ouverture |
| 03:33:47.657 | Réseau → PC | RST : réinitialisation de la connexion |
Le RST arrivait sur la carte Wi-Fi avant que Windows ne signale l’erreur au programme. Des retransmissions SYN-ACK apparaissaient ensuite. La coupure venait donc bien d’un paquet reçu du réseau.
J’aurais pu y voir une confirmation de mon soupçon initial envers Microsoft. Mais un serveur distant peut rejeter une connexion si les paquets qu’il reçoit ont été modifiés en chemin. Il fallait aussi examiner ce que mon PC envoyait.
C’est là que deux anomalies sont apparues :
- Le premier SYN portait un flow label IPv6 non nul, puis les paquets suivants portaient zéro. Dans l’échange ci-dessus, la valeur passait de
0xcf40dà0. - Dans un autre essai, j’avais imposé l’adresse source stable. Le SYN utilisait bien cette adresse, mais l’ACK et les données TLS partaient avec l’adresse temporaire.
Les ports et les numéros de séquence TCP permettaient de rattacher ces derniers paquets à la même tentative. Le changement d’adresse était déjà visible dans la pile réseau de Windows, puis sur la carte Wi-Fi. J’avais donc un indice de modification des paquets sur mon propre PC.
Un changement d’identité en plein échange : voilà enfin un détail digne d’attirer le regard de Patrick Jane. Mon enquête sur les serveurs de Microsoft venait de me ramener devant mon propre clavier.
Vue simplifiée d’un essai avec adresse source imposée. A et B remplacent les adresses IPv6 réelles du PC.
Le changement d’adresse était particulièrement suspect : mon PC ouvrait la connexion avec une adresse IPv6, puis envoyait la suite avec une autre. Le serveur pouvait alors ne plus reconnaître ces paquets comme faisant partie de la même connexion.
Le flow label est un numéro présent dans les paquets IPv6. Certains équipements réseau s’en servent, avec les adresses IP, pour faire passer les paquets d’un même échange par le même chemin. C’est l’un des usages décrits dans la RFC 6438.
Dans ma capture, ce numéro changeait pendant l’échange. J’avais donc une autre piste pour expliquer les coupures.
Pourquoi le Marketplace, alors que Google et Cloudflare fonctionnaient ?
C’était la question qui pouvait encore me faire soupçonner Microsoft. Pourtant, un problème sur mon PC pouvait avoir des effets différents selon les équipements rencontrés sur le réseau.
Si un équipement utilisait le flow label pour choisir le chemin, son changement pouvait envoyer la suite de l’échange ailleurs. Un équipement qui ne s’appuyait pas sur ce numéro pouvait, lui, conserver le même chemin. Cela pouvait expliquer pourquoi certaines destinations fonctionnaient et d’autres échouaient. Je n’avais toutefois pas accès aux réseaux de Microsoft, Google ou Cloudflare pour confirmer cette explication.
Je devais aussi nuancer mon constat de départ : Google avait échoué lorsque j’avais imposé l’adresse IPv6 stable de mon PC. Le problème ne se limitait donc pas au Marketplace dans tous mes essais. Les premières réussites chez Google et Cloudflare ne suffisaient pas à innocenter mon PC.
7. Identifier le composant qui intervient dans la connexion
Le détail était trouvé ; il fallait maintenant le relier à quelqu’un. Dans mon épisode du Mentalist, la caméra venait de quitter les serveurs de Microsoft pour revenir sur mon PC. Je cherchais quel composant local pouvait intervenir sur ces paquets.
Parmi les composants actifs, j’ai trouvé Intel Connectivity Network Service et Intel Connectivity Traffic Control Callout Driver. Ils sont associés à Intel Connectivity Performance Suite, ou ICPS.
Cette suite propose notamment de donner la priorité au trafic de certaines applications et d’optimiser le choix des connexions. Les fonctions disponibles dépendent du matériel et de la configuration, comme l’explique la présentation d’ICPS par Intel. Son rôle dans le traitement du trafic en faisait une piste à examiner.
J’ai ensuite trouvé un témoignage sur le forum Intel décrivant des flow labels IPv6 remis à zéro lorsque le service était actif. L’auteur constatait aussi une amélioration après son arrêt.
Un détail rendait ce cas particulièrement intéressant : il rencontrait des problèmes avec dev.azure.com, qui utilisait 2603:1061:10:1::16, l’une des adresses présentes dans mes propres tests.
Ce témoignage ressemblait beaucoup à ce que j’observais. J’avais enfin une piste concrète : arrêter le service Intel sur mon PC et refaire les mêmes tests pour voir si les échecs disparaissaient.
8. Arrêter le service, puis vérifier que le problème revient
C’était le moment de ma confrontation à la Patrick Jane : placer le suspect dans une situation où son rôle deviendrait visible. J’ai donc comparé trois situations :
- Le service actif.
- Le service arrêté.
- Le service redémarré.
Pour chaque phase, j’ai lancé dix requêtes IPv6 en alternant les deux adresses du Marketplace.
Tout le reste restait identique : le PC, le Wi-Fi, l’URL et la méthode de test. Je voulais observer l’effet de cette seule modification.
| État du service | HTTP 200 | Connexion réinitialisée | Autre résultat |
|---|---|---|---|
| Actif | 🟢 2 / 10 | 🔴 7 / 10 | 🟠 Un HTTP 503 |
| Arrêté | 🟢 10 / 10 | 🟢 0 / 10 | 🟢 Aucun |
| Redémarré | 🟢 2 / 10 | 🔴 8 / 10 | 🟢 Aucun |
J’ai compté le HTTP 503 à part. Même si la page n’était pas disponible, une réponse HTTP avait bien été reçue. Le confondre avec un reset aurait masqué cette différence.
Chaque case représente une requête. Les résultats sont regroupés par catégorie, sans suivre l’ordre des essais.
L’arrêt du service faisait disparaître les échecs, et son redémarrage les faisait revenir. C’était l’élément le plus convaincant de l’enquête. Je ne m’appuyais plus seulement sur une ressemblance avec un autre signalement : je reproduisais le problème en changeant l’état du service.
Ce résultat impliquait fortement le service sur mon installation. Il ne révélait pas pour autant le défaut exact dans le pilote, ni l’équipement distant qui émettait chaque reset.
Le script de comparaison
Voici les coulisses de ma mise en scène. Aucun complice caché derrière une porte : j’ai mené cette comparaison dans un PowerShell administrateur, avec le service actif au départ. La version ci-dessous rétablit cet état dans le bloc finally, sans changer le mode de démarrage du service.
$ErrorActionPreference = 'Stop'
$serviceName = 'Intel Connectivity Network Service'
if ((Get-Service -Name $serviceName).Status -ne 'Running') {
throw 'Ce test suppose un service initialement actif.'
}
$targetHost = 'marketplace.visualstudio.com'
$url = "https://$targetHost/items?itemName=iolys.iolys-visual-studio"
$ips = @([Net.Dns]::GetHostAddresses($targetHost) |
Where-Object AddressFamily -eq ([Net.Sockets.AddressFamily]::InterNetworkV6))
if ($ips.Count -eq 0) { throw 'Aucune adresse IPv6 résolue.' }
$rows = [Collections.Generic.List[object]]::new()
function Measure-Phase([string]$phase) {
$expected = if ($phase -eq 'stopped') { 'Stopped' } else { 'Running' }
foreach ($attempt in 1..5) {
foreach ($ip in $ips) {
if ((Get-Service -Name $serviceName).Status.ToString() -ne $expected) {
throw "État du service modifié pendant la phase $phase."
}
$result = & curl.exe -6 --silent --output NUL `
--connect-timeout 3 --max-time 6 `
--resolve "${targetHost}:443:[$ip]" `
--write-out '%{http_code}|%{time_total}|%{errormsg}' $url
$exitCode = $LASTEXITCODE
$fields = ($result -join '') -split '\|', 3
$rows.Add([pscustomobject]@{
Phase = $phase; Address = $ip.IPAddressToString
Attempt = $attempt; ExitCode = $exitCode
HttpStatus = $fields[0]; Seconds = $fields[1]; Error = $fields[2]
})
}
}
}
try {
Measure-Phase 'before'
Stop-Service -Name $serviceName
(Get-Service -Name $serviceName).WaitForStatus('Stopped', [TimeSpan]::FromSeconds(15))
Start-Sleep -Seconds 2
Measure-Phase 'stopped'
Start-Service -Name $serviceName
(Get-Service -Name $serviceName).WaitForStatus('Running', [TimeSpan]::FromSeconds(15))
Start-Sleep -Seconds 2
Measure-Phase 'restored'
} finally {
$resultFile = Join-Path $env:TEMP ('marketplace-service-' + (Get-Date -Format 'yyyyMMdd-HHmmss') + '.csv')
try {
Start-Service -Name $serviceName
(Get-Service -Name $serviceName).WaitForStatus('Running', [TimeSpan]::FromSeconds(15))
} finally {
$rows | Export-Csv -LiteralPath $resultFile -NoTypeInformation -Encoding UTF8
Write-Host "Résultats : $resultFile"
}
}
$rows | Format-Table -AutoSize
J’ai donc arrêté le service et désactivé son démarrage automatique. Le Wi-Fi et IPv6 continuaient de fonctionner, mais les optimisations ICPS liées au service n’étaient plus disponibles. J’ai gardé ce contournement en attendant un correctif.
9. Poursuivre l’enquête avec Intel et Microsoft
J’aimerais contacter Intel et Microsoft pour leur transmettre mes résultats et les captures réseau, puis creuser le sujet avec eux. Le signalement concernant dev.azure.com me donne une raison de plus de poursuivre l’enquête : pourquoi ces services sont-ils particulièrement touchés, et comment corriger durablement le problème ?
Après tous ces essais, je peux enfin m’accorder un petit « Et voilà ! ».
Source : Tenor.
Ce que cette enquête m’a appris
Cette enquête m’a appris à utiliser Packet Monitor et à mieux comprendre ce qui se passe sur le réseau quand j’ouvre une page web.
Elle m’a surtout rappelé que ma première impression n’était pas forcément la bonne. Je soupçonnais les serveurs de Microsoft ; les tests m’ont ramené à un service Intel sur mon PC.
Comme un bon enquêteur, je dois examiner les différentes hypothèses et chercher ce qui les confirme ou les contredit, sans laisser mes a priori décider du résultat. C’est la leçon que je retiens de cette petite enquête. Patrick Jane serait fier de moi.
Et j’ai découvert une dernière chose : j’ai très envie de revoir The Mentalist.
Happy Coding :)
Pour aller plus loin
Pour compléter mon dossier d’enquêteur, je rassemble ici les documents qui éclairent les outils et les mécanismes évoqués. Même mon Patrick Jane intérieur doit parfois ouvrir la documentation.
- Microsoft : présentation de Packet Monitor — le fonctionnement de PktMon et les informations qu’il peut recueillir.
- Microsoft : options de capture PktMon — le choix des composants, la taille des paquets capturés et les modes d’enregistrement.
- Microsoft : filtres PktMon — les commandes pour consulter, ajouter et supprimer les filtres.
- Manuel de curl — le choix IPv4/IPv6,
--resolve, les mesures de temps et les codes de sortie. - RFC 6437 : IPv6 Flow Label Specification et RFC 6438 : Flow Labels and Load Balancing — le rôle du flow label et son utilisation pour répartir le trafic.
- Intel Connectivity Performance Suite — les fonctions proposées par ICPS.
- Témoignage sur le forum Intel — un cas proche du mien, qui reste un témoignage et non un avis technique officiel.