Risolvere i problemi di ASP.NET Core in Servizio app di Azure e IIS

Questo articolo fornisce informazioni sugli errori di avvio delle app comuni e istruzioni su come diagnosticare gli errori quando un'app viene distribuita nel servizio app Azure o IIS:

Errori di avvio dell'app
Illustra gli scenari comuni del codice di stato HTTP di avvio.

Risolvere i problemi relativi al servizio app Azure
Fornisce consigli per la risoluzione dei problemi per le app distribuite nel servizio app Azure.

Risolvere i problemi in IIS
Fornisce consigli per la risoluzione dei problemi per le app distribuite in IIS o in esecuzione in IIS Express in locale. Le linee guida si applicano sia alle distribuzioni di Windows Server che a windows desktop.

Cancellare le cache dei pacchetti
Spiega cosa fare quando i pacchetti incoerenti interrompono un'app durante l'esecuzione di aggiornamenti principali o la modifica delle versioni dei pacchetti.

Risorse aggiuntive
Elenca altri argomenti relativi alla risoluzione dei problemi.

Errori di avvio dell'app

In Visual Studio il server predefinito del progetto ASP.NET Core è Kestrel. Visual Studio può essere configurato per l'uso di IIS Express. 502.5 - Errore di processo o 500.30 - Errore di avvio che si verifica quando si esegue il debug in locale con IIS Express può essere diagnosticato usando i consigli in questo argomento.

403.14 Accesso negato

L'app non viene avviata. Viene registrato l'errore seguente:

The Web server is configured to not list the contents of this directory.

L'errore è in genere causato da una distribuzione interrotta nel sistema di hosting, che include uno degli scenari seguenti:

• L'app viene distribuita nella cartella errata nel sistema di hosting.
• Il processo di distribuzione non è riuscito a spostare tutti i file e le cartelle dell'app nella cartella di distribuzione nel sistema di hosting.
• Il file web.config non è presente nella distribuzione oppure il contenuto del file web.config non è valido.

Procedi come segue:

1. Eliminare tutti i file e le cartelle dalla cartella di distribuzione nel sistema di hosting.
2. Ridistribuire il contenuto della cartella di pubblicazione dell'app nel sistema di hosting usando il metodo normale di distribuzione, ad esempio Visual Studio, PowerShell o distribuzione manuale:
   • Verificare che il file web.config sia presente nella distribuzione e che il relativo contenuto sia corretto.
   • Quando si ospita nel servizio app Azure, verificare che l'app venga distribuita nella D:\home\site\wwwroot cartella .
   • Quando l'app è ospitata da IIS, verificare che l'app venga distribuita nel percorso fisico IIS visualizzato nelle impostazioni di base di Gestione IIS.
3. Verificare che tutti i file e le cartelle dell'app vengano distribuiti confrontando la distribuzione nel sistema di hosting con il contenuto della cartella di pubblicazione del progetto.

Per altre informazioni sul layout di un'app ASP.NET Core pubblicata, vedere ASP.NET struttura di directory Core. Per altre informazioni sul file web.config , vedere ASP.NET Core Module (ANCM) per IIS.

500 Errore interno del server

L'app viene avviata, ma un errore impedisce al server di soddisfare la richiesta.

Questo errore si verifica all'interno del codice dell'app durante l'avvio o durante la creazione di una risposta. La risposta potrebbe non avere alcun contenuto o essere visualizzata nel browser come un codice 500 Errore interno del server. Il log eventi dell'applicazione in genere indica che l'app è stata avviata normalmente. Dal punto di vista del server, questo è corretto. L'app è stata effettivamente avviata, ma non può generare una risposta valida. Per risolvere il problema, eseguire l'app dal prompt dei comandi nel server o abilitare il log stdout del modulo ASP.NET Core.

Questo errore può verificarsi anche quando il bundle di hosting .NET Core non è installato o è danneggiato. L'installazione o il ripristino dell'installazione del bundle di hosting .NET Core (per IIS) o di Visual Studio (per IIS Express) possono risolvere il problema.

500.0 Errore di caricamento del gestore in-process

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Si è verificato un errore sconosciuto durante il caricamento ASP.NET componenti core module . Effettua una delle seguenti azioni:

• Contattare il supporto tecnico Microsoft. Selezionare Strumenti di sviluppo e quindi ASP.NET Core.
• Porre una domanda in Stack Overflow.
• Segnalare il problema nel repository GitHub di ASP.NET Core.

500.30 Errore di avvio in-process

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare .NET Core CLR in-process, ma non viene avviato. In genere è possibile determinare la causa di un errore di avvio del processo dalle voci nel log eventi dell'applicazione e nel log stdout del modulo ASP.NET Core.

Condizioni di errore comuni:

• L'app non è configurata correttamente a causa della destinazione di una versione del framework condiviso di ASP.NET Core non presente. Controllare le versioni del framework condiviso ASP.NET Core installate nel computer di destinazione.
• Uso di Azure Key Vault, mancanza di autorizzazioni per l'insieme di credenziali delle chiavi. Controllare i criteri di accesso nell'insieme di credenziali delle chiavi di destinazione per assicurarsi che vengano concesse le autorizzazioni corrette.

500.31 ANCM Failed to Find Native Dependencies (500.31 Il modulo ASP.NET Core non è riuscito a trovare le dipendenze native)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare il runtime di .NET Core in-process, ma non viene avviato. La causa più comune di questo errore di avvio è la mancata installazione del runtime di Microsoft.NETCore.App o di Microsoft.AspNetCore.App. Se l'app viene distribuita per ASP.NET Core 3.0 e tale versione non esiste nel computer, si verifica questo errore. Ecco un esempio di messaggio di errore:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

Il messaggio di errore elenca tutte le versioni di .NET Core installate e la versione richiesta dall'app. Per correggere l'errore, eseguire una delle operazioni seguenti:

• Installare la versione appropriata di .NET Core nel computer.
• Modificare l'app in modo che usi una versione di .NET Core presente nel computer.
• Pubblicare l'app come distribuzione autonoma.

Durante l'esecuzione in fase di sviluppo (con la variabile di ambiente ASPNETCORE_ENVIRONMENT impostata su Development), l'errore specifico viene scritto nella risposta HTTP. La causa di un errore di avvio del processo è disponibile anche nel log eventi dell'applicazione.

500.32 ANCM Failed to Load dll (500.32 Il modulo ASP.NET Core non è riuscito a caricare la DLL)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

La causa più comune di questo errore è la pubblicazione dell'app per processori con architettura non compatibile. Se il processo di lavoro è in esecuzione come app a 32 bit e l'app è stata pubblicata per un'architettura a 64 bit, si verifica questo errore.

Per correggere l'errore, eseguire una delle operazioni seguenti:

• Ripubblicare l'app per processori con la stessa architettura del processo di lavoro.
• Pubblicare l'app come distribuzione dipendente dal framework.

500.33 ANCM Request Handler Load Failure (500.33 Errore di caricamento del gestore della richiesta del modulo ASP.Net Core)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

L'app non fa riferimento al framework Microsoft.AspNetCore.App. Solo le app destinate al Microsoft.AspNetCore.App framework possono essere ospitate dal modulo principale ASP.NET.

Per correggere questo errore, verificare che l'app sia destinata al framework Microsoft.AspNetCore.App. Controllare il framework di destinazione dell'app nel file .runtimeconfig.json.

500.34 ANCM Mixed Hosting Models Not Supported (500.34 Modelli di hosting misto non supportati nel modulo ASP.NET Core)

Il processo di lavoro non è in grado di eseguire un'app In-Process e un'app Out-of-process nello stesso processo.

Per correggere questo errore, eseguire le app in pool di applicazioni IIS separati.

500.35 ANCM Multiple In-Process Applications in same Process (500.35 Modulo ASP.NET Core: più applicazioni In-Process nello stesso processo)

Il processo di lavoro non può eseguire più app in-process nello stesso processo.

Per correggere questo errore, eseguire le app in pool di applicazioni IIS separati.

500.36 ANCM Out-Of-Process Handler Load Failure (500.36 Modulo ASP.NET Core: Errore di caricamento del gestore Out-of-process)

Il gestore delle richieste Out-of-process, aspnetcorev2_outofprocess.dll, non è accanto al file aspnetcorev2.dll. Indica un'installazione danneggiata del modulo core ASP.NET.

Per correggere questo errore, riparare l'installazione del bundle di hosting di .NET Core (per IIS) o di Visual Studio (per IIS Express).

500.37 ANCM Failed to Start Within Startup Time Limit (500.37 Avvio del modulo ASP.NET Core non riuscito entro il limite di tempo stabilito)

Non è stato possibile avviare ANCM entro il limite di tempo di avvio specificato. Per impostazione predefinita, il timeout è di 120 secondi.

Questo errore può verificarsi quando si avvia un numero elevato di app nello stesso computer. Controllare i picchi di utilizzo della CPU e della memoria nel server durante l'avvio. Può essere necessario scaglionare il processo di avvio di più app.

500.38 DLL dell'applicazione ANCM non trovata

ANCM non è riuscito a individuare la DLL dell'applicazione, che dovrebbe essere accanto al file eseguibile.

Questo errore si verifica quando si ospita un'app in pacchetto come eseguibile a file singolo usando il modello di hosting in-process. Il modello in-process richiede che ANCM carichi l'app .NET Core nel processo IIS esistente. Questo scenario non è supportato dal modello di distribuzione a file singolo. Usare uno degli approcci seguenti nel file di progetto dell'app per correggere questo errore:

1. Disabilitare la pubblicazione a file singolo impostando la PublishSingleFile proprietà MSBuild su false.
2. Passare al modello di hosting out-of-process impostando la AspNetCoreHostingModel proprietà MSBuild su OutOfProcess.

502.5 Process Failure (Errore del processo)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare il processo di lavoro, ma l'avvio non riesce. In genere è possibile determinare la causa di un errore di avvio del processo dalle voci nel log eventi dell'applicazione e nel log stdout del modulo ASP.NET Core.

Una condizione di errore comune è dovuta alla configurazione non corretta dell'app perché come destinazione viene specificata una versione del framework condiviso ASP.NET Core, che non è presente. Controllare le versioni del framework condiviso ASP.NET Core installate nel computer di destinazione. Il framework condiviso è il set di assembly (file DLL) che vengono installati nel computer e cui fa riferimento un metapacchetto, ad esempio Microsoft.AspNetCore.App. Il riferimento del metapacchetto può specificare una versione minima richiesta. Per altre informazioni, vedere The shared framework (Il framework condiviso).

La pagina di errore 502.5 Errore del processo viene restituita quando il processo di lavoro ha esito negativo a causa di un errore di configurazione dell'hosting o dell'app:

Non è stato possibile avviare l'aggiornamento dell'applicazione. Errore: 0x800700c1

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

L'app non è stata avviata perché non è stato possibile caricarne l'assembly (.dll).

Questo errore si verifica quando è presente una mancata corrispondenza del numero di bit tra l'app pubblicata e il processo w3wp/iisexpress.

Verificare che l'impostazione del pool di app a 32 bit sia corretta:

1. Selezionare il pool di app in Pool di applicazioni di Gestione IIS.
2. Selezionare Impostazioni avanzate in Modifica pool di applicazioni nel pannello Azioni.
3. Impostare Abilita applicazioni a 32 bit:
   • Se si sta sviluppando un'app a 32 bit (x86), impostare il valore su True.
   • Se si sta sviluppando un'app a 64 bit (x64), impostare il valore su False.

Verificare che non vi sia un conflitto tra una <Platform> proprietà MSBuild nel file di progetto e il livello di bit pubblicato dell'app.

Impossibile avviare l'applicazione (ErrorCode '0x800701b1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

Impossibile avviare l'app perché non è stato possibile caricare un servizio Windows.

Un servizio comune che deve essere abilitato è il servizio "null". Il comando seguente abilita il null servizio Windows:

sc.exe start null

Reimpostazione della connessione

Se si verifica un errore dopo l'invio delle intestazioni, è troppo tardi perché il server possa inviare un codice 500 Errore interno del server quando si verifica un errore. Questo spesso accade quando si verifica un errore durante la serializzazione di oggetti complessi per una risposta. Questo tipo di errore viene visualizzato come un errore di reimpostazione della connessione nel client. La registrazione delle applicazioni può consentire di risolvere questi tipi di errori.

Limiti di avvio predefiniti

Il modulo core ASP.NET è configurato con un valore predefinito startupTimeLimit di 120 secondi. Quando si mantiene il valore predefinito, l'avvio di un'app potrebbe richiedere fino a due minuti prima che il modulo registri un errore del processo. Per informazioni sulla configurazione del modulo, vedere Attributi dell'elemento aspNetCore.

Risolvere i problemi relativi al servizio app Azure

Flusso di log di app Azure Services

Le informazioni di registrazione dei flussi di log di app Azure Services non appena si verificano. Per visualizzare i log di streaming:

1. Nel portale di Azure aprire l'app in Servizi app.
2. Nel riquadro sinistro passare a Monitoraggio> servizio app Log.
3. Selezionare File System per Registrazione server Web. Facoltativamente, abilitare Registrazione applicazioni.
4. Nel riquadro sinistro passare a Monitoraggio>del flusso di log e quindi selezionare Log applicazioni o Log del server Web.

Le immagini seguenti illustrano l'output dei log dell'applicazione:

I log di streaming hanno una certa latenza e potrebbero non essere visualizzati immediatamente.

Registro eventi dell'applicazione (servizio app Azure)

Per accedere al log eventi dell'applicazione, usare il pannello Diagnostica e risolvi i problemi nel portale di Azure:

1. Nel portale di Azure aprire l'app in Servizi app.
2. Selezionare Diagnostica e risoluzione dei problemi.
3. Selezionare l'intestazione Strumenti di diagnostica.
4. In Strumenti di supporto selezionare il pulsante Eventi dell'applicazione.
5. Esaminare l'errore più recente dalla voce IIS AspNetCoreModule o IIS AspNetCoreModule V2 nella colonna Origine.

Un'alternativa all'uso del pannello Diagnostica e risolvi i problemi consiste nell'esaminare direttamente il file del log eventi dell'applicazione usando Kudu:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire la cartella LogFiles .
4. Selezionare l'icona a forma di matita accanto al eventlog.xml file.
5. Esaminare il log. Scorrere fino alla fine del log per visualizzare gli eventi più recenti.

Eseguire l'app nella console Kudu

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile eseguire l'app nella console di esecuzione remota Kudu per individuare l'errore:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.

Test di un'app a 32 bit (x86)

Versione corrente

1. cd d:\home\site\wwwroot
2. Eseguire l'app:

   • Se l'app è una distribuzione dipendente dal framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se l'app è una distribuzione autonoma:

     {ASSEMBLY NAME}.exe
     

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Test di un'app a 64 bit (x64)

Versione corrente

• Se l'app è una distribuzione dipendente dal framework a 64 bit (x64):
  1. cd D:\Program Files\dotnet
  2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se l'app è una distribuzione autonoma:
  1. cd D:\home\site\wwwroot
  2. Eseguire l'app: {ASSEMBLY NAME}.exe

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

log stdout del modulo core ASP.NET (servizio app Azure)

Il log stdout del modulo ASP.NET Core spesso registra utili messaggi di errore non disponibili nel log eventi dell'applicazione. Per abilitare e visualizzare i log stdout:

1. Nel portale di Azure passare all'app Web.
2. Nel pannello servizio app immettere kudu nella casella di ricerca.
3. Selezionare Strumenti>avanzati Vai.
4. Selezionare CmD della console > di debug.
5. Passare a sito/wwwroot
6. Selezionare l'icona a forma di matita per modificare il file web.config .
7. Nell'elemento <aspNetCore /> impostare stdoutLogEnabled="true" e selezionare Salva.

Disabilitare la registrazione stdout al termine della risoluzione dei problemi impostando stdoutLogEnabled="false".

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

log di debug del modulo core ASP.NET (servizio app Azure)

Il log di debug del modulo ASP.NET Core fornisce dati di registrazione aggiuntivi e più approfonditi dal modulo ASP.NET Core. Per abilitare e visualizzare i log stdout:

1. Per abilitare il log di diagnostica avanzato, eseguire una delle operazioni seguenti:
   • Seguire le istruzioni in Log di diagnostica avanzati per configurare l'app per la registrazione di diagnostica avanzata. Ridistribuire l'app.
   • Aggiungere il <handlerSettings> visualizzato nei log di diagnostica avanzati al file web.config dell'app live usando la console Kudu:
     1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
     2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
     3. Aprire le cartelle nel percorso site>wwwroot. Modificare il file web.config selezionando il pulsante a forma di matita. Aggiungere la sezione <handlerSettings> come illustrato in Log di diagnostica avanzati. Selezionare il pulsante Salva.
2. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
3. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
4. Aprire le cartelle nel percorso site>wwwroot. Se non è stato specificato un percorso per il file aspnetcore-debug.log, il file viene visualizzato nell'elenco. Se è stato specificato un percorso, passare al percorso del file di log.
5. Aprire il file di log con il pulsante a forma di matita accanto al nome del file.

Al termine della risoluzione dei problemi, disabilitare la registrazione di debug:

Per disabilitare il log di debug avanzato, eseguire le operazioni seguenti:

• Rimuovere <handlerSettings> dal file web.config in locale e ridistribuire l'app.
• Usare la console Kudu per modificare il file web.config e rimuovere la sezione <handlerSettings>. Salvare il file.

Per altre informazioni, vedere Creazione e reindirizzamento dei log con il modulo ASP.NET Core.

App lenta o non rispondente (servizio app Azure)

Quando un'app risponde lentamente o non risponde a una richiesta, vedere Risolvere i problemi di prestazioni lente dell'app Web in app Azure Servizio.

Pannelli di monitoraggio

I pannelli di monitoraggio forniscono un'esperienza di risoluzione dei problemi alternativa ai metodi descritti in precedenza in questo argomento. È possibile usare questi pannelli per diagnosticare gli errori della serie 500.

Verificare che le estensioni di ASP.NET Core siano installate. Se le estensioni non sono installate, installarle manualmente:

1. Nella sezione del pannello STRUMENTI DI SVILUPPO selezionare il pannello Estensioni.
2. Nell'elenco dovrebbe essere visualizzato ASP.NET Core Extensions (Estensioni ASP.NET Core).
3. Se le estensioni non sono installate, selezionare il pulsante Aggiungi.
4. Scegliere ASP.NET Core Extensions (Estensioni ASP.NET Core) dall'elenco.
5. Selezionare OK per accettare le condizioni legali.
6. Selezionare OK nel pannello Aggiungi estensione.
7. Un messaggio popup informativo indica quando le estensioni sono state installate correttamente.

Se la registrazione stdout non è abilitata, attenersi ai passaggi riportati di seguito:

1. Nel portale di Azure selezionare il pannello Strumenti avanzati nell'area STRUMENTI DI SVILUPPO. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire le cartelle nel percorso site>wwwroot e scorrere verso il basso fino a visualizzare il file web.config in fondo all'elenco.
4. Fare clic sull'icona della matita accanto al file web.config.
5. Impostare stdoutLogEnabled su true e cambiare il percorso di stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selezionare Salva per salvare il file web.config aggiornato.

Passare all'attivazione della registrazione diagnostica:

1. Nel portale di Azure selezionare il pannello Log di diagnostica.
2. Selezionare l'interruttore Attivato per Registrazione applicazioni (file system) e Messaggi di errore dettagliati. Selezionare il pulsante Salva nella parte superiore del pannello.
3. Per includere la traccia delle richieste non riuscite, anche nota come registrazione FREB (Failed Request Event Buffering), selezionare l'interruttore Attivato per Traccia delle richieste non riuscite.
4. Selezionare il pannello Flusso di registrazione, immediatamente sotto il pannello Log di diagnostica nel portale.
5. Effettuare una richiesta all'app.
6. Nei dati del flusso di registrazione viene indicata la causa dell'errore.

Al termine della risoluzione dei problemi, assicurarsi di disabilitare la registrazione stdout.

Per visualizzare i log di traccia delle richieste non riuscite (log FREB):

1. Passare al pannello Diagnostica e risolvi i problemi nel portale di Azure.
2. Selezionare Failed Request Tracing Logs (Log di traccia delle richieste non riuscite) nell'area STRUMENTI DI SUPPORTO della barra laterale.

Per altre informazioni, vedere la sezione relativa alla traccia delle richieste non riuscite nell'argomento Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure e Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure: Come si abilita la traccia delle richieste non riuscite?.

Per altre informazioni, vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure.

Risolvere i problemi in IIS

Registro eventi applicazioni (IIS)

Accedere al log eventi dell'applicazione:

1. Aprire il menu Start, cercare Visualizzatore eventi e selezionare l'app Visualizzatore eventi.
2. In Visualizzatore eventi aprire il nodo Registri di Windows.
3. Selezionare Applicazione per aprire il log eventi dell'applicazione.
4. Cercare gli errori associati all'app in cui si è verificato il problema. Gli errori presentano un valore Modulo AspNetCore IIS o Modulo AspNetCore IIS Express nella colonna Origine.

Eseguire l'app da un prompt dei comandi

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile individuare la causa di alcuni errori eseguendo l'app da un prompt dei comandi nel sistema host.

Distribuzione dipendente dal framework

Se l'app è una distribuzione dipendente dal framework:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare l'app eseguendo l'assembly dell'app con dotnet.exe. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: dotnet .\<assembly_name>.dll.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

Distribuzione autonoma

Se l'app è una distribuzione autonoma:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare il file eseguibile dell'app. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: <assembly_name>.exe.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

log stdout del modulo principale ASP.NET (IIS)

Per abilitare e visualizzare i log stdout:

1. Passare alla cartella di distribuzione del sito nel sistema host.
2. Se la cartella logs non è presente, creare la cartella. Per istruzioni su come impostare MSBuild per la creazione automatica della cartella logs nella distribuzione, vedere l'argomento Struttura della directory.
3. Modificare il file web.config. Impostare stdoutLogEnabled su true e modificare il percorso di stdoutLogFile in modo da fare riferimento alla cartella logs, ad esempio .\logs\stdout. stdout nel percorso è il prefisso del nome del file di log. Un timestamp, l'ID del processo e l'estensione del file vengono aggiunti automaticamente al momento della creazione del log. Usando stdout come prefisso del nome del file, un tipico file di log è denominato stdout_20180205184032_5412.log.
4. Verificare che il pool di applicazioni disponga delle autorizzazioni di identity scrittura per la cartella logs .
5. Salvare il file web.config aggiornato.
6. Effettuare una richiesta all'app.
7. Passare alla cartella logs. Trovare e aprire il log stdout più recente.
8. Esaminare il log per verificare se sono presenti errori.

Al termine della risoluzione dei problemi, disabilitare la registrazione stdout:

1. Modificare il file web.config.
2. Impostare stdoutLogEnabled su false.
3. Salvare il file.

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

log di debug del modulo core di ASP.NET (IIS)

Aggiungere le impostazioni del gestore seguenti al file web.config dell'app per abilitare ASP.NET log di debug del modulo core:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Verificare che il percorso specificato per il log esista e che il pool di app disponga delle autorizzazioni di identity scrittura per il percorso.

Per altre informazioni, vedere Creazione e reindirizzamento dei log con il modulo ASP.NET Core.

Abilitare la pagina delle eccezioni per gli sviluppatori

La ASPNETCORE_ENVIRONMENT variabile di ambiente può essere aggiunta a web.config per eseguire l'app nell'ambiente di sviluppo. Purché l'ambiente non sia sottoposto a override durante l'avvio dell'app tramite UseEnvironment nel generatore di host, l'impostazione della variabile di ambiente consente di visualizzare la pagina delle eccezioni per gli sviluppatori quando viene eseguita l'app.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

L'impostazione della variabile di ambiente per ASPNETCORE_ENVIRONMENT è consigliata solo per l'uso in server di gestione temporanea e test non esposti a Internet. Al termine della risoluzione dei problemi, rimuovere la variabile di ambiente dal file web.config. Per informazioni sull'impostazione delle variabili di ambiente in web.config, vedere elemento figlio environmentVariables di aspNetCore.

Ottenere dati da un'app

Se un'app è in grado di rispondere alle richieste, è possibile ottenere dati sulle richieste, le connessioni e altri dati dall'app tramite middleware inline di terminale. Per altre informazioni e codice di esempio, vedere Risolvere i problemi ed eseguire il debug di progetti di base ASP.NET.

App lenta o non risponde (IIS)

Un dump di arresto anomalo del sistema è uno snapshot della memoria del sistema e può aiutare a determinare la causa di un arresto anomalo dell'app, un errore di avvio o un'app lenta.

Arresto anomalo o eccezione di un'app

Ottenere e analizzare un dump da Segnalazione errori Windows:

1. Creare una cartella per i file dump di arresto anomalo del sistema in c:\dumps. Il pool di app deve avere accesso in scrittura alla cartella.

2. Eseguire lo script di PowerShell EnableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Eseguire l'app nelle condizioni che causano l'arresto anomalo.

4. Dopo che si è verificato l'arresto anomalo, eseguire lo script di PowerShell DisableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\DisableDumps dotnet.exe
     

Dopo l'arresto anomalo di un'app e la raccolta dei dump, l'app può terminare normalmente. Lo script di PowerShell configura Segnalazione errori Windows per raccogliere fino a cinque dump per ogni app.

L'app non risponde, non riesce durante l'avvio o viene eseguita normalmente

Quando un'app smette di rispondere ma non si arresta in modo anomalo, non riesce durante l'avvio o viene eseguita normalmente, vedi File di dump in modalità utente: scelta dello strumento migliore per selezionare uno strumento appropriato per produrre il dump.

Analizzare il dump

È possibile analizzare un dump usando diversi approcci. Per altre informazioni, vedere Analyzing a User-Mode Dump File (Analisi di un file dump in modalità utente).

Cancellare le cache dei pacchetti

Un'app funzionante potrebbe non riuscire immediatamente dopo l'aggiornamento di .NET Core SDK nel computer di sviluppo o la modifica delle versioni dei pacchetti all'interno dell'app. In alcuni casi i pacchetti incoerenti possono interrompere un'app quando si eseguono aggiornamenti principali. La maggior parte di questi problemi può essere risolta attenendosi alle istruzioni seguenti:

1. Eliminare le cartelle bin e obj.

2. Cancellare le cache dei pacchetti eseguendo dotnet nuget locals all --clear da una shell dei comandi.

   La cancellazione delle cache dei pacchetti può essere eseguita anche con lo strumento nuget.exe ed eseguendo il comando nuget locals all -clear. nuget.exe non è un'installazione inclusa con il sistema operativo desktop Windows e deve essere ottenuta separatamente dal sito Web NuGet.

3. Ripristinare e ricompilare il progetto.

4. Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.

Risorse aggiuntive

• Eseguire il debug di .NET e ASP.NET codice sorgente Core con Visual Studio
• Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core
• Risoluzione di errori comuni di Servizio app di Azure e IIS con ASP.NET Core
• Gestire gli errori in ASP.NET Core
• Modulo ASP.NET Core (ANCM) per IIS

Documentazione Azure

• Application Insights per ASP.NET Core
• Sezione Debug remoto delle app Web di Risolvere i problemi relativi a un'app Web nel servizio app Azure con Visual Studio
• Panoramica della diagnostica del servizio app di Azure
• Procedura: Eseguire il monitoraggio delle app nel servizio app di Azure
• Risoluzione dei problemi di un'app Web nel servizio app di Azure tramite Visual Studio
• Risolvere gli errori HTTP "502 - Gateway non valido" e "503 - Servizio non disponibile" nelle App Web di Azure
• Risoluzione dei problemi di rallentamento delle prestazioni delle app Web nel Servizio app di Azure
• Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure
• Azure Web App sandbox (App Service runtime execution limitations) (Sandbox per app Web di Azure - Limitazioni di esecuzione di runtime di Servizio app di Azure)

Documentazione di Visual Studio

• Debug remoto ASP.NET Core in IIS in Azure in Visual Studio 2017
• Debug remoto ASP.NET Core in un computer IIS remoto in Visual Studio 2017
• Informazioni sul debug tramite Visual Studio

Documentazione di Visual Studio Code

• Debugging with Visual Studio Code (Debug con Visual Studio Code)

Questo articolo fornisce informazioni sugli errori di avvio delle app comuni e istruzioni su come diagnosticare gli errori quando un'app viene distribuita nel servizio app Azure o IIS:

Errori di avvio dell'app
Illustra gli scenari comuni del codice di stato HTTP di avvio.

Risolvere i problemi relativi al servizio app Azure
Fornisce consigli per la risoluzione dei problemi per le app distribuite nel servizio app Azure.

Risolvere i problemi in IIS
Fornisce consigli per la risoluzione dei problemi per le app distribuite in IIS o in esecuzione in IIS Express in locale. Le linee guida si applicano sia alle distribuzioni di Windows Server che a windows desktop.

Cancellare le cache dei pacchetti
Spiega cosa fare quando i pacchetti incoerenti interrompono un'app durante l'esecuzione di aggiornamenti principali o la modifica delle versioni dei pacchetti.

Risorse aggiuntive
Elenca altri argomenti relativi alla risoluzione dei problemi.

Errori di avvio dell'app

In Visual Studio, per impostazione predefinita un progetto ASP.NET Core usa l'hosting in IIS Express durante il debug. 502.5 - Errore del processo o 500.30 - Errore di avvio che si verifica quando si esegue il debug in locale può essere diagnosticato usando i consigli in questo argomento.

403.14 Accesso negato

L'app non viene avviata. Viene registrato l'errore seguente:

The Web server is configured to not list the contents of this directory.

L'errore è in genere causato da una distribuzione interrotta nel sistema di hosting, che include uno degli scenari seguenti:

• L'app viene distribuita nella cartella errata nel sistema di hosting.
• Il processo di distribuzione non è riuscito a spostare tutti i file e le cartelle dell'app nella cartella di distribuzione nel sistema di hosting.
• Il file web.config non è presente nella distribuzione oppure il contenuto del file web.config non è valido.

Procedi come segue:

1. Eliminare tutti i file e le cartelle dalla cartella di distribuzione nel sistema di hosting.
2. Ridistribuire il contenuto della cartella di pubblicazione dell'app nel sistema di hosting usando il metodo normale di distribuzione, ad esempio Visual Studio, PowerShell o distribuzione manuale:
   • Verificare che il file web.config sia presente nella distribuzione e che il relativo contenuto sia corretto.
   • Quando si ospita nel servizio app Azure, verificare che l'app venga distribuita nella D:\home\site\wwwroot cartella .
   • Quando l'app è ospitata da IIS, verificare che l'app venga distribuita nel percorso fisico IIS visualizzato nelle impostazioni di base di Gestione IIS.
3. Verificare che tutti i file e le cartelle dell'app vengano distribuiti confrontando la distribuzione nel sistema di hosting con il contenuto della cartella di pubblicazione del progetto.

Per altre informazioni sul layout di un'app ASP.NET Core pubblicata, vedere ASP.NET struttura di directory Core. Per altre informazioni sul file web.config , vedere ASP.NET Core Module (ANCM) per IIS.

500 Errore interno del server

L'app viene avviata, ma un errore impedisce al server di soddisfare la richiesta.

Questo errore si verifica all'interno del codice dell'app durante l'avvio o durante la creazione di una risposta. La risposta potrebbe non avere alcun contenuto o essere visualizzata nel browser come un codice 500 Errore interno del server. Il log eventi dell'applicazione in genere indica che l'app è stata avviata normalmente. Dal punto di vista del server, questo è corretto. L'app è stata effettivamente avviata, ma non può generare una risposta valida. Per risolvere il problema, eseguire l'app dal prompt dei comandi nel server o abilitare il log stdout del modulo ASP.NET Core.

Questo errore può verificarsi anche quando il bundle di hosting .NET Core non è installato o è danneggiato. L'installazione o il ripristino dell'installazione del bundle di hosting .NET Core (per IIS) o di Visual Studio (per IIS Express) possono risolvere il problema.

500.0 Errore di caricamento del gestore in-process

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core non riesce a trovare .NET Core CLR e trovare il gestore delle richieste in-process (aspnetcorev2_inprocess.dll). Controllare che:

• L'app specifichi come destinazione il pacchetto NuGet Microsoft.AspNetCore.Server.IIS o il metapacchetto Microsoft.AspNetCore.App.
• Le versione del framework condiviso ASP.NET Core specificata come destinazione dall'app sia installata nel computer di destinazione.

500.0 Errore di caricamento del gestore out-of-process

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo core di ASP.NET non riesce a trovare il gestore di richieste di hosting out-of-process. Verificare che aspnetcorev2_outofprocess.dll sia presente in una sottocartella accanto ad aspnetcorev2.dll.

502.5 Process Failure (Errore del processo)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare il processo di lavoro, ma l'avvio non riesce. In genere è possibile determinare la causa di un errore di avvio del processo dalle voci nel log eventi dell'applicazione e nel log stdout del modulo ASP.NET Core.

Una condizione di errore comune è dovuta alla configurazione non corretta dell'app perché come destinazione viene specificata una versione del framework condiviso ASP.NET Core, che non è presente. Controllare le versioni del framework condiviso ASP.NET Core installate nel computer di destinazione. Il framework condiviso è il set di assembly (file DLL) che vengono installati nel computer e cui fa riferimento un metapacchetto, ad esempio Microsoft.AspNetCore.App. Il riferimento del metapacchetto può specificare una versione minima richiesta. Per altre informazioni, vedere The shared framework (Il framework condiviso).

La pagina di errore 502.5 Errore del processo viene restituita quando il processo di lavoro ha esito negativo a causa di un errore di configurazione dell'hosting o dell'app:

Non è stato possibile avviare l'aggiornamento dell'applicazione. Errore: 0x800700c1

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

L'app non è stata avviata perché non è stato possibile caricarne l'assembly (.dll).

Questo errore si verifica quando è presente una mancata corrispondenza del numero di bit tra l'app pubblicata e il processo w3wp/iisexpress.

Verificare che l'impostazione del pool di app a 32 bit sia corretta:

1. Selezionare il pool di app in Pool di applicazioni di Gestione IIS.
2. Selezionare Impostazioni avanzate in Modifica pool di applicazioni nel pannello Azioni.
3. Impostare Abilita applicazioni a 32 bit:
   • Se si sta sviluppando un'app a 32 bit (x86), impostare il valore su True.
   • Se si sta sviluppando un'app a 64 bit (x64), impostare il valore su False.

Verificare che non vi sia un conflitto tra una <Platform> proprietà MSBuild nel file di progetto e il livello di bit pubblicato dell'app.

Reimpostazione della connessione

Se si verifica un errore dopo l'invio delle intestazioni, è troppo tardi perché il server possa inviare un codice 500 Errore interno del server quando si verifica un errore. Questo spesso accade quando si verifica un errore durante la serializzazione di oggetti complessi per una risposta. Questo tipo di errore viene visualizzato come un errore di reimpostazione della connessione nel client. La registrazione delle applicazioni può consentire di risolvere questi tipi di errori.

Limiti di avvio predefiniti

Il modulo core ASP.NET è configurato con un valore predefinito startupTimeLimit di 120 secondi. Quando si mantiene il valore predefinito, l'avvio di un'app potrebbe richiedere fino a due minuti prima che il modulo registri un errore del processo. Per informazioni sulla configurazione del modulo, vedere Attributi dell'elemento aspNetCore.

Risolvere i problemi relativi al servizio app Azure

Registro eventi dell'applicazione (servizio app Azure)

Per accedere al log eventi dell'applicazione, usare il pannello Diagnostica e risolvi i problemi nel portale di Azure:

1. Nel portale di Azure aprire l'app in Servizi app.
2. Selezionare Diagnostica e risoluzione dei problemi.
3. Selezionare l'intestazione Strumenti di diagnostica.
4. In Strumenti di supporto selezionare il pulsante Eventi dell'applicazione.
5. Esaminare l'errore più recente dalla voce IIS AspNetCoreModule o IIS AspNetCoreModule V2 nella colonna Origine.

Un'alternativa all'uso del pannello Diagnostica e risolvi i problemi consiste nell'esaminare direttamente il file del log eventi dell'applicazione usando Kudu:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire la cartella LogFiles .
4. Selezionare l'icona a forma di matita accanto al eventlog.xml file.
5. Esaminare il log. Scorrere fino alla fine del log per visualizzare gli eventi più recenti.

Eseguire l'app nella console Kudu

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile eseguire l'app nella console di esecuzione remota Kudu per individuare l'errore:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.

Test di un'app a 32 bit (x86)

Versione corrente

1. cd d:\home\site\wwwroot
2. Eseguire l'app:

   • Se l'app è una distribuzione dipendente dal framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se l'app è una distribuzione autonoma:

     {ASSEMBLY NAME}.exe
     

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Test di un'app a 64 bit (x64)

Versione corrente

• Se l'app è una distribuzione dipendente dal framework a 64 bit (x64):
  1. cd D:\Program Files\dotnet
  2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se l'app è una distribuzione autonoma:
  1. cd D:\home\site\wwwroot
  2. Eseguire l'app: {ASSEMBLY NAME}.exe

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

log stdout del modulo core ASP.NET (servizio app Azure)

Il log stdout del modulo ASP.NET Core spesso registra utili messaggi di errore non disponibili nel log eventi dell'applicazione. Per abilitare e visualizzare i log stdout:

1. Passare al pannello Diagnostica e risolvi i problemi nel portale di Azure.
2. In SELECT PROBLEM CATEGORY (SELEZIONARE LA CATEGORIA DEL PROBLEMA) selezionare il pulsante Web App Down (App Web inattiva).
3. In Suggested Solutions (Soluzioni consigliate) >Enable Stdout Log Redirection (Abilita il reindirizzamento del log Stdout) selezionare il pulsante Open Kudu Console to edit Web.Config (Apri la console Kudu per modificare Web.Config).
4. Nella console diagnostica Kudu aprire le cartelle nel percorso site>wwwroot. Scorrere verso il basso fino a visualizzare il file web.config in fondo all'elenco.
5. Fare clic sull'icona della matita accanto al file web.config.
6. Impostare stdoutLogEnabled su true e cambiare il percorso di stdoutLogFile in: \\?\%home%\LogFiles\stdout.
7. Selezionare Salva per salvare il file web.config aggiornato.
8. Effettuare una richiesta all'app.
9. Tornare al portale di Azure. Selezionare il pannello Strumenti avanzati nell'area STRUMENTI DI SVILUPPO. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
10. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
11. Selezionare la cartella LogFiles.
12. Controllare la colonna Data modifica e selezionare l'icona della matita per modificare il log stdout con la data di modifica più recente.
13. Quando si apre il file di log, verrà visualizzato l'errore.

Al termine della risoluzione dei problemi, disabilitare la registrazione stdout:

1. Nella console diagnostica Kudu tornare al percorso site>wwwroot per visualizzare il file web.config. Aprire nuovamente il file web.config selezionando l'icona della matita.
2. Impostare stdoutLogEnabled su false.
3. Selezionare Salva per salvare il file.

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

log di debug del modulo core ASP.NET (servizio app Azure)

Il log di debug del modulo ASP.NET Core fornisce dati di registrazione aggiuntivi e più approfonditi dal modulo ASP.NET Core. Per abilitare e visualizzare i log stdout:

1. Per abilitare il log di diagnostica avanzato, eseguire una delle operazioni seguenti:
   • Seguire le istruzioni in Log di diagnostica avanzati per configurare l'app per la registrazione di diagnostica avanzata. Ridistribuire l'app.
   • Aggiungere il <handlerSettings> visualizzato nei log di diagnostica avanzati al file web.config dell'app live usando la console Kudu:
     1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
     2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
     3. Aprire le cartelle nel percorso site>wwwroot. Modificare il file web.config selezionando il pulsante a forma di matita. Aggiungere la sezione <handlerSettings> come illustrato in Log di diagnostica avanzati. Selezionare il pulsante Salva.
2. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
3. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
4. Aprire le cartelle nel percorso site>wwwroot. Se non è stato specificato un percorso per il file aspnetcore-debug.log, il file viene visualizzato nell'elenco. Se è stato specificato un percorso, passare al percorso del file di log.
5. Aprire il file di log con il pulsante a forma di matita accanto al nome del file.

Al termine della risoluzione dei problemi, disabilitare la registrazione di debug:

Per disabilitare il log di debug avanzato, eseguire le operazioni seguenti:

• Rimuovere <handlerSettings> dal file web.config in locale e ridistribuire l'app.
• Usare la console Kudu per modificare il file web.config e rimuovere la sezione <handlerSettings>. Salvare il file.

Per altre informazioni, vedere Creazione e reindirizzamento dei log con il modulo ASP.NET Core.

App lenta o non risponde (servizio app Azure)

Quando un'app risponde lentamente o non risponde a una richiesta, vedere gli articoli seguenti:

• Risoluzione dei problemi di rallentamento delle prestazioni delle app Web nel Servizio app di Azure
• Use Crash Diagnoser Site Extension to Capture Dump for Intermittent Exception issues or performance issues on Azure Web App (Usare l'estensione del sito Crash Diagnoser per acquisire il dump per i problemi di eccezioni intermittenti o i problemi di prestazioni nell'app Web di Azure)

Pannelli di monitoraggio

I pannelli di monitoraggio forniscono un'esperienza di risoluzione dei problemi alternativa ai metodi descritti in precedenza in questo argomento. È possibile usare questi pannelli per diagnosticare gli errori della serie 500.

Verificare che le estensioni di ASP.NET Core siano installate. Se le estensioni non sono installate, installarle manualmente:

1. Nella sezione del pannello STRUMENTI DI SVILUPPO selezionare il pannello Estensioni.
2. Nell'elenco dovrebbe essere visualizzato ASP.NET Core Extensions (Estensioni ASP.NET Core).
3. Se le estensioni non sono installate, selezionare il pulsante Aggiungi.
4. Scegliere ASP.NET Core Extensions (Estensioni ASP.NET Core) dall'elenco.
5. Selezionare OK per accettare le condizioni legali.
6. Selezionare OK nel pannello Aggiungi estensione.
7. Un messaggio popup informativo indica quando le estensioni sono state installate correttamente.

Se la registrazione stdout non è abilitata, attenersi ai passaggi riportati di seguito:

1. Nel portale di Azure selezionare il pannello Strumenti avanzati nell'area STRUMENTI DI SVILUPPO. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire le cartelle nel percorso site>wwwroot e scorrere verso il basso fino a visualizzare il file web.config in fondo all'elenco.
4. Fare clic sull'icona della matita accanto al file web.config.
5. Impostare stdoutLogEnabled su true e cambiare il percorso di stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selezionare Salva per salvare il file web.config aggiornato.

Passare all'attivazione della registrazione diagnostica:

1. Nel portale di Azure selezionare il pannello Log di diagnostica.
2. Selezionare l'interruttore Attivato per Registrazione applicazioni (file system) e Messaggi di errore dettagliati. Selezionare il pulsante Salva nella parte superiore del pannello.
3. Per includere la traccia delle richieste non riuscite, anche nota come registrazione FREB (Failed Request Event Buffering), selezionare l'interruttore Attivato per Traccia delle richieste non riuscite.
4. Selezionare il pannello Flusso di registrazione, immediatamente sotto il pannello Log di diagnostica nel portale.
5. Effettuare una richiesta all'app.
6. Nei dati del flusso di registrazione viene indicata la causa dell'errore.

Al termine della risoluzione dei problemi, assicurarsi di disabilitare la registrazione stdout.

Per visualizzare i log di traccia delle richieste non riuscite (log FREB):

1. Passare al pannello Diagnostica e risolvi i problemi nel portale di Azure.
2. Selezionare Failed Request Tracing Logs (Log di traccia delle richieste non riuscite) nell'area STRUMENTI DI SUPPORTO della barra laterale.

Per altre informazioni, vedere la sezione relativa alla traccia delle richieste non riuscite nell'argomento Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure e Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure: Come si abilita la traccia delle richieste non riuscite?.

Per altre informazioni, vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure.

Risolvere i problemi in IIS

Registro eventi applicazioni (IIS)

Accedere al log eventi dell'applicazione:

1. Aprire il menu Start, cercare Visualizzatore eventi e selezionare l'app Visualizzatore eventi.
2. In Visualizzatore eventi aprire il nodo Registri di Windows.
3. Selezionare Applicazione per aprire il log eventi dell'applicazione.
4. Cercare gli errori associati all'app in cui si è verificato il problema. Gli errori presentano un valore Modulo AspNetCore IIS o Modulo AspNetCore IIS Express nella colonna Origine.

Eseguire l'app da un prompt dei comandi

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile individuare la causa di alcuni errori eseguendo l'app da un prompt dei comandi nel sistema host.

Distribuzione dipendente dal framework

Se l'app è una distribuzione dipendente dal framework:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare l'app eseguendo l'assembly dell'app con dotnet.exe. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: dotnet .\<assembly_name>.dll.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

Distribuzione autonoma

Se l'app è una distribuzione autonoma:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare il file eseguibile dell'app. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: <assembly_name>.exe.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

log stdout del modulo principale ASP.NET (IIS)

Per abilitare e visualizzare i log stdout:

1. Passare alla cartella di distribuzione del sito nel sistema host.
2. Se la cartella logs non è presente, creare la cartella. Per istruzioni su come impostare MSBuild per la creazione automatica della cartella logs nella distribuzione, vedere l'argomento Struttura della directory.
3. Modificare il file web.config. Impostare stdoutLogEnabled su true e modificare il percorso di stdoutLogFile in modo da fare riferimento alla cartella logs, ad esempio .\logs\stdout. stdout nel percorso è il prefisso del nome del file di log. Un timestamp, l'ID del processo e l'estensione del file vengono aggiunti automaticamente al momento della creazione del log. Usando stdout come prefisso del nome del file, un tipico file di log è denominato stdout_20180205184032_5412.log.
4. Verificare che il pool di applicazioni disponga delle autorizzazioni di identity scrittura per la cartella logs .
5. Salvare il file web.config aggiornato.
6. Effettuare una richiesta all'app.
7. Passare alla cartella logs. Trovare e aprire il log stdout più recente.
8. Esaminare il log per verificare se sono presenti errori.

Al termine della risoluzione dei problemi, disabilitare la registrazione stdout:

1. Modificare il file web.config.
2. Impostare stdoutLogEnabled su false.
3. Salvare il file.

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

log di debug del modulo core di ASP.NET (IIS)

Aggiungere le impostazioni del gestore seguenti al file web.config dell'app per abilitare ASP.NET log di debug del modulo core:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Verificare che il percorso specificato per il log esista e che il pool di app disponga delle autorizzazioni di identity scrittura per il percorso.

Per altre informazioni, vedere Creazione e reindirizzamento dei log con il modulo ASP.NET Core.

Abilitare la pagina delle eccezioni per gli sviluppatori

La ASPNETCORE_ENVIRONMENT variabile di ambiente può essere aggiunta a web.config per eseguire l'app nell'ambiente di sviluppo. Purché l'ambiente non sia sottoposto a override durante l'avvio dell'app tramite UseEnvironment nel generatore di host, l'impostazione della variabile di ambiente consente di visualizzare la pagina delle eccezioni per gli sviluppatori quando viene eseguita l'app.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

L'impostazione della variabile di ambiente per ASPNETCORE_ENVIRONMENT è consigliata solo per l'uso in server di gestione temporanea e test non esposti a Internet. Al termine della risoluzione dei problemi, rimuovere la variabile di ambiente dal file web.config. Per informazioni sull'impostazione delle variabili di ambiente in web.config, vedere elemento figlio environmentVariables di aspNetCore.

Ottenere dati da un'app

Se un'app è in grado di rispondere alle richieste, è possibile ottenere dati sulle richieste, le connessioni e altri dati dall'app tramite middleware inline di terminale. Per altre informazioni e codice di esempio, vedere Risolvere i problemi ed eseguire il debug di progetti di base ASP.NET.

App lenta o non risponde (IIS)

Un dump di arresto anomalo del sistema è uno snapshot della memoria del sistema e può aiutare a determinare la causa di un arresto anomalo dell'app, un errore di avvio o un'app lenta.

Arresto anomalo o eccezione di un'app

Ottenere e analizzare un dump da Segnalazione errori Windows:

1. Creare una cartella per i file dump di arresto anomalo del sistema in c:\dumps. Il pool di app deve avere accesso in scrittura alla cartella.

2. Eseguire lo script di PowerShell EnableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Eseguire l'app nelle condizioni che causano l'arresto anomalo.

4. Dopo che si è verificato l'arresto anomalo, eseguire lo script di PowerShell DisableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\DisableDumps dotnet.exe
     

Dopo l'arresto anomalo di un'app e la raccolta dei dump, l'app può terminare normalmente. Lo script di PowerShell configura Segnalazione errori Windows per raccogliere fino a cinque dump per ogni app.

L'app non risponde, non riesce durante l'avvio o viene eseguita normalmente

Quando un'app smette di rispondere ma non si arresta in modo anomalo, non riesce durante l'avvio o viene eseguita normalmente, vedi File di dump in modalità utente: scelta dello strumento migliore per selezionare uno strumento appropriato per produrre il dump.

Analizzare il dump

È possibile analizzare un dump usando diversi approcci. Per altre informazioni, vedere Analyzing a User-Mode Dump File (Analisi di un file dump in modalità utente).

Cancellare le cache dei pacchetti

Un'app funzionante potrebbe non riuscire immediatamente dopo l'aggiornamento di .NET Core SDK nel computer di sviluppo o la modifica delle versioni dei pacchetti all'interno dell'app. In alcuni casi i pacchetti incoerenti possono interrompere un'app quando si eseguono aggiornamenti principali. La maggior parte di questi problemi può essere risolta attenendosi alle istruzioni seguenti:

1. Eliminare le cartelle bin e obj.

2. Cancellare le cache dei pacchetti eseguendo dotnet nuget locals all --clear da una shell dei comandi.

   La cancellazione delle cache dei pacchetti può essere eseguita anche con lo strumento nuget.exe ed eseguendo il comando nuget locals all -clear. nuget.exe non è un'installazione inclusa con il sistema operativo desktop Windows e deve essere ottenuta separatamente dal sito Web NuGet.

3. Ripristinare e ricompilare il progetto.

4. Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.

Risorse aggiuntive

• Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core
• Risoluzione di errori comuni di Servizio app di Azure e IIS con ASP.NET Core
• Gestire gli errori in ASP.NET Core
• Modulo ASP.NET Core (ANCM) per IIS

Documentazione Azure

• Application Insights per ASP.NET Core
• Sezione Debug remoto delle app Web di Risolvere i problemi relativi a un'app Web nel servizio app Azure con Visual Studio
• Panoramica della diagnostica del servizio app di Azure
• Procedura: Eseguire il monitoraggio delle app nel servizio app di Azure
• Risoluzione dei problemi di un'app Web nel servizio app di Azure tramite Visual Studio
• Risolvere gli errori HTTP "502 - Gateway non valido" e "503 - Servizio non disponibile" nelle App Web di Azure
• Risoluzione dei problemi di rallentamento delle prestazioni delle app Web nel Servizio app di Azure
• Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure
• Azure Web App sandbox (App Service runtime execution limitations) (Sandbox per app Web di Azure - Limitazioni di esecuzione di runtime di Servizio app di Azure)

Documentazione di Visual Studio

• Debug remoto ASP.NET Core in IIS in Azure in Visual Studio 2017
• Debug remoto ASP.NET Core in un computer IIS remoto in Visual Studio 2017
• Informazioni sul debug tramite Visual Studio

Documentazione di Visual Studio Code

• Debugging with Visual Studio Code (Debug con Visual Studio Code)

Questo articolo fornisce informazioni sugli errori di avvio delle app comuni e istruzioni su come diagnosticare gli errori quando un'app viene distribuita nel servizio app Azure o IIS:

Errori di avvio dell'app
Illustra gli scenari comuni del codice di stato HTTP di avvio.

Risolvere i problemi relativi al servizio app Azure
Fornisce consigli per la risoluzione dei problemi per le app distribuite nel servizio app Azure.

Risolvere i problemi in IIS
Fornisce consigli per la risoluzione dei problemi per le app distribuite in IIS o in esecuzione in IIS Express in locale. Le linee guida si applicano sia alle distribuzioni di Windows Server che a windows desktop.

Cancellare le cache dei pacchetti
Spiega cosa fare quando i pacchetti incoerenti interrompono un'app durante l'esecuzione di aggiornamenti principali o la modifica delle versioni dei pacchetti.

Risorse aggiuntive
Elenca altri argomenti relativi alla risoluzione dei problemi.

Errori di avvio dell'app

In Visual Studio, per impostazione predefinita un progetto ASP.NET Core usa l'hosting in IIS Express durante il debug. Errore di processo 502.5 che si verifica durante il debug in locale usando i consigli in questo argomento.

403.14 Accesso negato

L'app non viene avviata. Viene registrato l'errore seguente:

The Web server is configured to not list the contents of this directory.

L'errore è in genere causato da una distribuzione interrotta nel sistema di hosting, che include uno degli scenari seguenti:

• L'app viene distribuita nella cartella errata nel sistema di hosting.
• Il processo di distribuzione non è riuscito a spostare tutti i file e le cartelle dell'app nella cartella di distribuzione nel sistema di hosting.
• Il file web.config non è presente nella distribuzione oppure il contenuto del file web.config non è valido.

Procedi come segue:

1. Eliminare tutti i file e le cartelle dalla cartella di distribuzione nel sistema di hosting.
2. Ridistribuire il contenuto della cartella di pubblicazione dell'app nel sistema di hosting usando il metodo normale di distribuzione, ad esempio Visual Studio, PowerShell o distribuzione manuale:
   • Verificare che il file web.config sia presente nella distribuzione e che il relativo contenuto sia corretto.
   • Quando si ospita nel servizio app Azure, verificare che l'app venga distribuita nella D:\home\site\wwwroot cartella .
   • Quando l'app è ospitata da IIS, verificare che l'app venga distribuita nel percorso fisico IIS visualizzato nelle impostazioni di base di Gestione IIS.
3. Verificare che tutti i file e le cartelle dell'app vengano distribuiti confrontando la distribuzione nel sistema di hosting con il contenuto della cartella di pubblicazione del progetto.

Per altre informazioni sul layout di un'app ASP.NET Core pubblicata, vedere ASP.NET struttura di directory Core. Per altre informazioni sul file web.config , vedere ASP.NET Core Module (ANCM) per IIS.

500 Errore interno del server

L'app viene avviata, ma un errore impedisce al server di soddisfare la richiesta.

Questo errore si verifica all'interno del codice dell'app durante l'avvio o durante la creazione di una risposta. La risposta potrebbe non avere alcun contenuto o essere visualizzata nel browser come un codice 500 Errore interno del server. Il log eventi dell'applicazione in genere indica che l'app è stata avviata normalmente. Dal punto di vista del server, questo è corretto. L'app è stata effettivamente avviata, ma non può generare una risposta valida. Per risolvere il problema, eseguire l'app dal prompt dei comandi nel server o abilitare il log stdout del modulo ASP.NET Core.

Questo errore può verificarsi anche quando il bundle di hosting .NET Core non è installato o è danneggiato. L'installazione o il ripristino dell'installazione del bundle di hosting .NET Core (per IIS) o di Visual Studio (per IIS Express) possono risolvere il problema.

502.5 Process Failure (Errore del processo)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare il processo di lavoro, ma l'avvio non riesce. In genere è possibile determinare la causa di un errore di avvio del processo dalle voci nel log eventi dell'applicazione e nel log stdout del modulo ASP.NET Core.

Una condizione di errore comune è dovuta alla configurazione non corretta dell'app perché come destinazione viene specificata una versione del framework condiviso ASP.NET Core, che non è presente. Controllare le versioni del framework condiviso ASP.NET Core installate nel computer di destinazione. Il framework condiviso è il set di assembly (file DLL) che vengono installati nel computer e cui fa riferimento un metapacchetto, ad esempio Microsoft.AspNetCore.App. Il riferimento del metapacchetto può specificare una versione minima richiesta. Per altre informazioni, vedere The shared framework (Il framework condiviso).

La pagina di errore 502.5 Errore del processo viene restituita quando il processo di lavoro ha esito negativo a causa di un errore di configurazione dell'hosting o dell'app:

Non è stato possibile avviare l'aggiornamento dell'applicazione. Errore: 0x800700c1

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

L'app non è stata avviata perché non è stato possibile caricarne l'assembly (.dll).

Questo errore si verifica quando è presente una mancata corrispondenza del numero di bit tra l'app pubblicata e il processo w3wp/iisexpress.

Verificare che l'impostazione del pool di app a 32 bit sia corretta:

1. Selezionare il pool di app in Pool di applicazioni di Gestione IIS.
2. Selezionare Impostazioni avanzate in Modifica pool di applicazioni nel pannello Azioni.
3. Impostare Abilita applicazioni a 32 bit:
   • Se si sta sviluppando un'app a 32 bit (x86), impostare il valore su True.
   • Se si sta sviluppando un'app a 64 bit (x64), impostare il valore su False.

Verificare che non vi sia un conflitto tra una <Platform> proprietà MSBuild nel file di progetto e il livello di bit pubblicato dell'app.

Reimpostazione della connessione

Se si verifica un errore dopo l'invio delle intestazioni, è troppo tardi perché il server possa inviare un codice 500 Errore interno del server quando si verifica un errore. Questo spesso accade quando si verifica un errore durante la serializzazione di oggetti complessi per una risposta. Questo tipo di errore viene visualizzato come un errore di reimpostazione della connessione nel client. La registrazione delle applicazioni può consentire di risolvere questi tipi di errori.

Limiti di avvio predefiniti

Il modulo core ASP.NET è configurato con un valore predefinito startupTimeLimit di 120 secondi. Quando si mantiene il valore predefinito, l'avvio di un'app potrebbe richiedere fino a due minuti prima che il modulo registri un errore del processo. Per informazioni sulla configurazione del modulo, vedere Attributi dell'elemento aspNetCore.

Risolvere i problemi relativi al servizio app Azure

Registro eventi dell'applicazione (servizio app Azure)

Per accedere al log eventi dell'applicazione, usare il pannello Diagnostica e risolvi i problemi nel portale di Azure:

1. Nel portale di Azure aprire l'app in Servizi app.
2. Selezionare Diagnostica e risoluzione dei problemi.
3. Selezionare l'intestazione Strumenti di diagnostica.
4. In Strumenti di supporto selezionare il pulsante Eventi dell'applicazione.
5. Esaminare l'errore più recente dalla voce IIS AspNetCoreModule o IIS AspNetCoreModule V2 nella colonna Origine.

Un'alternativa all'uso del pannello Diagnostica e risolvi i problemi consiste nell'esaminare direttamente il file del log eventi dell'applicazione usando Kudu:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire la cartella LogFiles .
4. Selezionare l'icona a forma di matita accanto al eventlog.xml file.
5. Esaminare il log. Scorrere fino alla fine del log per visualizzare gli eventi più recenti.

Eseguire l'app nella console Kudu

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile eseguire l'app nella console di esecuzione remota Kudu per individuare l'errore:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.

Test di un'app a 32 bit (x86)

Versione corrente

1. cd d:\home\site\wwwroot
2. Eseguire l'app:

   • Se l'app è una distribuzione dipendente dal framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se l'app è una distribuzione autonoma:

     {ASSEMBLY NAME}.exe
     

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Test di un'app a 64 bit (x64)

Versione corrente

• Se l'app è una distribuzione dipendente dal framework a 64 bit (x64):
  1. cd D:\Program Files\dotnet
  2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se l'app è una distribuzione autonoma:
  1. cd D:\home\site\wwwroot
  2. Eseguire l'app: {ASSEMBLY NAME}.exe

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

log stdout del modulo core ASP.NET (servizio app Azure)

Il log stdout del modulo ASP.NET Core spesso registra utili messaggi di errore non disponibili nel log eventi dell'applicazione. Per abilitare e visualizzare i log stdout:

1. Passare al pannello Diagnostica e risolvi i problemi nel portale di Azure.
2. In SELECT PROBLEM CATEGORY (SELEZIONARE LA CATEGORIA DEL PROBLEMA) selezionare il pulsante Web App Down (App Web inattiva).
3. In Suggested Solutions (Soluzioni consigliate) >Enable Stdout Log Redirection (Abilita il reindirizzamento del log Stdout) selezionare il pulsante Open Kudu Console to edit Web.Config (Apri la console Kudu per modificare Web.Config).
4. Nella console diagnostica Kudu aprire le cartelle nel percorso site>wwwroot. Scorrere verso il basso fino a visualizzare il file web.config in fondo all'elenco.
5. Fare clic sull'icona della matita accanto al file web.config.
6. Impostare stdoutLogEnabled su true e cambiare il percorso di stdoutLogFile in: \\?\%home%\LogFiles\stdout.
7. Selezionare Salva per salvare il file web.config aggiornato.
8. Effettuare una richiesta all'app.
9. Tornare al portale di Azure. Selezionare il pannello Strumenti avanzati nell'area STRUMENTI DI SVILUPPO. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
10. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
11. Selezionare la cartella LogFiles.
12. Controllare la colonna Data modifica e selezionare l'icona della matita per modificare il log stdout con la data di modifica più recente.
13. Quando si apre il file di log, verrà visualizzato l'errore.

Al termine della risoluzione dei problemi, disabilitare la registrazione stdout:

1. Nella console diagnostica Kudu tornare al percorso site>wwwroot per visualizzare il file web.config. Aprire nuovamente il file web.config selezionando l'icona della matita.
2. Impostare stdoutLogEnabled su false.
3. Selezionare Salva per salvare il file.

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

App lenta o non risponde (servizio app Azure)

Quando un'app risponde lentamente o non risponde a una richiesta, vedere gli articoli seguenti:

• Risoluzione dei problemi di rallentamento delle prestazioni delle app Web nel Servizio app di Azure
• Use Crash Diagnoser Site Extension to Capture Dump for Intermittent Exception issues or performance issues on Azure Web App (Usare l'estensione del sito Crash Diagnoser per acquisire il dump per i problemi di eccezioni intermittenti o i problemi di prestazioni nell'app Web di Azure)

Pannelli di monitoraggio

I pannelli di monitoraggio forniscono un'esperienza di risoluzione dei problemi alternativa ai metodi descritti in precedenza in questo argomento. È possibile usare questi pannelli per diagnosticare gli errori della serie 500.

Verificare che le estensioni di ASP.NET Core siano installate. Se le estensioni non sono installate, installarle manualmente:

1. Nella sezione del pannello STRUMENTI DI SVILUPPO selezionare il pannello Estensioni.
2. Nell'elenco dovrebbe essere visualizzato ASP.NET Core Extensions (Estensioni ASP.NET Core).
3. Se le estensioni non sono installate, selezionare il pulsante Aggiungi.
4. Scegliere ASP.NET Core Extensions (Estensioni ASP.NET Core) dall'elenco.
5. Selezionare OK per accettare le condizioni legali.
6. Selezionare OK nel pannello Aggiungi estensione.
7. Un messaggio popup informativo indica quando le estensioni sono state installate correttamente.

Se la registrazione stdout non è abilitata, attenersi ai passaggi riportati di seguito:

1. Nel portale di Azure selezionare il pannello Strumenti avanzati nell'area STRUMENTI DI SVILUPPO. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire le cartelle nel percorso site>wwwroot e scorrere verso il basso fino a visualizzare il file web.config in fondo all'elenco.
4. Fare clic sull'icona della matita accanto al file web.config.
5. Impostare stdoutLogEnabled su true e cambiare il percorso di stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selezionare Salva per salvare il file web.config aggiornato.

Passare all'attivazione della registrazione diagnostica:

1. Nel portale di Azure selezionare il pannello Log di diagnostica.
2. Selezionare l'interruttore Attivato per Registrazione applicazioni (file system) e Messaggi di errore dettagliati. Selezionare il pulsante Salva nella parte superiore del pannello.
3. Per includere la traccia delle richieste non riuscite, anche nota come registrazione FREB (Failed Request Event Buffering), selezionare l'interruttore Attivato per Traccia delle richieste non riuscite.
4. Selezionare il pannello Flusso di registrazione, immediatamente sotto il pannello Log di diagnostica nel portale.
5. Effettuare una richiesta all'app.
6. Nei dati del flusso di registrazione viene indicata la causa dell'errore.

Al termine della risoluzione dei problemi, assicurarsi di disabilitare la registrazione stdout.

Per visualizzare i log di traccia delle richieste non riuscite (log FREB):

1. Passare al pannello Diagnostica e risolvi i problemi nel portale di Azure.
2. Selezionare Failed Request Tracing Logs (Log di traccia delle richieste non riuscite) nell'area STRUMENTI DI SUPPORTO della barra laterale.

Per altre informazioni, vedere la sezione relativa alla traccia delle richieste non riuscite nell'argomento Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure e Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure: Come si abilita la traccia delle richieste non riuscite?.

Per altre informazioni, vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure.

Risolvere i problemi in IIS

Registro eventi applicazioni (IIS)

Accedere al log eventi dell'applicazione:

1. Aprire il menu Start, cercare Visualizzatore eventi e selezionare l'app Visualizzatore eventi.
2. In Visualizzatore eventi aprire il nodo Registri di Windows.
3. Selezionare Applicazione per aprire il log eventi dell'applicazione.
4. Cercare gli errori associati all'app in cui si è verificato il problema. Gli errori presentano un valore Modulo AspNetCore IIS o Modulo AspNetCore IIS Express nella colonna Origine.

Eseguire l'app da un prompt dei comandi

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile individuare la causa di alcuni errori eseguendo l'app da un prompt dei comandi nel sistema host.

Distribuzione dipendente dal framework

Se l'app è una distribuzione dipendente dal framework:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare l'app eseguendo l'assembly dell'app con dotnet.exe. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: dotnet .\<assembly_name>.dll.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

Distribuzione autonoma

Se l'app è una distribuzione autonoma:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare il file eseguibile dell'app. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: <assembly_name>.exe.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

log stdout del modulo principale ASP.NET (IIS)

Per abilitare e visualizzare i log stdout:

1. Passare alla cartella di distribuzione del sito nel sistema host.
2. Se la cartella logs non è presente, creare la cartella. Per istruzioni su come impostare MSBuild per la creazione automatica della cartella logs nella distribuzione, vedere l'argomento Struttura della directory.
3. Modificare il file web.config. Impostare stdoutLogEnabled su true e modificare il percorso di stdoutLogFile in modo da fare riferimento alla cartella logs, ad esempio .\logs\stdout. stdout nel percorso è il prefisso del nome del file di log. Un timestamp, l'ID del processo e l'estensione del file vengono aggiunti automaticamente al momento della creazione del log. Usando stdout come prefisso del nome del file, un tipico file di log è denominato stdout_20180205184032_5412.log.
4. Verificare che il pool di applicazioni disponga delle autorizzazioni di identity scrittura per la cartella logs .
5. Salvare il file web.config aggiornato.
6. Effettuare una richiesta all'app.
7. Passare alla cartella logs. Trovare e aprire il log stdout più recente.
8. Esaminare il log per verificare se sono presenti errori.

Al termine della risoluzione dei problemi, disabilitare la registrazione stdout:

1. Modificare il file web.config.
2. Impostare stdoutLogEnabled su false.
3. Salvare il file.

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

Abilitare la pagina delle eccezioni per gli sviluppatori

La ASPNETCORE_ENVIRONMENT variabile di ambiente può essere aggiunta a web.config per eseguire l'app nell'ambiente di sviluppo. Purché l'ambiente non sia sottoposto a override durante l'avvio dell'app tramite UseEnvironment nel generatore di host, l'impostazione della variabile di ambiente consente di visualizzare la pagina delle eccezioni per gli sviluppatori quando viene eseguita l'app.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

L'impostazione della variabile di ambiente per ASPNETCORE_ENVIRONMENT è consigliata solo per l'uso in server di gestione temporanea e test non esposti a Internet. Al termine della risoluzione dei problemi, rimuovere la variabile di ambiente dal file web.config. Per informazioni sull'impostazione delle variabili di ambiente in web.config, vedere elemento figlio environmentVariables di aspNetCore.

Ottenere dati da un'app

Se un'app è in grado di rispondere alle richieste, è possibile ottenere dati sulle richieste, le connessioni e altri dati dall'app tramite middleware inline di terminale. Per altre informazioni e codice di esempio, vedere Risolvere i problemi ed eseguire il debug di progetti di base ASP.NET.

App lenta o non risponde (IIS)

Un dump di arresto anomalo del sistema è uno snapshot della memoria del sistema e può aiutare a determinare la causa di un arresto anomalo dell'app, un errore di avvio o un'app lenta.

Arresto anomalo o eccezione di un'app

Ottenere e analizzare un dump da Segnalazione errori Windows:

1. Creare una cartella per i file dump di arresto anomalo del sistema in c:\dumps. Il pool di app deve avere accesso in scrittura alla cartella.

2. Eseguire lo script di PowerShell EnableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Eseguire l'app nelle condizioni che causano l'arresto anomalo.

4. Dopo che si è verificato l'arresto anomalo, eseguire lo script di PowerShell DisableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\DisableDumps dotnet.exe
     

Dopo l'arresto anomalo di un'app e la raccolta dei dump, l'app può terminare normalmente. Lo script di PowerShell configura Segnalazione errori Windows per raccogliere fino a cinque dump per ogni app.

L'app non risponde, non riesce durante l'avvio o viene eseguita normalmente

Quando un'app smette di rispondere ma non si arresta in modo anomalo, non riesce durante l'avvio o viene eseguita normalmente, vedi File di dump in modalità utente: scelta dello strumento migliore per selezionare uno strumento appropriato per produrre il dump.

Analizzare il dump

È possibile analizzare un dump usando diversi approcci. Per altre informazioni, vedere Analyzing a User-Mode Dump File (Analisi di un file dump in modalità utente).

Cancellare le cache dei pacchetti

Un'app funzionante potrebbe non riuscire immediatamente dopo l'aggiornamento di .NET Core SDK nel computer di sviluppo o la modifica delle versioni dei pacchetti all'interno dell'app. In alcuni casi i pacchetti incoerenti possono interrompere un'app quando si eseguono aggiornamenti principali. La maggior parte di questi problemi può essere risolta attenendosi alle istruzioni seguenti:

1. Eliminare le cartelle bin e obj.

2. Cancellare le cache dei pacchetti eseguendo dotnet nuget locals all --clear da una shell dei comandi.

   La cancellazione delle cache dei pacchetti può essere eseguita anche con lo strumento nuget.exe ed eseguendo il comando nuget locals all -clear. nuget.exe non è un'installazione inclusa con il sistema operativo desktop Windows e deve essere ottenuta separatamente dal sito Web NuGet.

3. Ripristinare e ricompilare il progetto.

4. Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.

Risorse aggiuntive

• Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core
• Risoluzione di errori comuni di Servizio app di Azure e IIS con ASP.NET Core
• Gestire gli errori in ASP.NET Core
• Modulo ASP.NET Core (ANCM) per IIS

Documentazione Azure

• Application Insights per ASP.NET Core
• Sezione Debug remoto delle app Web di Risolvere i problemi relativi a un'app Web nel servizio app Azure con Visual Studio
• Panoramica della diagnostica del servizio app di Azure
• Procedura: Eseguire il monitoraggio delle app nel servizio app di Azure
• Risoluzione dei problemi di un'app Web nel servizio app di Azure tramite Visual Studio
• Risolvere gli errori HTTP "502 - Gateway non valido" e "503 - Servizio non disponibile" nelle App Web di Azure
• Risoluzione dei problemi di rallentamento delle prestazioni delle app Web nel Servizio app di Azure
• Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure
• Azure Web App sandbox (App Service runtime execution limitations) (Sandbox per app Web di Azure - Limitazioni di esecuzione di runtime di Servizio app di Azure)

Documentazione di Visual Studio

• Debug remoto ASP.NET Core in IIS in Azure in Visual Studio 2017
• Debug remoto ASP.NET Core in un computer IIS remoto in Visual Studio 2017
• Informazioni sul debug tramite Visual Studio

Documentazione di Visual Studio Code

• Debugging with Visual Studio Code (Debug con Visual Studio Code)

Questo articolo fornisce informazioni sugli errori di avvio delle app comuni e istruzioni su come diagnosticare gli errori quando un'app viene distribuita nel servizio app Azure o IIS:

Errori di avvio dell'app
Illustra gli scenari comuni del codice di stato HTTP di avvio.

Risolvere i problemi relativi al servizio app Azure
Fornisce consigli per la risoluzione dei problemi per le app distribuite nel servizio app Azure.

Risolvere i problemi in IIS
Fornisce consigli per la risoluzione dei problemi per le app distribuite in IIS o in esecuzione in IIS Express in locale. Le linee guida si applicano sia alle distribuzioni di Windows Server che a windows desktop.

Cancellare le cache dei pacchetti
Spiega cosa fare quando i pacchetti incoerenti interrompono un'app durante l'esecuzione di aggiornamenti principali o la modifica delle versioni dei pacchetti.

Risorse aggiuntive
Elenca altri argomenti relativi alla risoluzione dei problemi.

Errori di avvio dell'app

In Visual Studio il server predefinito del progetto ASP.NET Core è Kestrel. Visual Studio può essere configurato per l'uso di IIS Express. 502.5 - Errore di processo o 500.30 - Errore di avvio che si verifica quando si esegue il debug in locale con IIS Express può essere diagnosticato usando i consigli in questo argomento.

403.14 Accesso negato

L'app non viene avviata. Viene registrato l'errore seguente:

The Web server is configured to not list the contents of this directory.

L'errore è in genere causato da una distribuzione interrotta nel sistema di hosting, che include uno degli scenari seguenti:

• L'app viene distribuita nella cartella errata nel sistema di hosting.
• Il processo di distribuzione non è riuscito a spostare tutti i file e le cartelle dell'app nella cartella di distribuzione nel sistema di hosting.
• Il file web.config non è presente nella distribuzione oppure il contenuto del file web.config non è valido.

Procedi come segue:

1. Eliminare tutti i file e le cartelle dalla cartella di distribuzione nel sistema di hosting.
2. Ridistribuire il contenuto della cartella di pubblicazione dell'app nel sistema di hosting usando il metodo normale di distribuzione, ad esempio Visual Studio, PowerShell o distribuzione manuale:
   • Verificare che il file web.config sia presente nella distribuzione e che il relativo contenuto sia corretto.
   • Quando si ospita nel servizio app Azure, verificare che l'app venga distribuita nella D:\home\site\wwwroot cartella .
   • Quando l'app è ospitata da IIS, verificare che l'app venga distribuita nel percorso fisico IIS visualizzato nelle impostazioni di base di Gestione IIS.
3. Verificare che tutti i file e le cartelle dell'app vengano distribuiti confrontando la distribuzione nel sistema di hosting con il contenuto della cartella di pubblicazione del progetto.

Per altre informazioni sul layout di un'app ASP.NET Core pubblicata, vedere ASP.NET struttura di directory Core. Per altre informazioni sul file web.config , vedere ASP.NET Core Module (ANCM) per IIS.

500 Errore interno del server

L'app viene avviata, ma un errore impedisce al server di soddisfare la richiesta.

Questo errore si verifica all'interno del codice dell'app durante l'avvio o durante la creazione di una risposta. La risposta potrebbe non avere alcun contenuto o essere visualizzata nel browser come un codice 500 Errore interno del server. Il log eventi dell'applicazione in genere indica che l'app è stata avviata normalmente. Dal punto di vista del server, questo è corretto. L'app è stata effettivamente avviata, ma non può generare una risposta valida. Per risolvere il problema, eseguire l'app dal prompt dei comandi nel server o abilitare il log stdout del modulo ASP.NET Core.

Questo errore può verificarsi anche quando il bundle di hosting .NET Core non è installato o è danneggiato. L'installazione o il ripristino dell'installazione del bundle di hosting .NET Core (per IIS) o di Visual Studio (per IIS Express) possono risolvere il problema.

500.0 Errore di caricamento del gestore in-process

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Si è verificato un errore sconosciuto durante il caricamento ASP.NET componenti core module . Effettua una delle seguenti azioni:

• Contattare il supporto tecnico Microsoft. Selezionare Strumenti di sviluppo e quindi ASP.NET Core.
• Porre una domanda in Stack Overflow.
• Segnalare il problema nel repository GitHub di ASP.NET Core.

500.30 Errore di avvio in-process

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare .NET Core CLR in-process, ma non viene avviato. In genere è possibile determinare la causa di un errore di avvio del processo dalle voci nel log eventi dell'applicazione e nel log stdout del modulo ASP.NET Core.

Condizioni di errore comuni:

• L'app non è configurata correttamente a causa della destinazione di una versione del framework condiviso di ASP.NET Core non presente. Controllare le versioni del framework condiviso ASP.NET Core installate nel computer di destinazione.
• Uso di Azure Key Vault, mancanza di autorizzazioni per l'insieme di credenziali delle chiavi. Controllare i criteri di accesso nell'insieme di credenziali delle chiavi di destinazione per assicurarsi che vengano concesse le autorizzazioni corrette.

500.31 ANCM Failed to Find Native Dependencies (500.31 Il modulo ASP.NET Core non è riuscito a trovare le dipendenze native)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare il runtime di .NET Core in-process, ma non viene avviato. La causa più comune di questo errore di avvio è la mancata installazione del runtime di Microsoft.NETCore.App o di Microsoft.AspNetCore.App. Se l'app viene distribuita per ASP.NET Core 3.0 e tale versione non esiste nel computer, si verifica questo errore. Ecco un esempio di messaggio di errore:

The specified framework 'Microsoft.NETCore.App', version '3.0.0' was not found.
  - The following frameworks were found:
      2.2.1 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview5-27626-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27713-13 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27714-15 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]
      3.0.0-preview6-27723-08 at [C:\Program Files\dotnet\x64\shared\Microsoft.NETCore.App]

Il messaggio di errore elenca tutte le versioni di .NET Core installate e la versione richiesta dall'app. Per correggere l'errore, eseguire una delle operazioni seguenti:

• Installare la versione appropriata di .NET Core nel computer.
• Modificare l'app in modo che usi una versione di .NET Core presente nel computer.
• Pubblicare l'app come distribuzione autonoma.

Durante l'esecuzione in fase di sviluppo (con la variabile di ambiente ASPNETCORE_ENVIRONMENT impostata su Development), l'errore specifico viene scritto nella risposta HTTP. La causa di un errore di avvio del processo è disponibile anche nel log eventi dell'applicazione.

500.32 ANCM Failed to Load dll (500.32 Il modulo ASP.NET Core non è riuscito a caricare la DLL)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

La causa più comune di questo errore è la pubblicazione dell'app per processori con architettura non compatibile. Se il processo di lavoro è in esecuzione come app a 32 bit e l'app è stata pubblicata per un'architettura a 64 bit, si verifica questo errore.

Per correggere l'errore, eseguire una delle operazioni seguenti:

• Ripubblicare l'app per processori con la stessa architettura del processo di lavoro.
• Pubblicare l'app come distribuzione dipendente dal framework.

500.33 ANCM Request Handler Load Failure (500.33 Errore di caricamento del gestore della richiesta del modulo ASP.Net Core)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

L'app non fa riferimento al framework Microsoft.AspNetCore.App. Solo le app destinate al Microsoft.AspNetCore.App framework possono essere ospitate dal modulo principale ASP.NET.

Per correggere questo errore, verificare che l'app sia destinata al framework Microsoft.AspNetCore.App. Controllare il framework di destinazione dell'app nel file .runtimeconfig.json.

500.34 ANCM Mixed Hosting Models Not Supported (500.34 Modelli di hosting misto non supportati nel modulo ASP.NET Core)

Il processo di lavoro non è in grado di eseguire un'app In-Process e un'app Out-of-process nello stesso processo.

Per correggere questo errore, eseguire le app in pool di applicazioni IIS separati.

500.35 ANCM Multiple In-Process Applications in same Process (500.35 Modulo ASP.NET Core: più applicazioni In-Process nello stesso processo)

Il processo di lavoro non può eseguire più app in-process nello stesso processo.

Per correggere questo errore, eseguire le app in pool di applicazioni IIS separati.

500.36 ANCM Out-Of-Process Handler Load Failure (500.36 Modulo ASP.NET Core: Errore di caricamento del gestore Out-of-process)

Il gestore delle richieste Out-of-process, aspnetcorev2_outofprocess.dll, non è accanto al file aspnetcorev2.dll. Indica un'installazione danneggiata del modulo core ASP.NET.

Per correggere questo errore, riparare l'installazione del bundle di hosting di .NET Core (per IIS) o di Visual Studio (per IIS Express).

500.37 ANCM Failed to Start Within Startup Time Limit (500.37 Avvio del modulo ASP.NET Core non riuscito entro il limite di tempo stabilito)

Non è stato possibile avviare ANCM entro il limite di tempo di avvio specificato. Per impostazione predefinita, il timeout è di 120 secondi.

Questo errore può verificarsi quando si avvia un numero elevato di app nello stesso computer. Controllare i picchi di utilizzo della CPU e della memoria nel server durante l'avvio. Può essere necessario scaglionare il processo di avvio di più app.

500.38 DLL dell'applicazione ANCM non trovata

ANCM non è riuscito a individuare la DLL dell'applicazione, che dovrebbe essere accanto al file eseguibile.

Questo errore si verifica quando si ospita un'app in pacchetto come eseguibile a file singolo usando il modello di hosting in-process. Il modello in-process richiede che ANCM carichi l'app .NET Core nel processo IIS esistente. Questo scenario non è supportato dal modello di distribuzione a file singolo. Usare uno degli approcci seguenti nel file di progetto dell'app per correggere questo errore:

1. Disabilitare la pubblicazione a file singolo impostando la PublishSingleFile proprietà MSBuild su false.
2. Passare al modello di hosting out-of-process impostando la AspNetCoreHostingModel proprietà MSBuild su OutOfProcess.

502.5 Process Failure (Errore del processo)

Il processo di lavoro ha esito negativo. L'app non viene avviata.

Il modulo ASP.NET Core tenta di avviare il processo di lavoro, ma l'avvio non riesce. In genere è possibile determinare la causa di un errore di avvio del processo dalle voci nel log eventi dell'applicazione e nel log stdout del modulo ASP.NET Core.

Una condizione di errore comune è dovuta alla configurazione non corretta dell'app perché come destinazione viene specificata una versione del framework condiviso ASP.NET Core, che non è presente. Controllare le versioni del framework condiviso ASP.NET Core installate nel computer di destinazione. Il framework condiviso è il set di assembly (file DLL) che vengono installati nel computer e cui fa riferimento un metapacchetto, ad esempio Microsoft.AspNetCore.App. Il riferimento del metapacchetto può specificare una versione minima richiesta. Per altre informazioni, vedere The shared framework (Il framework condiviso).

La pagina di errore 502.5 Errore del processo viene restituita quando il processo di lavoro ha esito negativo a causa di un errore di configurazione dell'hosting o dell'app:

Non è stato possibile avviare l'aggiornamento dell'applicazione. Errore: 0x800700c1

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/6/ROOT/', ErrorCode '0x800700c1'.

L'app non è stata avviata perché non è stato possibile caricarne l'assembly (.dll).

Questo errore si verifica quando è presente una mancata corrispondenza del numero di bit tra l'app pubblicata e il processo w3wp/iisexpress.

Verificare che l'impostazione del pool di app a 32 bit sia corretta:

1. Selezionare il pool di app in Pool di applicazioni di Gestione IIS.
2. Selezionare Impostazioni avanzate in Modifica pool di applicazioni nel pannello Azioni.
3. Impostare Abilita applicazioni a 32 bit:
   • Se si sta sviluppando un'app a 32 bit (x86), impostare il valore su True.
   • Se si sta sviluppando un'app a 64 bit (x64), impostare il valore su False.

Verificare che non vi sia un conflitto tra una <Platform> proprietà MSBuild nel file di progetto e il livello di bit pubblicato dell'app.

Impossibile avviare l'applicazione (ErrorCode '0x800701b1')

EventID: 1010
Source: IIS AspNetCore Module V2
Failed to start application '/LM/W3SVC/3/ROOT', ErrorCode '0x800701b1'.

Impossibile avviare l'app perché non è stato possibile caricare un servizio Windows.

Un servizio comune che deve essere abilitato è il servizio "null". Il comando seguente abilita il null servizio Windows:

sc.exe start null

Reimpostazione della connessione

Se si verifica un errore dopo l'invio delle intestazioni, è troppo tardi perché il server possa inviare un codice 500 Errore interno del server quando si verifica un errore. Questo spesso accade quando si verifica un errore durante la serializzazione di oggetti complessi per una risposta. Questo tipo di errore viene visualizzato come un errore di reimpostazione della connessione nel client. La registrazione delle applicazioni può consentire di risolvere questi tipi di errori.

Limiti di avvio predefiniti

Il modulo core ASP.NET è configurato con un valore predefinito startupTimeLimit di 120 secondi. Quando si mantiene il valore predefinito, l'avvio di un'app potrebbe richiedere fino a due minuti prima che il modulo registri un errore del processo. Per informazioni sulla configurazione del modulo, vedere Attributi dell'elemento aspNetCore.

Risolvere i problemi relativi al servizio app Azure

Flusso di log di app Azure Services

Le informazioni di registrazione dei flussi di log di app Azure Services non appena si verificano. Per visualizzare i log di streaming:

1. Nel portale di Azure aprire l'app in Servizi app.
2. Nel riquadro sinistro passare a Monitoraggio> servizio app Log.
3. Selezionare File System per Registrazione server Web. Facoltativamente, abilitare Registrazione applicazioni.
4. Nel riquadro sinistro passare a Monitoraggio>del flusso di log e quindi selezionare Log applicazioni o Log del server Web.

Le immagini seguenti illustrano l'output dei log dell'applicazione:

I log di streaming hanno una certa latenza e potrebbero non essere visualizzati immediatamente.

Registro eventi dell'applicazione (servizio app Azure)

Per accedere al log eventi dell'applicazione, usare il pannello Diagnostica e risolvi i problemi nel portale di Azure:

1. Nel portale di Azure aprire l'app in Servizi app.
2. Selezionare Diagnostica e risoluzione dei problemi.
3. Selezionare l'intestazione Strumenti di diagnostica.
4. In Strumenti di supporto selezionare il pulsante Eventi dell'applicazione.
5. Esaminare l'errore più recente dalla voce IIS AspNetCoreModule o IIS AspNetCoreModule V2 nella colonna Origine.

Un'alternativa all'uso del pannello Diagnostica e risolvi i problemi consiste nell'esaminare direttamente il file del log eventi dell'applicazione usando Kudu:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire la cartella LogFiles .
4. Selezionare l'icona a forma di matita accanto al eventlog.xml file.
5. Esaminare il log. Scorrere fino alla fine del log per visualizzare gli eventi più recenti.

Eseguire l'app nella console Kudu

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile eseguire l'app nella console di esecuzione remota Kudu per individuare l'errore:

1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.

Test di un'app a 32 bit (x86)

Versione corrente

1. cd d:\home\site\wwwroot
2. Eseguire l'app:

   • Se l'app è una distribuzione dipendente dal framework:

     dotnet .\{ASSEMBLY NAME}.dll
     

   • Se l'app è una distribuzione autonoma:

     {ASSEMBLY NAME}.exe
     

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x86).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x32 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Test di un'app a 64 bit (x64)

Versione corrente

• Se l'app è una distribuzione dipendente dal framework a 64 bit (x64):
  1. cd D:\Program Files\dotnet
  2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll
• Se l'app è una distribuzione autonoma:
  1. cd D:\home\site\wwwroot
  2. Eseguire l'app: {ASSEMBLY NAME}.exe

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

Distribuzione dipendente dal framework in esecuzione in una versione di anteprima

Richiede l'installazione dell'estensione del sito del runtime ASP.NET Core {VERSION} (x64).

1. cd D:\home\SiteExtensions\AspNetCoreRuntime.{X.Y}.x64 ({X.Y} è la versione di runtime)
2. Eseguire l'app: dotnet \home\site\wwwroot\{ASSEMBLY NAME}.dll

L'output della console dall'app, che visualizza gli eventuali errori, viene inviato tramite pipe alla console Kudu.

log stdout del modulo core ASP.NET (servizio app Azure)

Il log stdout del modulo ASP.NET Core spesso registra utili messaggi di errore non disponibili nel log eventi dell'applicazione. Per abilitare e visualizzare i log stdout:

1. Nel portale di Azure passare all'app Web.
2. Nel pannello servizio app immettere kudu nella casella di ricerca.
3. Selezionare Strumenti>avanzati Vai.
4. Selezionare CmD della console > di debug.
5. Passare a sito/wwwroot
6. Selezionare l'icona a forma di matita per modificare il file web.config .
7. Nell'elemento <aspNetCore /> impostare stdoutLogEnabled="true" e selezionare Salva.

Disabilitare la registrazione stdout al termine della risoluzione dei problemi impostando stdoutLogEnabled="false".

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

log di debug del modulo core ASP.NET (servizio app Azure)

Il log di debug del modulo ASP.NET Core fornisce dati di registrazione aggiuntivi e più approfonditi dal modulo ASP.NET Core. Per abilitare e visualizzare i log stdout:

1. Per abilitare il log di diagnostica avanzato, eseguire una delle operazioni seguenti:
   • Seguire le istruzioni in Log di diagnostica avanzati per configurare l'app per la registrazione di diagnostica avanzata. Ridistribuire l'app.
   • Aggiungere il <handlerSettings> visualizzato nei log di diagnostica avanzati al file web.config dell'app live usando la console Kudu:
     1. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
     2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
     3. Aprire le cartelle nel percorso site>wwwroot. Modificare il file web.config selezionando il pulsante a forma di matita. Aggiungere la sezione <handlerSettings> come illustrato in Log di diagnostica avanzati. Selezionare il pulsante Salva.
2. Aprire Strumenti avanzati nell'area Strumenti di sviluppo. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
3. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
4. Aprire le cartelle nel percorso site>wwwroot. Se non è stato specificato un percorso per il file aspnetcore-debug.log, il file viene visualizzato nell'elenco. Se è stato specificato un percorso, passare al percorso del file di log.
5. Aprire il file di log con il pulsante a forma di matita accanto al nome del file.

Al termine della risoluzione dei problemi, disabilitare la registrazione di debug:

Per disabilitare il log di debug avanzato, eseguire le operazioni seguenti:

• Rimuovere <handlerSettings> dal file web.config in locale e ridistribuire l'app.
• Usare la console Kudu per modificare il file web.config e rimuovere la sezione <handlerSettings>. Salvare il file.

Per altre informazioni, vedere Creazione e reindirizzamento dei log con il modulo ASP.NET Core.

App lenta o non risponde (servizio app Azure)

Quando un'app risponde lentamente o non risponde a una richiesta, vedere Risolvere i problemi di prestazioni lente dell'app Web in app Azure Servizio.

Pannelli di monitoraggio

I pannelli di monitoraggio forniscono un'esperienza di risoluzione dei problemi alternativa ai metodi descritti in precedenza in questo argomento. È possibile usare questi pannelli per diagnosticare gli errori della serie 500.

Verificare che le estensioni di ASP.NET Core siano installate. Se le estensioni non sono installate, installarle manualmente:

1. Nella sezione del pannello STRUMENTI DI SVILUPPO selezionare il pannello Estensioni.
2. Nell'elenco dovrebbe essere visualizzato ASP.NET Core Extensions (Estensioni ASP.NET Core).
3. Se le estensioni non sono installate, selezionare il pulsante Aggiungi.
4. Scegliere ASP.NET Core Extensions (Estensioni ASP.NET Core) dall'elenco.
5. Selezionare OK per accettare le condizioni legali.
6. Selezionare OK nel pannello Aggiungi estensione.
7. Un messaggio popup informativo indica quando le estensioni sono state installate correttamente.

Se la registrazione stdout non è abilitata, attenersi ai passaggi riportati di seguito:

1. Nel portale di Azure selezionare il pannello Strumenti avanzati nell'area STRUMENTI DI SVILUPPO. Selezionare il pulsante Vai→ . Verrà aperta la console Kudu in una nuova scheda o finestra del browser.
2. Usando la barra di spostamento nella parte superiore della pagina, aprire Console di debug e selezionare CMD.
3. Aprire le cartelle nel percorso site>wwwroot e scorrere verso il basso fino a visualizzare il file web.config in fondo all'elenco.
4. Fare clic sull'icona della matita accanto al file web.config.
5. Impostare stdoutLogEnabled su true e cambiare il percorso di stdoutLogFile in: \\?\%home%\LogFiles\stdout.
6. Selezionare Salva per salvare il file web.config aggiornato.

Passare all'attivazione della registrazione diagnostica:

1. Nel portale di Azure selezionare il pannello Log di diagnostica.
2. Selezionare l'interruttore Attivato per Registrazione applicazioni (file system) e Messaggi di errore dettagliati. Selezionare il pulsante Salva nella parte superiore del pannello.
3. Per includere la traccia delle richieste non riuscite, anche nota come registrazione FREB (Failed Request Event Buffering), selezionare l'interruttore Attivato per Traccia delle richieste non riuscite.
4. Selezionare il pannello Flusso di registrazione, immediatamente sotto il pannello Log di diagnostica nel portale.
5. Effettuare una richiesta all'app.
6. Nei dati del flusso di registrazione viene indicata la causa dell'errore.

Al termine della risoluzione dei problemi, assicurarsi di disabilitare la registrazione stdout.

Per visualizzare i log di traccia delle richieste non riuscite (log FREB):

1. Passare al pannello Diagnostica e risolvi i problemi nel portale di Azure.
2. Selezionare Failed Request Tracing Logs (Log di traccia delle richieste non riuscite) nell'area STRUMENTI DI SUPPORTO della barra laterale.

Per altre informazioni, vedere la sezione relativa alla traccia delle richieste non riuscite nell'argomento Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure e Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure: Come si abilita la traccia delle richieste non riuscite?.

Per altre informazioni, vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure.

Risolvere i problemi in IIS

Registro eventi applicazioni (IIS)

Accedere al log eventi dell'applicazione:

1. Aprire il menu Start, cercare Visualizzatore eventi e selezionare l'app Visualizzatore eventi.
2. In Visualizzatore eventi aprire il nodo Registri di Windows.
3. Selezionare Applicazione per aprire il log eventi dell'applicazione.
4. Cercare gli errori associati all'app in cui si è verificato il problema. Gli errori presentano un valore Modulo AspNetCore IIS o Modulo AspNetCore IIS Express nella colonna Origine.

Eseguire l'app da un prompt dei comandi

Molti errori di avvio non producono informazioni utili nel log eventi dell'applicazione. È possibile individuare la causa di alcuni errori eseguendo l'app da un prompt dei comandi nel sistema host.

Distribuzione dipendente dal framework

Se l'app è una distribuzione dipendente dal framework:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare l'app eseguendo l'assembly dell'app con dotnet.exe. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: dotnet .\<assembly_name>.dll.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

Distribuzione autonoma

Se l'app è una distribuzione autonoma:

1. Da un prompt dei comandi passare alla cartella di distribuzione e avviare il file eseguibile dell'app. Nel comando seguente sostituire il nome dell'assembly dell'app per <assembly_name>: <assembly_name>.exe.
2. L'output della console per l'app, in cui sono indicati gli eventuali errori, verrà scritto nella finestra della console.
3. Se si verificano errori durante l'esecuzione di una richiesta all'app, effettuare una richiesta all'host e alla porta in cui Kestrel è in ascolto. Usando l'host e la porta predefiniti, effettuare una richiesta a http://localhost:5000/. Se l'app risponde normalmente all'indirizzo dell'endpoint Kestrel , il problema è probabilmente correlato alla configurazione dell'hosting e meno probabile all'interno dell'app.

log stdout del modulo principale ASP.NET (IIS)

Per abilitare e visualizzare i log stdout:

1. Passare alla cartella di distribuzione del sito nel sistema host.
2. Se la cartella logs non è presente, creare la cartella. Per istruzioni su come impostare MSBuild per la creazione automatica della cartella logs nella distribuzione, vedere l'argomento Struttura della directory.
3. Modificare il file web.config. Impostare stdoutLogEnabled su true e modificare il percorso di stdoutLogFile in modo da fare riferimento alla cartella logs, ad esempio .\logs\stdout. stdout nel percorso è il prefisso del nome del file di log. Un timestamp, l'ID del processo e l'estensione del file vengono aggiunti automaticamente al momento della creazione del log. Usando stdout come prefisso del nome del file, un tipico file di log è denominato stdout_20180205184032_5412.log.
4. Verificare che il pool di applicazioni disponga delle autorizzazioni di identity scrittura per la cartella logs .
5. Salvare il file web.config aggiornato.
6. Effettuare una richiesta all'app.
7. Passare alla cartella logs. Trovare e aprire il log stdout più recente.
8. Esaminare il log per verificare se sono presenti errori.

Al termine della risoluzione dei problemi, disabilitare la registrazione stdout:

1. Modificare il file web.config.
2. Impostare stdoutLogEnabled su false.
3. Salvare il file.

Per altre informazioni, vedere Modulo ASP.NET Core (ANCM) per IIS.

log di debug del modulo core di ASP.NET (IIS)

Aggiungere le impostazioni del gestore seguenti al file web.config dell'app per abilitare ASP.NET log di debug del modulo core:

<aspNetCore ...>
  <handlerSettings>
    <handlerSetting name="debugLevel" value="file" />
    <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
  </handlerSettings>
</aspNetCore>

Verificare che il percorso specificato per il log esista e che il pool di app disponga delle autorizzazioni di identity scrittura per il percorso.

Per altre informazioni, vedere Creazione e reindirizzamento dei log con il modulo ASP.NET Core.

Abilitare la pagina delle eccezioni per gli sviluppatori

La ASPNETCORE_ENVIRONMENT variabile di ambiente può essere aggiunta a web.config per eseguire l'app nell'ambiente di sviluppo. Purché l'ambiente non sia sottoposto a override durante l'avvio dell'app tramite UseEnvironment nel generatore di host, l'impostazione della variabile di ambiente consente di visualizzare la pagina delle eccezioni per gli sviluppatori quando viene eseguita l'app.

<aspNetCore processPath="dotnet"
      arguments=".\MyApp.dll"
      stdoutLogEnabled="false"
      stdoutLogFile=".\logs\stdout"
      hostingModel="InProcess">
  <environmentVariables>
    <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

L'impostazione della variabile di ambiente per ASPNETCORE_ENVIRONMENT è consigliata solo per l'uso in server di gestione temporanea e test non esposti a Internet. Al termine della risoluzione dei problemi, rimuovere la variabile di ambiente dal file web.config. Per informazioni sull'impostazione delle variabili di ambiente in web.config, vedere elemento figlio environmentVariables di aspNetCore.

Ottenere dati da un'app

Se un'app è in grado di rispondere alle richieste, è possibile ottenere dati sulle richieste, le connessioni e altri dati dall'app tramite middleware inline di terminale. Per altre informazioni e codice di esempio, vedere Risolvere i problemi ed eseguire il debug di progetti di base ASP.NET.

App lenta o non risponde (IIS)

Un dump di arresto anomalo del sistema è uno snapshot della memoria del sistema e può aiutare a determinare la causa di un arresto anomalo dell'app, un errore di avvio o un'app lenta.

Arresto anomalo o eccezione di un'app

Ottenere e analizzare un dump da Segnalazione errori Windows:

1. Creare una cartella per i file dump di arresto anomalo del sistema in c:\dumps. Il pool di app deve avere accesso in scrittura alla cartella.

2. Eseguire lo script di PowerShell EnableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\EnableDumps w3wp.exe c:\dumps
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\EnableDumps dotnet.exe c:\dumps
     

3. Eseguire l'app nelle condizioni che causano l'arresto anomalo.

4. Dopo che si è verificato l'arresto anomalo, eseguire lo script di PowerShell DisableDumps:

   • Se l'app usa il modello di hosting in-process, eseguire lo script per w3wp.exe:

     .\DisableDumps w3wp.exe
     

   • Se l'app usa il modello di hosting out-of-process, eseguire lo script per dotnet.exe:

     .\DisableDumps dotnet.exe
     

Dopo l'arresto anomalo di un'app e la raccolta dei dump, l'app può terminare normalmente. Lo script di PowerShell configura Segnalazione errori Windows per raccogliere fino a cinque dump per ogni app.

L'app non risponde, non riesce durante l'avvio o viene eseguita normalmente

Quando un'app smette di rispondere ma non si arresta in modo anomalo, non riesce durante l'avvio o viene eseguita normalmente, vedi File di dump in modalità utente: scelta dello strumento migliore per selezionare uno strumento appropriato per produrre il dump.

Analizzare il dump

È possibile analizzare un dump usando diversi approcci. Per altre informazioni, vedere Analyzing a User-Mode Dump File (Analisi di un file dump in modalità utente).

Cancellare le cache dei pacchetti

Un'app funzionante potrebbe non riuscire immediatamente dopo l'aggiornamento di .NET Core SDK nel computer di sviluppo o la modifica delle versioni dei pacchetti all'interno dell'app. In alcuni casi i pacchetti incoerenti possono interrompere un'app quando si eseguono aggiornamenti principali. La maggior parte di questi problemi può essere risolta attenendosi alle istruzioni seguenti:

1. Eliminare le cartelle bin e obj.

2. Cancellare le cache dei pacchetti eseguendo dotnet nuget locals all --clear da una shell dei comandi.

   La cancellazione delle cache dei pacchetti può essere eseguita anche con lo strumento nuget.exe ed eseguendo il comando nuget locals all -clear. nuget.exe non è un'installazione inclusa con il sistema operativo desktop Windows e deve essere ottenuta separatamente dal sito Web NuGet.

3. Ripristinare e ricompilare il progetto.

4. Eliminare tutti i file nella cartella di distribuzione nel server prima di ridistribuire l'app.

Risorse aggiuntive

• Eseguire il debug di .NET e ASP.NET codice sorgente Core con Visual Studio
• Risolvere i problemi ed eseguire il debug di progetti ASP.NET Core
• Risoluzione di errori comuni di Servizio app di Azure e IIS con ASP.NET Core
• Gestire gli errori in ASP.NET Core
• Modulo ASP.NET Core (ANCM) per IIS

Documentazione Azure

• Application Insights per ASP.NET Core
• Sezione Debug remoto delle app Web di Risolvere i problemi relativi a un'app Web nel servizio app Azure con Visual Studio
• Panoramica della diagnostica del servizio app di Azure
• Procedura: Eseguire il monitoraggio delle app nel servizio app di Azure
• Risoluzione dei problemi di un'app Web nel servizio app di Azure tramite Visual Studio
• Risolvere gli errori HTTP "502 - Gateway non valido" e "503 - Servizio non disponibile" nelle App Web di Azure
• Risoluzione dei problemi di rallentamento delle prestazioni delle app Web nel Servizio app di Azure
• Domande frequenti sulle prestazioni delle applicazioni in App Web di Azure
• Azure Web App sandbox (App Service runtime execution limitations) (Sandbox per app Web di Azure - Limitazioni di esecuzione di runtime di Servizio app di Azure)

Documentazione di Visual Studio

• Debug remoto ASP.NET Core in IIS in Azure in Visual Studio 2017
• Debug remoto ASP.NET Core in un computer IIS remoto in Visual Studio 2017
• Informazioni sul debug tramite Visual Studio

Documentazione di Visual Studio Code

• Debugging with Visual Studio Code (Debug con Visual Studio Code)