Monitoraggio richieste IIS: errore “Not implemented” con appcmd list requests – cause e soluzioni

Quando appcmd list requests su IIS risponde con “Not implemented” è facile perdersi tra feature, ruoli e strumenti di diagnostica. In questa guida spieghiamo perché accade, come riconoscere i casi legittimi e quali alternative usare per tracciare e risolvere richieste lente o bloccate.

Indice

Scenario e sintomi

Su un sistema con IIS installato, l’esecuzione del comando:

%windir%\system32\inetsrv\appcmd list requests

restituisce l’errore:

ERROR ( hresult:80004001, message:Command execution failed. Not implemented )

Il tutto anche se “IIS Request Monitor” risulta spuntato nelle funzionalità, la console è avviata con privilegi elevati e nel Visualizzatore eventi non compaiono dettagli utili.

Perché compare “Not implemented”

Il messaggio non indica necessariamente un guasto. Nella pratica, i due motivi più frequenti sono:

Motivo	Dettaglio
Funzionalità non prevista su Windows client	Nelle edizioni client (Windows 10/11, ecc.) il binario di `appcmd` esiste ma il codice che implementa `list requests` è disabilitato: l’errore “Not implemented” è previsto e non aggirabile.
Ruolo non davvero installato su Windows Server	Su Windows Server, la sotto‑feature Web‑Request‑Monitor potrebbe non essere stata selezionata oppure non essere stata registrata correttamente. In questo caso il comando fallisce finché la feature non viene installata/registrata.

Che cosa fa (e che cosa non fa) Request Monitor

Espone lo stato corrente delle richieste nei processi w3wp.exe, con URL, tempo trascorso, modulo/pipeline, stato di autenticazione e altri metadati utili.
È pensato per diagnosi live di blocchi o hangs. Non è un logger storico: se la richiesta termina, sparisce dall’elenco.
Non vede il traffico servito interamente dal kernel (kernel‑mode cache) né ciò che non raggiunge il worker process.

Verifiche preliminari consigliate

Capire l’edizione di Windows
Get-ComputerInfo | Select-Object WindowsProductName, OsHardwareAbstractionLayer, OsVersion Se è un’edizione client, non potrai usare appcmd list requests.
Verificare la feature su Windows Server
Get-WindowsFeature -Name Web-Request-Monitor Attesa: Install State : Installed. In alternativa: dism /online /get-features /format:table | findstr /i request
Confermare che ci siano richieste in esecuzione
Spesso l’output è vuoto perché non ci sono richieste attive. Genera traffico contro il sito/endpoint problematico mentre esegui il comando.
Identificare il processo interessato
%windir%\system32\inetsrv\appcmd list wp Individua Process Id e l’Application Pool corretto.
Verificare permessi e contesto
Esegui il prompt come amministratore sulla macchina che esegue IIS. appcmd opera localmente: lanciare il comando da una macchina di gestione remota non interroga il server remoto.

Soluzioni per ogni scenario

Scenario: Windows 10/11 (edizioni client)

Non è possibile abilitare Request Monitor: l’errore è atteso. Passa subito alle alternative operative:

Failed Request Tracing (FREB) per catturare richieste lente o con errori, con stack di moduli/handler e tempi di ciascuna fase.
Event Tracing for Windows (ETW) per tracciare pipeline IIS e HTTP.sys a bassa intrusività.
Strumenti live come Process Monitor, PerfView, dump di processo con procdump per analizzare stalli o deadlock.

Scenario: Windows Server

Verifica stato feature
Get-WindowsFeature -Name Web-Request-Monitor
Installa se mancante
Install-WindowsFeature Web-Request-Monitor (Sinonimo storico: Add-WindowsFeature Web-Request-Monitor)
Riavvia W3SVC (minimamente invasivo): Restart-Service W3SVC In alternativa, iisreset riavvia anche i worker process: più impattante.
Esegui di nuovo il comando
%windir%\system32\inetsrv\appcmd list requests

Alternative operative efficaci

Failed Request Tracing (FREB)

Ottimo per indagare richieste lente, time‑out o codici di stato specifici.

Abilitazione globale in IIS Manager: server ▸ Actions ▸ Configure Failed Request Tracing… ▸ Enable.
Regola per sito: apri il sito ▸ Failed Request Tracing Rules ▸ Add…, scegli “All content”, imposta filtri:
- Per lentezza: Time‑Taken > 30000 ms (ad es. 30 s).
- Per errori: Status code 500, 502, 503 o range.
Analisi: i file .xml con XSL sono in %SystemDrive%\inetpub\logs\FailedReqLogFiles\W3SVC<ID>. Apri l’XML nel browser e leggi:
- Time Taken per ogni nodo (autenticazione, autorizzazione, handler, moduli).
- ModuleName e Notification in cui si accumulano i tempi.
- Eventuali eccezioni gestite/non gestite.

Consigli pratici

Limita la cattura al periodo del problema per evitare file voluminosi.
Configura regole separate per status e per lentezza con soglie differenti.
Se usi riscrittura URL o reverse proxy, aggiungi i campi server‑variables nei log per facilitare la correlazione (percorso reale, upstream, ecc.).

ETW/Traccia di sistema

Quando serve visibilità a basso overhead, ETW è la scelta migliore.
Traccia rapida con logman

mkdir C:\Traces
logman start iistrace -p "Microsoft-Windows-IIS-W3SVC" 0xFFFFFFFF 0x5 -ets -o C:\Traces\iistrace.etl
REM riproduci il problema...
logman stop iis_trace -ets

Apri l’.etl con Windows Performance Analyzer o PerfView per vedere code, handler e tempi.

Traccia HTTP.sys (coda kernel)

logman start httptrace -p "Microsoft-Windows-HttpService" 0xFFFFFFFF 0x5 -ets -o C:\Traces\httptrace.etl
REM riproduci il problema...
logman stop http_trace -ets

Process Monitor, PerfView e dump mirati

Process Monitor: filtra su Process Name is w3wp.exe e osserva I/O e accessi a registro che bloccano i thread.
PerfView: cattura CPU stacks, thread time e GC per capire hot‑path o lock contesi.
Procdump: utile per blocchi sporadici: procdump -ma -n 3 -s 5 -h w3wp.exe Crea fino a tre dump quando il processo resta sospeso per oltre 5 s. Analizza i dump con WinDbg o Visual Studio per individuare deadlock o attese esterne.

Esempi d’uso e comandi utili

Individuare richieste per un Application Pool

%windir%\system32\inetsrv\appcmd list requests /apppool.name:"MyAppPool"

Visualizzare i worker process attivi

%windir%\system32\inetsrv\appcmd list wp

Ristartare in sicurezza solo i servizi web

Restart-Service W3SVC
Restart-Service WAS

Script PowerShell per Windows Server

Automatizza verifica e installazione della feature, con riavvio del servizio:

# Eseguire in una console elevata
Idempotente: installa Web-Request-Monitor se mancante e riavvia W3SVC

Verifica modulo ServerManager (presente da WS2008 R2+)

if (-not (Get-Module -ListAvailable -Name ServerManager)) {
Write-Host "Modulo ServerManager non trovato. Continuo: su Windows Server recenti è caricato automaticamente."
}

$featureName = "Web-Request-Monitor"
$feature = Get-WindowsFeature -Name $featureName -ErrorAction SilentlyContinue

if ($null -eq $feature) {
Write-Warning "Impossibile interrogare le feature. Verifica di essere su Windows Server."
} elseif (-not $feature.Installed) {
Write-Host "Installazione di $featureName in corso..."
Install-WindowsFeature -Name $featureName -IncludeManagementTools -Verbose
} else {
Write-Host "$featureName è già installata."
}

Write-Host "Riavvio del servizio W3SVC..."
Restart-Service -Name W3SVC -Force

Test rapido di appcmd

$ac = Join-Path $env:windir "System32\inetsrv\appcmd.exe"
if (Test-Path $ac) {
Write-Host "Esecuzione test: appcmd list requests"
& $ac list requests
} else {
Write-Warning "appcmd.exe non trovato. IIS è installato?"
}

Diagnosi senza Request Monitor: una procedura collaudata

Misura il backlog
Aggiungi questi contatori in Performance Monitor:
- HTTP Service Request Queues ▸ CurrentQueueSize (per nome coda).
- ASP.NET Applications ▸ Requests In Application Queue (per applicazione).
- W3SVC_W3WP ▸ Active Requests e Requests/Sec (per processo).
Se i numeri salgono stabilmente, c’è saturazione a livello di worker o di coda HTTP.sys.
Attiva FREB con soglia di lentezza (es. > 10 s) e aspetta che si generino .xml.
Correla con i log IIS
Abilita campi aggiuntivi utili: time‑taken, cs‑uri‑stem, cs‑method, sc‑status, sc‑win32‑status, cs‑username, referer, user‑agent. Valuta anche X‑Forwarded‑For se passi da un bilanciatore.
Se sospetti un lock o un collo di bottiglia nel codice, acquisisci un dump con procdump o una traccia CPU con PerfView e analizza gli stack.
Se il collo di bottiglia è esterno (SQL, file system, rete), estendi la cattura: ETW provider di ADO.NET/Entity Framework, SMB Client/Server, DNS Client, TCPIP.

Domande frequenti

Posso “forzare” `appcmd list requests` su Windows 10/11?

No. Sulle edizioni client la funzionalità non è implementata. Installa un’edizione server o usa le alternative (FREB/ETW/PerfView).

Devo riavviare il server dopo l’installazione della feature?

Non sempre. In genere basta riavviare W3SVC. Se continui a vedere l’errore, effettua un riavvio completo per riallineare WAS e i moduli nativi.

`appcmd list requests` non mostra niente ma il sito risulta lento: perché?

Perché non ci sono richieste attive nel preciso istante dell’interrogazione, oppure il problema avviene prima di arrivare al worker (es. coda kernel piena, TLS handshake, limitazioni di connessione). In questi casi i contatori HTTP Service Request Queues e FREB danno più visibilità.

È meglio usare `iisreset` o riavviare servizi?

iisreset è più invasivo (chiude e riapre i worker process). Quando possibile preferisci Restart-Service W3SVC o il riciclo puntuale dell’Application Pool.

Checklist decisionale

Windows client? Sì → l’errore è atteso. Passa a FREB/ETW/PerfView.
Windows Server? Verifica e installa Web‑Request‑Monitor. Riavvia W3SVC.
Serve visibilità storica? Usa FREB e log IIS con time‑taken.
Serve visibilità a basso overhead? ETW (IIS + HTTP.sys).
Sospetti un hang? procdump condizionato e analisi stack.

Buone pratiche per prevenire richieste lente

Ricicli controllati degli Application Pool (orari di bassa attività, overlapped recycle attivo, warm‑up del sito).
Limiti sensati di maxConcurrentRequestsPerCPU e Queue Length dell’App Pool in base alla capacità.
Piani di capacity basati su contatori (Requests/Sec, CPU %, CurrentQueueSize, Thread Count).
Timeout espliciti verso dipendenze esterne (SQL/HTTP) e politica di retry con circuit breaker.
Log arricchiti (correlation‑id, user‑agent, client‑ip) per svolgere analisi causale con più velocità.

Errori comuni da evitare

Supporre che “IIS Request Monitor” spuntato su Windows 10/11 abiliti appcmd list requests: non è così.
Dare per scontato che appcmd interroghi server remoti: lavora solo in locale.
Attivare FREB senza regole specifiche: si rischiano migliaia di file inutili.
Confondere i contatori: per la coda kernel guardare HTTP Service Request Queues, per la coda applicativa ASP.NET Applications.

Esempio di sessione diagnostica completa

Controllo piattaforma: il server è Windows Server 2019.
Feature: Get-WindowsFeature Web-Request-Monitor Install-WindowsFeature Web-Request-Monitor Restart-Service W3SVC
Carico richieste: genera traffico sul sito di test.
Ispezione live: appcmd list requests /apppool.name:"MyAppPool" Se presente, identifica le richieste con TimeElapsed alto e annota URL e modulo coinvolto.
FREB: abilita regola > 10 s e 500/502/503. Analizza ModuleName con maggior tempo.
ETW: acquisisci traccia IIS+HTTP.sys per confermare se l’attesa è in coda kernel, in handler o in backend.
Dump (solo se necessario): procdump -ma -n 2 -s 10 -h w3wp.exe e verifica le attese di thread.

Conclusione

Il messaggio “Not implemented” di appcmd list requests ha quasi sempre una spiegazione semplice: su Windows client è un limite progettuale; su Windows Server occorre verificare e installare la feature Web‑Request‑Monitor. Per l’analisi sul campo, FREB, ETW e dump mirati offrono tutta la visibilità necessaria per individuare colli di bottiglia, blocchi e dipendenze lente, spesso con overhead irrisorio e senza downtime.

Riepilogo operativo

Scenario	Passaggi consigliati
Sistema operativo client (Windows 10/11, ecc.)	Non è possibile usare Request Monitor. Usa invece: Failed Request Tracing (FREB) per registrare richieste lente o con errori. ETW (Event Tracing for Windows) o `logman` per pipeline IIS/HTTP.sys. Process Monitor, PerfView o dump di processo (`procdump -ma w3wp.exe`) per debug live.
Windows Server	Verifica lo stato: `Get-WindowsFeature Web-Request-Monitor`. Se “Install State = Available”, installa: `Install-WindowsFeature Web-Request-Monitor`. Riavvia W3SVC o il server. Esegui di nuovo `appcmd list requests`.
Diagnosi senza Request Monitor	Abilita FREB in IIS Manager (Actions ▸ Configure ▸ Failed Request Tracing ▸ Enable). Imposta filtri (es. `TimeTaken > 30000 ms`). Analizza i log `.xml` generati per identificare la richiesta problematica.

Suggerimenti extra

Automazione PowerShell su Windows Server: Install-WindowsFeature Web-Request-Monitor Restart-Service W3SVC
Performance counters: se il problema è il carico, abilita soprattutto:
- HTTP Service Request Queues ▸ CurrentQueueSize (backlog kernel).
- ASP.NET Applications ▸ Requests In Application Queue (backlog in user‑mode).
- W3SVC_W3WP ▸ Active Requests e Requests/Sec.
Dump condizionati per blocchi sporadici: procdump -ma -n 3 -s 5 -h w3wp.exe

In breve: su Windows client l’errore è previsto; su Windows Server va prima confermata (ed eventualmente installata) la feature Web‑Request‑Monitor. In entrambi i casi esistono alternative efficaci, in particolare Failed Request Tracing, ETW e dump di processo, per tracciare e diagnosticare richieste problematiche.