Risoluzione dei problemi e problemi noti per il debug di snapshot in Visual Studio

Si applica a: Visual Studio

Questo articolo offre soluzioni a problemi comuni che possono verificarsi durante il debug di un'app di Azure con Snapshot Debugger in Visual Studio.

Se i passaggi descritti in questo articolo non risolvono il problema, cercare il problema nella community degli sviluppatori o segnalare un nuovo problema scegliendo Guida>per inviare>commenti e suggerimenti segnalando un problema in Visual Studio.

Problema: "Attach Snapshot Debugger" rileva un errore di codice di stato HTTP

Se viene visualizzato l'errore seguente nella finestra Output durante il tentativo di connessione, potrebbe trattarsi di un problema noto elencato nelle sezioni seguenti. Provare le soluzioni proposte e, se il problema persiste, contattare l'alias precedente.

[TIMESTAMP] Error --- Unable to Start Snapshot Debugger - Attach Snapshot Debugger failed: System.Net.WebException: The remote server returned an error: (###) XXXXXX

(401) Non autorizzato

Questo errore indica che la chiamata REST rilasciata da Visual Studio ad Azure usa credenziali non valide.

Prova ad eseguire questi passaggi:

• Assicurarsi che l'account di personalizzazione di Visual Studio disponga delle autorizzazioni per la sottoscrizione e la risorsa di Azure a cui si sta eseguendo il collegamento. Un modo rapido per determinare questo è controllare se la risorsa è disponibile nella finestra di dialogo da Debug>Attach Snapshot Debugger...>Risorsa di>Azure Selezionare esistente o in Cloud Explorer.
• Se l'errore persiste, usare uno dei canali di feedback descritti all'inizio di questo articolo.

Se è stata abilitata l'autenticazione/autorizzazione (EasyAuth) nel servizio app, è possibile che si verifichi un errore 401 con LaunchAgentAsync nel messaggio di errore dello stack di chiamate. Assicurarsi che l'azione da eseguire quando la richiesta non è autenticata è impostata su Consenti richieste anonime (nessuna azione) nella portale di Azure e fornire un authorization.json in D:\Home\sites\wwwroot con il contenuto seguente.

{
  "routes": [
    {
      "path_prefix": "/",
      "policies": {
        "unauthenticated_action": "RedirectToLoginPage"
      }
    },
    {
      "http_methods": [ "POST" ],
      "path_prefix": "/41C07CED-2E08-4609-9D9F-882468261608/api/agent",
      "policies": {
        "unauthenticated_action": "AllowAnonymous"
      }
    }
  ]
}

La prima route protegge efficacemente il dominio dell'app in modo analogo all'accesso con [IdentityProvider]. La seconda route espone l'endpoint AgentLaunch SnapshotDebugger all'esterno dell'autenticazione, che esegue l'azione predefinita di avvio dell'agente di diagnostica SnapshotDebugger solo se l'estensione del sito preinstallata SnapshotDebugger è abilitata per il servizio app. Per altre informazioni sulla configurazione authorization.json , vedere Regole di autorizzazione URL.

(403) Accesso negato

L'errore 403 - Accesso negato indica che l'autorizzazione è negata. Molti scenari diversi possono causare questo errore.

Prova ad eseguire questi passaggi:

• Verificare che l'account di Visual Studio disponga di una sottoscrizione di Azure valida con le autorizzazioni di Controllo di accesso (RBAC) necessarie per la risorsa. Per AppService, controllare se si dispone delle autorizzazioni per eseguire query sul piano di servizio app che ospita l'app.
• Verificare che il timestamp del computer client sia corretto e aggiornato. I server con timestamp disattivati per più di 15 minuti del timestamp della richiesta generano in genere questo errore.
• Se l'errore persiste, usare uno dei canali di feedback descritti all'inizio di questo articolo.

(404) Non trovato

L'errore 404 - Non trovato indica che il sito Web non è stato trovato nel server.

Prova ad eseguire questi passaggi:

• Verificare di avere distribuito e in esecuzione un sito Web nella risorsa servizio app a cui si sta eseguendo il collegamento.
• Verificare che il sito sia disponibile in https://< resource.azurewebsites.net>
• Verificare che l'applicazione Web personalizzata in esecuzione correttamente non restituisca un codice di stato 404 quando si accede a https:// resource.azurewebsites.net><.
• Se l'errore persiste, usare uno dei canali di feedback descritti all'inizio di questo articolo.

(406) Non accettabile

L'errore 406 - Non accettabile indica che il server non è in grado di rispondere al tipo impostato nell'intestazione Accept della richiesta.

Prova ad eseguire questi passaggi:

• Verificare che il sito sia disponibile all'indirizzo https:// resource.azurewebsites.net>.<
• Verificare che il sito non sia stato migrato a nuove istanze. Snapshot Debugger usa il concetto di ARRAffinity per il routing delle richieste a istanze specifiche che possono generare questo errore in modo intermittente.
• Se l'errore persiste, usare uno dei canali di feedback descritti all'inizio di questo articolo.

(409) Conflitto

L'errore 409 - Conflitto indica che la richiesta è in conflitto con lo stato del server corrente.

Si tratta di un problema noto che si verifica quando un utente tenta di collegare snapshot debugger a un servizio app che ha abilitato ApplicationInsights. ApplicationInsights imposta AppSettings con una combinazione di maiuscole e minuscole diversa da Visual Studio, causando questo problema.

Questo problema è stato risolto in Visual Studio 2019.

Prova ad eseguire questi passaggi:

• Se l'errore persiste, usare uno dei canali di feedback descritti all'inizio di questo articolo.

(500) Errore interno del server

L'errore 500 - Errore interno del server indica che il sito è inattivo o che il server non è in grado di gestire la richiesta. Snapshot Debugger funziona solo nelle applicazioni in esecuzione. Il debugger snapshot di Application Insights offre snapshot sulle eccezioni e può essere lo strumento migliore per le proprie esigenze.

(502) Gateway non valido

L'errore 502 - Gateway non valido indica un problema di rete lato server e può essere temporaneo.

Prova ad eseguire questi passaggi:

• Provare ad attendere alcuni minuti prima di collegare nuovamente snapshot debugger.
• Se l'errore persiste, usare uno dei canali di feedback descritti all'inizio di questo articolo.

Problema: Snappoint non è attivato

Se viene visualizzata un'icona di avviso con il punto di ancoraggio anziché l'icona normale del punto di ancoraggio, il punto di ancoraggio non è attivato.

Prova ad eseguire questi passaggi:

• Assicurarsi di usare la stessa versione del codice sorgente per compilare e distribuire l'app.
• Assicurarsi di caricare i simboli corretti per la distribuzione.
• A tale scopo, visualizzare la finestra Moduli durante il debug dello snapshot e verificare che la colonna File di simboli mostri un file con estensione pdb caricato per il modulo di cui si sta eseguendo il debug.
  • Snapshot Debugger tenterà automaticamente di scaricare e usare i simboli per la distribuzione.

Problema: i simboli non vengono caricati quando si apre uno snapshot

Se viene visualizzata la finestra seguente, i simboli non sono stati caricati.

Prova ad eseguire questi passaggi:

• Selezionare Cambia impostazioni simbolo... nella pagina.

• Nelle impostazioni Del simbolo di debug > aggiungere una directory della cache dei simboli.

• Riavviare il debug di snapshot dopo aver impostato il percorso dei simboli.

  I simboli o i file con estensione pdb disponibili nel progetto devono corrispondere alla distribuzione servizio app. La maggior parte delle distribuzioni (distribuzione tramite Visual Studio, CI/CD con Azure Pipelines o Kudu e così via) pubblica i file di simboli nel servizio app. L'impostazione della directory di cache dei simboli consente a Visual Studio di usarli.

  

• In alternativa, se l'organizzazione usa un server di simboli o posiziona i simboli in un percorso diverso, usare le impostazioni dei simboli per caricare i simboli corretti per la distribuzione.

Problema: non è possibile visualizzare l'opzione "Attach Snapshot Debugger" in Cloud Explorer

Prova ad eseguire questi passaggi:

• Verificare che il componente Snapshot Debugger sia installato. Aprire il programma di installazione di Visual Studio e selezionare il componente Snapshot Debugger nel carico di lavoro di Azure.

• Per Visual Studio 2019 o versioni successive, verificare che l'app sia supportata:

  • Servizi app di Azure - Applicazioni ASP.NET in esecuzione in .NET Framework 4.6.1 o versioni successive.
  • Servizi app di Azure - Applicazioni ASP.NET Core in esecuzione in .NET Core 2.0 o versioni successive in Windows.
  • Macchine virtuali di Azure (e set di scalabilità di macchine virtuali) - Applicazioni ASP.NET in esecuzione in .NET Framework 4.6.1 o versioni successive.
  • Macchine virtuali di Azure (e set di scalabilità di macchine virtuali) - Applicazioni ASP.NET Core in esecuzione in .NET Core 2.0 o versioni successive in Windows.
  • Servizi Azure Kubernetes - Applicazioni ASP.NET Core in esecuzione in .NET Core 2.2 o versioni successive in Debian 9.
  • Servizi Azure Kubernetes - Applicazioni ASP.NET Core in esecuzione in .NET Core 2.2 o versioni successive in Alpine 3.8.
  • Servizi Azure Kubernetes - Applicazioni ASP.NET Core in esecuzione in .NET Core 2.2 o versioni successive in Ubuntu 18.04.

Problema: negli strumenti di diagnostica sono visibili solo snapshot soggetti a limitazioni

Prova ad eseguire questi passaggi:

• Gli snapshot usano poca memoria, ma prevedono un carico per il commit. Se Snapshot Debugger rileva che il server è in condizioni di carico elevato per la memoria, non verranno acquisiti snapshot. È possibile eliminare gli snapshot già acquisiti interrompendo la sessione di Snapshot Debugger e riprovando.

Problema: il debug dello snapshot con più versioni di Visual Studio restituisce errori (Visual Studio 2019 o versioni successive)

Visual Studio 2019 richiede una versione più recente dell'estensione del sito Snapshot Debugger nel servizio app Azure. Questa versione non è compatibile con la versione precedente dell'estensione del sito Snapshot Debugger usata da Visual Studio 2017. Se si tenta di collegare snapshot debugger in Visual Studio 2019 a un servizio di app Azure precedentemente sottoposto a debug da Snapshot Debugger in Visual Studio 2017, verrà visualizzato l'errore seguente:

Viceversa, se si usa Visual Studio 2017 per collegare snapshot debugger a un servizio app Azure precedentemente sottoposto a debug da Snapshot Debugger in Visual Studio 2019, verrà visualizzato l'errore seguente:

Per risolvere questo problema, eliminare le impostazioni dell'app seguenti nel portale di Azure e collegare nuovamente Snapshot Debugger:

• INSTRUMENTATIONENGINE_EXTENSION_VERSION
• SNAPSHOTDEBUGGER_EXTENSION_VERSION

Problema: Si sta connettendo alla risorsa di Azure o all'account di archiviazione errato o precedente

Prova ad eseguire questi passaggi:

Le voci "Risorsa di Azure" e "Account di archiviazione" usano i nomi delle risorse come chiavi, in modo che azioni come la migrazione di una risorsa a sottoscrizioni diverse possano causare problemi. Per cancellare l'elenco, seguire questa procedura:

1. Eseguire questi comandi nel prompt dei comandi per sviluppatori per Visual Studio (con privilegi di amministratore).

   vsregedit remove local HKCU SnapshotDebugger AzureResourcesMRU
   vsregedit remove local HKCU SnapshotDebugger StorageAccountsMRU
   

2. Eliminare tutti i file con estensione suo associati all'app Web.

Problema: Si verificano problemi durante il debug dello snapshot ed è necessario abilitare più registrazione

Abilitare i log dell'agente

Per abilitare e disabilitare la registrazione dell'agente, aprire Visual Studio e passare a Strumenti>Opzioni>Snapshot Debugger>Abilita registrazione agente. Si noti che se l'opzione Elimina i log dell'agente precedente all'avvio della sessione è abilitata, ogni collegamento di Visual Studio riuscito eliminerà i log dell'agente precedenti.

È possibile trovare i log dell'agente nei percorsi seguenti:

• servizio app:
  • Passare al sito Kudu del servizio app, <ovvero il servizio app.>scm.azurewebsites.net) e passare a Console di debug.
  • I log dell'agente vengono archiviati nella directory seguente: D:\home\LogFiles\SiteExtensions\DiagnosticsAgentLogs\.
• VM/VMSS:
  • Accedere alla macchina virtuale, i log dell'agente vengono archiviati come segue: C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Diagnostics.IaaSDiagnostics<Version>\SnapshotDebuggerAgent*.txt_
• Servizio Azure Kubernetes
  • Passare alla directory seguente: /tmp/diag/AgentLogs/*

Abilitare i log di Profiler/Strumentazione

È possibile trovare i log di strumentazione nelle posizioni seguenti:

• servizio app:
  • La registrazione degli errori viene inviata automaticamente a D:\Home\LogFiles\eventlog.xml, gli eventi vengono contrassegnati con <Provider Name="Instrumentation Engine" /> o "Punti di interruzione di produzione"
• VM/VMSS:
  • Accedere alla macchina virtuale e aprire il Visualizzatore eventi.
  • Aprire la visualizzazione seguente: Applicazione Log> di Windows.
  • Selezionare Filtro registro corrente e in Origine eventi selezionare Production Breakpoints o Instrumentation Engine.
• Servizio Azure Kubernetes
  • Registrazione del motore di strumentazione in /tmp/diag/log.txt (impostato MicrosoftInstrumentationEngine_FileLogPath in DockerFile)
  • Registrazione productionBreakpoint in /tmp/diag/shLog.txt

Problemi noti

• Il debug degli snapshot con più client di Visual Studio sullo stesso servizio app non è attualmente supportato.
• Le ottimizzazioni di Roslyn IL non sono completamente supportate nei progetti ASP.NET Core. Per alcuni progetti ASP.NET Core, potrebbe non essere possibile vedere alcune variabili o usare alcune variabili nelle istruzioni condizionali.
• Le variabili speciali, ad esempio $FUNCTION o $CALLER, non possono essere valutate in istruzioni condizionali o punti di log per i progetti ASP.NET Core.
• Il debug degli snapshot non funziona nelle servizio app con memorizzazione nella cache locale attivata.
• Le app per le API di debug snapshot non sono attualmente supportate.

Aggiornamento dell'estensione del sito

Il debug di snapshot e Application Insights dipendono da un ICorProfiler, che viene caricato nel processo del sito e causa problemi di blocco di file durante l'aggiornamento. È consigliabile eseguire questo processo per assicurarsi che non ci siano tempi di inattività per il sito di produzione.

• Creare uno slot di distribuzione all'interno del servizio app e distribuire il sito nello slot.
• Scambiare questo slot con quello di produzione da Cloud Explorer in Visual Studio o dal portale di Azure.
• Arrestare il sito dello slot. L'interruzione del sito w3wp.exe processo da tutte le istanze richiede alcuni secondi.
• Aggiornare l'estensione del sito slot dal sito Kudu o dal portale di Azure (aggiornamento delle > estensioni >degli strumenti > di sviluppo servizio app pannello).
• Avviare il sito dello slot. È consigliabile visitare il sito per eseguire di nuovo il riscaldamento.
• Scambiare questo slot con quello di produzione.

Riferimenti

• Debug in Visual Studio
• Eseguire il debug di app live ASP.NET usando snapshot debugger
• Eseguire il debug di set di scalabilità live ASP.NET di Azure Macchine virtuali\Macchine virtuali usando snapshot debugger
• Eseguire il debug live ASP.NET Azure Kubernetes usando snapshot debugger
• Domande frequenti sul debug di snapshot