Debugging .NET Applications

Debugging .NET Applications

Huma Qureshi

Debugging .NET Apps © Huma Qureshi

About the trainer

• Huma Qureshi• Independent training

consultant• Self-employed

entrepreneur

• Past• BS-CS from Fast-

Lahore• MS-CS from University

of Washington, Seattle• Techlogix, Conrad Labs,

Microsoft

• Contact• huma.qureshi@netsolte

ch.com• [email protected]

m


Introductions

• Name & background

• Career aspirations

• Experience with .NET

• Any other thing…


Why this course

• Discussion


Course outline

1. The debugging process

2. Visual Studio debugging tricks

3. Building for debuggability1. Symbols, .NET source stepping

4. Minidumps and remote debugging

5. Multi-threaded debugging in VS

6. Profiling and IntelliTrace

7. Introduction to WinDbg


THE DEBUGGING PROCESS


Bugs

• Are a reality!• But good engineering teams see lesser of them late

in the cycle

• Are awesome!• If you find them before the customer does

• You learn most when fixing bugs

• Must be found “as early as possible”


Bugs

• Are a HUGE cost

• Most development teams spend more than 50% of their time debugging

• The better you debug the faster you ship and the higher the quality


Cost of buggy products

• More time maintaining -> less time building new features

• Huge maintenance cost

• Results in• You company going out of business

• You loosing your job


Reasons for buggy products


1. Dev ignorance or insufficient training• Reasons:

• Too many technologies to keep up with

• Dev ego comes in the way of learning

• Solutions:• Admit the deficiency

• Invest time in learning – online trainings, conferences, on-site trainings

• Mentoring


2. Lacking “commitment to quality”• Organizations claim, but not often are truly

committed to quality.

• Focus on short term achievements vs long term success.

• Every individual must advocate the “commitment to quality” in his capacity.


Debugging pre-reqs


1. Excellence = “Attention to detail”• Good debugging skills requires:

• “Phenomenal attention to detail” as a developer.• Avoid bugs

• Avoid resorting to the debugger

• Being good with available toolset.

• All good developers are good debuggers• They pay “attention to detail”


2. Avoid the debugger

• Take time to develop understanding of the problem you are trying to solve

• Take time to understand the underlying APIs you are consuming

• Program defensively


3. But before jumping into the debugger..• Know what you are trying to chase

• Write down the hypothesis you are going to test


4. Know the toolset

• Much faster and efficient if you know how to fully utilize the power of toolset available.!


5. Take a break - “Bug Talk”

• Getting stuck for too long kills creative thinking.

• When stuck at a problem for long• You are likely making some un-real assumptions

• Discuss with a peer

• Explain your issue – and likely you would understand while explaining.


The debugging process



Fix the bug

Formulate new

hypothesis

Duplicate

Own the bug

Formulate hypothesis

Divide and conquer

Think creatively

Leverage tools

Bug talk

Verify fix

Document learning

Describe

Q & A


VISUAL STUDIO DEBUGGING TOOLS


Debugee modules and symbols


Debugging tools are same across .NET• Technology doesn’t matter.

• There is one debugger that helps debug “.NET” code.


Start debugging: existing solution in Visual Studio


Start debugging: Process running outside Visual Studio


Show the modules window


Modules Window (loaded dlls)


Module Symbols (pdb files)

• An executing process is machine code.

• We need pdb files to translate the machine code to C# code and allow debugging.

• Must always save the pdb files for builds that are released.


Contents of pdb file

• Mapping of each IL offset to a source file and line number

• Names of the local variables in each function block, and their memory offset


Visual Studio debugger tips


Basic commands

• Start Debugging

• Insert/remove breakpoint

• Step over

• Step in

• Step out


Step into (F11)

• Start debugging with F11 to break at first line of your code executed.

• Good for debugging app startup issues


Run to cursor (Ctrl + F10)

• Runs the program and breaks execution at cursor position

• No need to set temporary breakpoint and then later delete it.


Data Visualizers


Data Visualizers: WPF Tree visualizer


Custom visualizers

• You can write your own visualizer for your specific ‘type’

• https://msdn.microsoft.com/en-us/library/ms164759.aspx


Data tips


“Refresh to enumerate” –function evaluation


Call stack: Show external code


Call stack: show parameter values


The locals, autos and watch window• Locals window

• All variables in current scope

• Autos window• Variables from current and previous statement

• Subset of locals window

• Watch window• User defined variables


Set next statement (altering execution flow)


Edit and continue

• Allows you to change your source code while your program is in break mode

• No need to restart debugging session to test a small code change.

• Handles most code changes in method bodies (except lambda expressions)


Step into specific

• Step into a specific method. For statements with nested method calls.


Step into specific


Immediate window

• Debugging unintegrated code


Tracepoints


Tracepoints


Conditional breakpoints


Conditional breakpoints


Viewing out of scope objects (Object ID)


Viewing out of scope objects (Object ID)


Useful keyboard shortcuts

Debug.BreakatFunction Ctrl+B

Debug.BreakAll Ctrl+Alt+Break

Debug.DeleteAllBreakpoints Ctrl+Shift+F9

Debug.Exceptions Ctrl+Alt+E

Debug.QuickWatch Ctrl+Alt+Q or Shift+F9

Debug.Restart Ctrl+Shift+F5

Debug.RunToCursor Ctrl+F10

Debug.SetNextStatement Ctrl+Shift+F10

Debug.Start F5

Debug.StartWithoutDebugging Ctrl+F5

Debug.StepInto F11

Debug.StepOut Shift+F11

Debug.StepOver F10

Debug.StopDebugging Shift+F5

Debug.ToggleBreakpoint F9

References

• Writing your own visualizer:• https://msdn.microsoft.com/en-us/library/ms164759.aspx

• Supported changes in ‘edit and continue’• https://msdn.microsoft.com/en-us/library/ms164927.aspx

• Full list of shortcuts:• http://msdn.microsoft.com/en-us/library/da5kh0wa.aspx

• Visual Studio debugging MSDN resources:• http://msdn.microsoft.com/en-us/library/k0k771bt.aspx


Q & A


BUILDING FOR DEBUGGABILITY


Build configurations


Building debug vs release


Building debug vs release:Default settings in proj file


Building debug vs release:build configurations


#if Preprocessor directive

• When the C# compiler encounters an #if directive, followed eventually by an #endif directive, it will compile the code between the directives only if the specified symbol/constant is defined.

Defined in project msbuild file


Compiler optimizations

• The optimize property tells the compiler to optimize the compiled code.

• Optimized builds:• more performant and hence used for retail

configuration.

• hard to debug, so we turn of optimizations in debug builds.


Debug vs Release build

• Debug -> Not optimized

• Retail -> optimized


Debug vs Release build

• ‘Debug’ build is configured for debugging• So customize it to help debugging

• ‘Release’ build is configured for production


AssertionsExpecting the unexpected


Debug.Assert()

• Effects only debug build

• Tests a condition and if the condition evaluates to false, the assertion fails -- your program enters break mode.


Failed assertion


Failed assertion

• Ignore

• Retry – break in

• Abort – abort the process


Assertions uses

• Assert liberally. You can never have too many assertions.

• Assertions don't replace exceptions. • Exceptions cover the things your code demands;

assertions cover the things it assumes.

• A well-written assertion can tell you not just what happened and where (like an exception), but why.

• The assertion failed dialog lets you attach a debugger to the process, so you can poke around the stack as if you had put a breakpoint there.


Assertions: Never change program state


The Debug class

• Collection of methods to assert or print to Debug output.

• Only if DEBUG constant is defined


The Trace class

• Collection of methods to assert or print to Trace output.

• Only if TRACE constant is defined


Adding your custom debug and trace listeners


Build Symbols


Symbols and symbol servers

• Always keep symbols around for your builds• Allows to debug issues on actual build running in

production/staging/test environment

• Create an internal symbol server for caching symbols of internal and released builds

• Can be easily automated using team build


Microsoft public symbols


.NET source stepping


References

• .NET source stepping:• http://referencesource.microsoft.com/setup.html

• List of dlls you can step:• http://referencesource.microsoft.com/indexedpdbs.txt

• Creating your team symbol server:• http://www.lionhack.com/2014/01/14/advanced-

dotnet-debugging-pdbs-and-symbols/


Q & A


Debugging .NET Applications

Documents

Transcript of Debugging .NET Applications