Debugging Applications

Level: Beginner to Intermediate

ℹ️ What You'll Learn

• Breakpoints and stepping through code
• Watch variables and expressions
• Debug output with Console.WriteLine and Debug.WriteLine
• Debugging in Visual Studio
• Common debugging scenarios
• Performance profiling

Breakpoints

Stop execution at specific line to inspect state.

In Visual Studio:

• Click left margin next to line number
• Red dot appears (breakpoint)

In VS Code:

• Ctrl+K, Ctrl+B to toggle breakpoint
• Or click margin

Run with debugging:

dotnet run

Or in IDE: F5 or Debug → Start Debugging

Stepping Through Code

After hitting breakpoint:

Command	What It Does
F10 or Step Over	Execute current line
F11 or Step Into	Enter method call
Shift+F11 or Step Out	Exit current method
F5 or Continue	Resume execution

Watch Variables

While paused at breakpoint:

In Visual Studio → Variables window:

• View current variable values
• Change values (for testing)
• Evaluate expressions

Example: Type student.Name.Length to evaluate.

Debug Output

Print messages during execution:

Console.WriteLine("Student Name: " + student.Name);
Debug.WriteLine("SQL Query: " + query);

Console output in Debug console.

Common Debugging Scenarios

Scenario 1: Variable has wrong value

1. Set breakpoint before the line
2. F10 to step
3. Check variable value in Watch

Scenario 2: Method not called

1. Set breakpoint in method
2. Run application
3. Breakpoint not hit = method not called

Scenario 3: Exception thrown

1. Exception breaks execution
2. Check exception message
3. Trace stack to root cause

Conditional Breakpoints

Break only when condition true.

Right-click breakpoint → Condition:

count > 10

Only pauses when count is greater than 10.

Debugging ASP.NET Core

1. Start debugging: F5
2. Make API call (Postman)
3. Breakpoint hits
4. Inspect request parameters

[HttpGet("{id}")]
public IActionResult GetStudent(int id)  // Breakpoint here
{
    // At breakpoint, inspect id value
    return Ok();
}

Logging for Production

Don't use breakpoints in production.

Use logging instead:

private ILogger<StudentService> _logger;

public StudentService(ILogger<StudentService> logger)
{
    _logger = logger;
}

public void CreateStudent(Student student)
{
    _logger.LogInformation("Creating student: {Name}", student.Name);
    // ... code ...
    _logger.LogError("Failed to create student: {Error}", ex.Message);
}

Check logs in production environment.

Performance Profiling

Find performance bottlenecks.

Visual Studio Profiler:

• Debug → Performance Profiler
• Select CPU Usage
• Run application
• Identify hot spots (slow functions)

Optimize slow methods.

🎯 Interview Favourite

Q: How do you debug a .NET application when something goes wrong?

Good Answer: "First, I set a breakpoint at the suspected line by clicking the left margin in the IDE. When I run the application with debugging enabled (F5), execution pauses at the breakpoint. Then I use Step Over (F10) to execute line-by-line and inspect variable values in the Watch window to see if they match expectations. If stepping shows the method isn't called at all, the logic before it must be wrong. For production issues I can't debug directly, I use structured logging with ILogger to log important information and errors. Performance issues are identified using the Visual Studio Performance Profiler to find which functions consume the most CPU time."

🤖Use AI to Learn Faster

Use ChatGPT, Claude, or Copilot to go deeper on Debugging .NET applications. Try these prompts:

• "How do I set and use breakpoints?"
• "What is the difference between Step Over and Step Into?"
• "How do I debug ASP.NET Core Web API?"
• "When should I use logging instead of breakpoints?"

💡 Tip: After reading this article, paste your own code into AI and ask "What could go wrong here and why?" — fastest way to find edge cases and deepen understanding.

Next Article

-> Version Management and Updates