Document Details

The `WebPageTraceListener` lets you view trace output by browsing to `/trace.axd`. 1. Add a <a href="/previous-versions/dotnet/netframework-4.0/6915t83k(v=vs.100)">trace element</a> under `<system.web>` in the Web.config file, such as the following example:

<system.web> <compilation debug="true" targetFramework="4.5" /> <httpRuntime targetFramework="4.5" /> </system.web>

1. Press CTRL+F5 to run the application. 1. In the address bar of the browser window, add *trace.axd* to the URL, and then press Enter (the URL is similar to `http://localhost:53370/trace.axd`). 1. On the **Application Trace** page, click **View Details** on the first line (not the BrowserLink line). :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-traceaxd1.png" alt-text="Screenshot of the Application Trace page in a web browser showing View Details selected on the first line."::: The **Request Details** page appears, and in the **Trace Information** section you see the output from the trace statements that you added to the `Index` method. :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-traceaxd2.png" alt-text="Screenshot of the Request Details page in a web browser showing a message highlighted in the Trace Information section."::: By default, `trace.axd` is only available locally. If you wanted to make it available from a remote app, you could add `localOnly="false"` to the `trace` element in the *Web.config* file, as shown in the following example:

However, enabling `trace.axd` in a production app is not recommended for security reasons. In the following sections, you'll see an easier way to read tracing logs in an App Service app. ### View the tracing output in Azure 1. In **Solution Explorer**, right-click the web project and click **Publish**. 2. In the **Publish Web** dialog box, click **Publish**. After Visual Studio publishes your update, it opens a browser window to your home page (assuming you didn't clear **Destination URL** on the **Connection** tab). 3. In **Server Explorer**, right-click your app and select **View Streaming Logs**. :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-viewlogsmenu.png" alt-text="Screenshot of Server Explorer after right-clicking your app, with View Streaming Logs selected in a new window."::: The **Output** window shows that you are connected to the log-streaming service, and adds a notification line each minute that goes by without a log to display. :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-nologsyet.png" alt-text="Screenshot of the Output window showing an example of a connection to a log-streaming service with notification lines."::: 4. In the browser window that shows your application home page, click **Contact**. Within a few seconds, the output from the error-level trace you added to the `Contact` method appears in the **Output** window.  Visual Studio is only showing error-level traces because that is the default setting when you enable the log monitoring service. When you create a new App Service app, all logging is disabled by default, as you saw when you opened the settings page earlier:  However, when you selected **View Streaming Logs**, Visual Studio automatically changed **Application Logging(File System)** to **Error**, which means error-level logs get reported. In order to see all of your tracing logs, you can change this setting to **Verbose**. When you select a severity level lower than error, all logs for higher severity levels are also reported. So when you select verbose, you also see information, warning, and error logs. 5. In **Server Explorer**, right-click the app, and then click **View Settings** as you did earlier. 6. Change **Application Logging (File System)** to **Verbose**, and then click **Save**.  7. In the browser window that is now showing your **Contact** page, click **Home**, then click **About**, and then click **Contact**. Within a few seconds, the **Output** window shows all of your tracing output.  In this section, you enabled and disabled logging by using app settings. You can also enable and disable trace listeners by modifying the Web.config file. However, modifying the Web.config file causes the app domain to recycle, while enabling logging via the app configuration doesn't do that. If the problem takes a long time to reproduce, or is intermittent, recycling the app domain might "fix" it and force you to wait until it happens again. Enabling diagnostics in Azure lets you start capturing error information immediately without recycling the app domain. ### Output window features The **Microsoft Azure Logs** tab of the **Output** Window has several buttons and a text box: :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-icons.png" alt-text="Screenshot showing the buttons and text box of the Microsoft Azure Logs tab in the Output window."::: These perform the following functions: * Clear the **Output** window. * Enable or disable word wrap. * Start or stop monitoring logs. * Specify which logs to monitor. * Download logs. * Filter logs based on a search string or a regular expression. * Close the **Output** window. If you enter a search string or regular expression, Visual Studio filters logging information at the client. That means you can enter the criteria after the logs are displayed in the **Output** window and you can change filtering criteria without having to regenerate the logs. ## <a name="webserverlogs"></a>View web server logs Web server logs record all HTTP activity for the app. In order to see them in the **Output** window, you must enable them for the app and tell Visual Studio that you want to monitor them. 1. In the **Azure Web App Configuration** tab that you opened from **Server Explorer**, change Web Server Logging to **On**, and then click **Save**.  2. In the **Output** Window, click the **Specify which Microsoft Azure logs to monitor** button.  3. In the **Microsoft Azure Logging Options** dialog box, select **Web server logs**, and then click **OK**.  4. In the browser window that shows the app, click **Home**, then click **About**, and then click **Contact**. The application logs generally appear first, followed by the web server logs. You might have to wait a while for the logs to appear.  By default, when you first enable web server logs by using Visual Studio, Azure writes the logs to the file system. As an alternative, you can use the Azure portal to specify that web server logs should be written to a blob container in a storage account. If you use the portal to enable web server logging to an Azure storage account, and then disable logging in Visual Studio, when you re-enable logging in Visual Studio your storage account settings are restored. ## <a name="detailederrorlogs"></a>View detailed error message logs Detailed error logs provide some additional information about HTTP requests that result in error response codes (400 or above). In order to see them in the **Output** window, you have to enable them for the app and tell Visual Studio that you want to monitor them. 1. In the **Azure Web App Configuration** tab that you opened from **Server Explorer**, change **Detailed Error Messages** to **On**, and then click **Save**.  2. In the **Output** Window, click the **Specify which Microsoft Azure logs to monitor** button. 3. In the **Microsoft Azure Logging Options** dialog box, click **All logs**, and then click **OK**.  4. In the address bar of the browser window, add an extra character to the URL to cause a 404 error (for example, `http://localhost:53370/Home/Contactx`), and press Enter. After several seconds, the detailed error log appears in the Visual Studio **Output** window.  Control+click the link to see the log output formatted in a browser:  ## <a name="downloadlogs"></a>Download file system logs Any logs that you can monitor in the **Output** window can also be downloaded as a *.zip* file. 1. In the **Output** window, click **Download Streaming Logs**. :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-downloadicon.png" alt-text="Screenshot of the Output window showing the Download Streaming Logs button highlighted."::: File Explorer opens to your *Downloads* folder with the downloaded file selected. :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-downloadedfile.png" alt-text="Screenshot of the Downloads folder in File Explorer with a downloaded file selected."::: 2. Extract the *.zip* file, and you see the following folder structure: :::image type="content" source="./media/web-sites-dotnet-troubleshoot-visual-studio/tws-logfilefolders.png" alt-text="Screenshot of the .zip file folder structure after the file has been extracted."::: * Application tracing logs are in *.txt* files in the *LogFiles\Application* folder. * Web server logs are in *.log* files in the *LogFiles\http\RawLogs* folder. You can use a tool such as [Log Parser](https://www.iis.net/downloads/community/2010/04/log-parser-22) to view and manipulate these files. * Detailed error message logs are in *.html* files in the *LogFiles\DetailedErrors* folder. (The *deployments* folder is for files created by source control publishing; it doesn't have anything related to Visual Studio publishing. The *Git* folder is for traces related to source control publishing and the log file streaming service.) <!-- ## <a name="storagelogs"></a>View storage logs Application tracing logs can also be sent to an Azure storage account, and you can view them in Visual Studio. To do that you'll create a storage account, enable storage logs in the Azure portal, and view them in the **Logs** tab of the **Azure Web App** window. You can send logs to any or all of three destinations: * The file system. * Storage account tables. * Storage account blobs. You can specify a different severity level for each destination. Tables make it easy to view details of logs online, and they support streaming; you can query logs in tables and see new logs as they are being created. Blobs make it easy to download logs in files and to analyze them using HDInsight, because HDInsight knows how to work with blob storage. For more information, see **Hadoop and MapReduce** in [Data Storage Options (Building Real-World Cloud Apps with Azure)](https://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/data-storage-options). You currently have file system logs set to verbose level; the following steps walk you through setting up information level logs to go to storage account tables. Information level means all logs created by calling `Trace.TraceInformation`, `Trace.TraceWarning`, and `Trace.TraceError` will be displayed, but not logs created by calling `Trace.WriteLine`. Storage accounts offer more storage and longer-lasting retention for logs compared to the file system. Another advantage of sending application tracing logs to storage is that you get some additional information with each log that you don't get from file system logs. 1. Right-click **Storage** under the Azure node, and then click **Create Storage Account**.  1. In the **Create Storage Account** dialog, enter a name for the storage account. The name must be must be unique (no other Azure storage account can have the same name). If the name you enter is already in use you'll get a chance to change it. The URL to access your storage account will be *{name}*.core.windows.net. 2. Set the **Region or Affinity Group** drop-down list to the region closest to you. This setting specifies which Azure datacenter will host your storage account. For this tutorial your choice won't make a noticeable difference, but for a production web app you want your web server and your storage account to be in the same region to minimize latency and data egress charges. The web app (which you'll create later) should run in a region as close as possible to the browsers accessing your web app in order to minimize latency. 3. Set the **Replication** drop-down list to **Locally redundant**. When geo-replication is enabled for a storage account, the stored content is replicated to a secondary datacenter to enable failover to that location in case of a major disaster in the primary location. Geo-replication can incur additional costs. For test and development accounts, you generally don't want to pay for geo-replication. For more information, see [Create, manage, or delete a storage account](../storage/common/storage-account-create.md). 4. Click **Create**.  5. In the Visual Studio **Azure Web App** window, click the **Logs** tab, and then click **Configure Logging in Management Portal**. <!-- todo:screenshot of new portal if the VS page link goes to new portal -- >  This opens the **Configure** tab in the portal for your web app. 6. In the portal's **Configure** tab, scroll down to the application diagnostics section, and then change **Application Logging (Table Storage)** to **On**. 7. Change **Logging Level** to **Information**. 8. Click **Manage Table Storage**.  In the **Manage table storage for application diagnostics** box, you can choose your storage account if you have more than one. You can create a new table or use an existing one.  9. In the **Manage table storage for application diagnostics** box, click the check mark to close the box. 10. In the portal's **Configure** tab, click **Save**. 11. In the browser window that displays the application web app, click **Home**, then click **About**, and then click **Contact**. The logging information produced by browsing these web pages is written to the storage account. 12. In the **Logs** tab of the **Azure Web App** window in Visual Studio, click **Refresh** under **Diagnostic Summary**.  The **Diagnostic Summary** section shows logs for the last 15 minutes by default. You can change the period to see more logs. (If you get a "table not found" error, verify that you browsed to the pages that do the tracing after you enabled **Application Logging (Storage)** and after you clicked **Save**.)  Notice that in this view you see **Process ID** and **Thread ID** for each log, which you don't get in the file system logs. You can see additional fields by viewing the Azure storage table directly. 13. Click **View all application logs**. The trace log table appears in the Azure storage table viewer. (If you get a "sequence contains no elements" error, open **Server Explorer**, expand the node for your storage account under the **Azure** node, and then right-click **Tables** and click **Refresh**.)  This view shows additional fields you don't see in any other views. This view also enables you to filter logs by using special Query Builder UI for constructing a query. For more information, see Working with Table Resources - Filtering Entities in [Browsing Storage Resources with Server Explorer](https://msdn.microsoft.com/library/ff683677.aspx). 14. To look at the details for a single row, double-click one of the rows.  --> ## <a name="failedrequestlogs"></a>View failed request tracing logs Failed request tracing logs are useful when you need to understand the details of how IIS is handling an HTTP request, in scenarios such as URL rewriting or authentication problems. App Service apps use the same failed request tracing functionality that has been available with IIS 7.0 and later. You don't have access to the IIS settings that configure which errors get logged, however. When you enable failed request tracing, all errors are captured. You can enable failed request tracing by using Visual Studio, but you can't view them in Visual Studio. These logs are XML files. The streaming log service only monitors files that are deemed readable in plain text mode: *.txt*, *.html*, and *.log* files. You can view failed request tracing logs in a browser directly via FTP or locally after using an FTP tool to download them to your local computer. In this section, you'll view them in a browser directly. 1. In the **Configuration** tab of the **Azure Web App** window that you opened from **Server Explorer**, change **Failed Request Tracing** to **On**, and then click **Save**.  2. In the address bar of the browser window that shows the app, add an extra character to the URL and click Enter to cause a 404 error. This causes a failed request tracing log to be created, and the following steps show how to view or download the log. 3. In Visual Studio, in the **Configuration** tab of the **Azure Web App** window, click **Open in Management Portal**. 4. In the [Azure portal](https://portal.azure.com) **Settings** page for your app, click **Deployment credentials**, and then enter a new user name and password.  > [!NOTE] > When you log in, you have to use the full user name with the app name prefixed to it. For example, if you enter "myid" as a user name and the site is "myexample", you log in as "myexample\myid". > 5. In a new browser window, go to the URL that is shown under **FTP hostname** or **FTPS hostname** in the **Overview** page for your app. 6. Sign in using the FTP credentials that you created earlier (including the app name prefix for the user name). The browser shows the root folder of the app. 7. Open the *LogFiles* folder.  8. Open the folder that is named W3SVC plus a numeric value.  The folder contains XML files for any errors that have been logged after you enabled failed request tracing, and an XSL file that a browser can use to format the XML.  9. Click the XML file for the failed request that you want to see tracing information for. The following illustration shows part of the tracing information for a sample error.  ## <a name="nextsteps"></a>Next Steps You've seen how Visual Studio makes it easy to view logs created by an App Service app. The following sections provide links to more resources on related topics: * App Service troubleshooting * Debugging in Visual Studio * Remote debugging in Azure * Tracing in ASP.NET applications * Analyzing web server logs * Analyzing failed request tracing logs * Debugging Cloud Services ### App Service troubleshooting For more information about troubleshooting apps in Azure App Service, see the following resources: * [How to monitor apps](web-sites-monitor.md) * [Investigating Memory Leaks in Azure App Service with Visual Studio 2013](https://devblogs.microsoft.com/devops/investigating-memory-leaks-in-azure-web-sites-with-visual-studio-2013/). Microsoft ALM blog post about Visual Studio features for analyzing managed memory issues. * [Azure App Service online tools you should know about](https://azure.microsoft.com/blog/windows-azure-websites-online-tools-you-should-know-about). Blog post by Amit Apple. For help with a specific troubleshooting question, start a thread in one of the following forums: * [The Azure forum on Microsoft Q&A](/answers/topics/azure-webapps.html). * [StackOverflow.com](https://www.stackoverflow.com). ### Debugging in Visual Studio For more information about how to use debug mode in Visual Studio, see [Debugging in Visual Studio](/visualstudio/debugger/debugging-in-visual-studio) and [Debugging Tips with Visual Studio 2010](https://weblogs.asp.net/scottgu/archive/2010/08/18/debugging-tips-with-visual-studio-2010.aspx). ### Remote debugging in Azure For more information about remote debugging for App Service apps and WebJobs, see the following resources: * [Introduction to Remote Debugging Azure App Service](https://azure.microsoft.com/blog/introduction-to-remote-debugging-on-azure-web-sites/). * [Introduction to Remote Debugging Azure App Service part 2 - Inside Remote debugging](https://azure.microsoft.com/blog/introduction-to-remote-debugging-on-azure-web-sites/) * [Introduction to Remote Debugging on Azure App Service part 3 - Multi-Instance environment and GIT](https://azure.microsoft.com/blog/introduction-to-remote-debugging-on-azure-web-sites/) * [WebJobs Debugging (video)](https://www.youtube.com/watch?v=ncQm9q5ZFZs&list=UU_SjTh-ZltPmTYzAybypB-g&index=1) If your app uses an Azure Web API or Mobile Services back-end and you need to debug that, see [Debugging .NET Backend in Visual Studio](/archive/blogs/azuremobile/debugging-net-backend-in-visual-studio). ### Tracing in ASP.NET applications There are no thorough and up-to-date introductions to ASP.NET tracing available on the Internet. The best you can do is get started with old introductory materials written for Web Forms because MVC didn't exist yet, and supplement that with newer blog posts that focus on specific issues. Some good places to start are the following resources: * [Monitoring and Telemetry (Building Real-World Cloud Apps with Azure)](https://www.asp.net/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/monitoring-and-telemetry).<br> E-book chapter with recommendations for tracing in Azure cloud applications. * [ASP.NET Tracing](/previous-versions/dotnet/articles/ms972204(v=msdn.10))<br/> Old but still a good resource for a basic introduction to the subject. * [Trace Listeners](/dotnet/framework/debug-trace-profile/trace-listeners)<br/> Information about trace listeners but doesn't mention the [WebPageTraceListener](/dotnet/api/system.web.webpagetracelistener). * [Walkthrough: Integrating ASP.NET Tracing with System.Diagnostics Tracing](/previous-versions/b0ectfxd(v=vs.140))<br/> This article is also old, but includes some additional information that the introductory article doesn't cover. * [Tracing in ASP.NET MVC Razor Views](https://devblogs.microsoft.com/aspnet/tracing-in-asp-net-mvc-razor-views/)<br/> Besides tracing in Razor views, the post also explains how to create an error filter in order to log all unhandled exceptions in an MVC application. For information about how to log all unhandled exceptions in a Web Forms application, see the Global.asax example in [Complete Example for Error Handlers](/previous-versions/bb397417(v=vs.140)) on MSDN. In either MVC or Web Forms, if you want to log certain exceptions but let the default framework handling take effect for them, you can catch and rethrow as in the following example: