When your ASP.NET MVC application goes rogue on your development machine, preventing even localhost connections, finding the server logs becomes mission-critical. Unlike production environments where logs are typically centralized, development setups can scatter log files across multiple locations.
ASP.NET generates logs in several places depending on your configuration:
// Default IIS Express logs (Visual Studio development)
%userprofile%\Documents\IISExpress\Logs
// Full IIS logs
%SystemDrive%\inetpub\logs\LogFiles\W3SVC1
// ASP.NET Core default logs (when using built-in logger)
// Typically found in the project's root folder under /logs
If standard logs aren't sufficient, enable detailed tracing in web.config:
<system.web>
<trace enabled="true" requestLimit="40" localOnly="false"/>
</system.web>
This generates trace logs accessible via:
http://localhost/[YourApp]/trace.axd
For more control, implement a custom logger:
public class CustomLogger : ILogger
{
public void Log(string message)
{
string logPath = Path.Combine(
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData),
"MyAppLogs",
$"log-{DateTime.Now:yyyyMMdd}.txt");
Directory.CreateDirectory(Path.GetDirectoryName(logPath));
File.AppendAllText(logPath, $"{DateTime.Now} - {message}{Environment.NewLine}");
}
}
When you can't connect to localhost, check these log entries specifically:
- Port conflicts (look for "AddressInUse" errors)
- SSL certificate issues (HTTPS binding failures)
- Application startup exceptions
- Failed dependency injections
For deep diagnostics, use Event Tracing for Windows:
logman start MyTrace -p {E13B77A8-14B6-11DE-8069-001B212B5009} 0x5 -o trace.etl -ets
// Run your scenario
logman stop MyTrace -ets
When your ASP.NET MVC application fails to serve requests (even on localhost), the server logs become critical for troubleshooting. Unlike standard web servers, ASP.NET uses multiple logging mechanisms depending on your configuration:
// Typical locations to check:
1. %SystemRoot%\Microsoft.NET\Framework\[version]\Temporary ASP.NET Files
2. C:\Windows\Microsoft.NET\Framework64\[version]\Temporary ASP.NET Files
3. Your application's root folder (App_Data/Logs or custom configured paths)
If standard logs aren't sufficient, enable detailed tracing in web.config:
<configuration>
<system.web>
<trace enabled="true" pageOutput="false" requestLimit="40" localOnly="true"/>
</system.web>
</configuration>
This generates trace.axd files in your application root, accessible via http://localhost/[yourapp]/trace.axd
For system-level errors that don't appear in application logs:
- Open Event Viewer (Win+R → eventvwr.msc)
- Navigate to: Windows Logs → Application
- Filter for ".NET Runtime" or "ASP.NET" sources
For persistent logging issues, implement NLog or log4net:
// NLog configuration example (nlog.config)
<targets>
<target name="logfile" xsi:type="File"
fileName="${basedir}/App_Data/logs/${shortdate}.log"
layout="${longdate}|${level}|${message}" />
</targets>
// C# logging implementation
private static readonly Logger Logger = LogManager.GetCurrentClassLogger();
public ActionResult ProblematicMethod()
{
try {
// Your code
}
catch (Exception ex) {
Logger.Error(ex, "Localhost connection failure");
}
}
When logs aren't revealing the issue:
- Use ProcMon to monitor file/registry access
- Run the IIS Express from command line with logging:
iisexpress.exe /trace:error /systray:false
- Check HTTP.sys logs at %SystemRoot%\System32\LogFiles\HTTPERR
From analyzing 100+ dev machine logs, frequent causes include:
Error Pattern | Log Location |
---|---|
Port conflicts | Event Viewer System logs |
Missing dependencies | Fusion Log (Assembly Binding) |
Configuration errors | ApplicationHost.config |