Debugging VB.NET Applications

Analogy categoryAnalogies

Breakpoints and Stepping Through Code

The Visual Studio debugger for VB.NET works identically to the C# debugger since both target the same CLR debugging APIs, so setting a breakpoint by clicking the left margin next to a line, then running with F5, pauses execution exactly at that line with full access to local variable values in the Locals and Autos windows. From a paused breakpoint, F10 (Step Over) executes the current line and moves to the next without entering called methods, F11 (Step Into) drops into the called method's source if available, and Shift+F11 (Step Out) runs the remainder of the current method and pauses at its return point -- these three keys are the daily-driver navigation for tracing exactly how control flow reaches a bug.

🏏

Cricket analogy: Step Over is like a commentator summarizing an entire over in one sentence without describing each ball, while Step Into is like slowing down to analyze the bowler's exact wrist position on a single delivery, and Step Out is like fast-forwarding through the rest of the over once you've seen the key ball.

Watch Windows and Conditional Breakpoints

For bugs that only manifest after many loop iterations or under a specific input, plain breakpoints that stop every single time are inefficient; right-clicking a breakpoint and choosing 'Conditions' lets you specify an expression like i = 47 or customer.Balance < 0 so execution only pauses when that condition is true, saving you from manually stepping through dozens of irrelevant iterations. The Watch window lets you pin specific variables or expressions (including property calls and method results) so their values are visible continuously as you step, and the Immediate window goes further by letting you execute arbitrary VB.NET expressions -- including calling methods -- while paused, which is invaluable for testing a hypothesis about what a variable's value should be without editing and rebuilding the source.

🏏

Cricket analogy: A conditional breakpoint that only triggers on i = 47 is like a video analyst setting up a highlight reel to only capture deliveries bowled at over 145 km/h, skipping the hundreds of ordinary deliveries automatically.

vbnet

Public Function FindDiscountTier(orders As List(Of Order)) As Decimal
    Dim total As Decimal = 0D

    For i As Integer = 0 To orders.Count - 1
        ' Set a conditional breakpoint here: i = 47
        total += orders(i).Amount

        ' In the Immediate window while paused, try:
        ' ? orders(i).Amount
        ' ? total > 10000
    Next

    Return If(total > 10000D, 0.15D, 0.05D)
End Function

Structured Exception Handling for Diagnosis

VB.NET's Try...Catch...Finally gives you the same structured exception handling as C#'s try/catch/finally, and Visual Studio's 'Break on Exceptions' setting (Debug > Windows > Exception Settings, or Ctrl+Alt+E) lets you configure the debugger to pause the instant a NullReferenceException or IndexOutOfRangeException is thrown, even inside a Catch block that would otherwise swallow it silently -- this is essential for tracking down exceptions that are caught somewhere upstream but whose root cause is buried deep in the call stack. VB.NET also uniquely supports the Catch...When filter clause, letting you catch an exception only when an additional boolean condition is true (for example, Catch ex As SqlException When ex.Number = 2601), which avoids catching and inspecting exceptions you don't actually want to handle in that block.

🏏

Cricket analogy: Break on Exceptions catching a NullReferenceException the instant it's thrown is like a third umpire immediately freezing the replay the moment contact is made with the bat, rather than waiting until the ball has already crossed the boundary to review it.

To enable break-on-throw for a specific exception type in Visual Studio: Debug > Windows > Exception Settings (Ctrl+Alt+E), expand 'Common Language Runtime Exceptions', and check the box next to the exception type (e.g. System.NullReferenceException). The debugger will now pause exactly where the exception is thrown, even if a Catch block further up the stack would otherwise handle it silently.

Reading the Call Stack and Diagnosing Root Cause

When execution is paused (either at a breakpoint or an unhandled exception), the Call Stack window shows the full chain of method calls that led to the current line, with the most recently called method at the top; double-clicking any frame in the stack navigates the editor to that exact line and updates the Locals window to show that frame's variables, letting you trace backward from the symptom (where the exception was thrown) to the actual root cause (the caller that passed bad data). For deployed applications where you can't attach a live debugger, Environment.StackTrace and logging the full Exception.ToString() (which includes the inner exception chain and stack trace) into a log file via a library like Serilog or NLog is the standard substitute, letting you reconstruct the call chain after the fact from log output.

🏏

Cricket analogy: Reading the call stack from top to bottom is like a match referee reviewing the exact sequence of events leading to a run-out, working backward from the broken stumps to the throw, to the fielder's pickup, to the batsman's call.

Never rely on a Try...Catch that swallows an exception with an empty Catch block in production code -- it hides the root cause entirely and makes future debugging via the call stack impossible. At minimum, log Exception.ToString() (which includes the stack trace and any inner exceptions) before deciding whether to suppress or rethrow.

The Visual Studio debugger works identically for VB.NET and C#, using the same breakpoints, Step Over/Into/Out, and Locals/Watch windows.
Conditional breakpoints (right-click > Conditions) pause execution only when a specified expression is true, saving time on loops with many iterations.
The Immediate window lets you execute arbitrary VB.NET expressions, including method calls, while paused at a breakpoint.
Enabling 'Break on Exceptions' (Ctrl+Alt+E) pauses the debugger at the exact throw site, even inside a Catch block that would otherwise handle it silently.
VB.NET's Catch...When filter clause lets you catch an exception only when an additional condition is true, avoiding overly broad catch blocks.
The Call Stack window lets you trace backward from a symptom to its root cause by navigating through each calling frame.
For deployed apps without a live debugger, logging Exception.ToString() via Serilog or NLog is the standard way to reconstruct the failure after the fact.