1. Debugging Under The Hood Tim Chew Consultant Arch Signal Sdn Bhd

2. Agenda Introduction Coding Tips Techniques Tools & Utilities Cases

3. Introduction

4. What is debugging? Attaching a debugger to your application and finding bugs Setting breakpoints in the debugger and watching variables

5. Introduction Two points of views: 1.Finding bugs in your program 2.Finding out why a program/application does what it does

6. Introduction Finding bugs in your program Narrower perspective Finding out why a program/application does what it does Wider perspective Opens the mind to a greater variety of techniques and avenues

7. Introduction Where’s the source? You may not always have the source code, and you still have to fix it Even if you don’t have the source code, the root or cause of the bug may still have to be determined

8. Introduction A little history… The computing term ‘bug’ is popularly attributed to Grace Hopper (Grandma Cobol) in the 1940’s A moth was found stuck in the Mark II computer at Harvard

9. Introduction

10. Coding Tips

11. Asserts Debug output Debug break Is the debugger attached? Compiler directives Parameters checking Exceptions

12. Coding Tips: Asserts An assert checks for a condition, and outputs a diagnostic message including the call stack if the condition is false. “Assert everything” ~ John Robbins

13. Coding Tips: Asserts Only assert that which would otherwise be a programming error In other words: If the assertion is false, it is a programming error Never assert expressions that are expected as part of normal data/code functionality Asserts only defined in debug builds (Compiler symbol: DEBUG)

14. Coding Tips: Debug Output “When in doubt, printf!” Write messages to the debugger Win32: OutputDebugString().NET: Debug.WriteXxx(), Trace.WriteXxx()

15. Coding Tips: Debug Output Writing to the console requires access to the standard output (stdout). Commonly, available in: –Debugger –Console You will not always be able to debug your program with a debugger attached –The debugger may throw off the speed of execution due to diagnostics which may prevent a bug from manifesting

16. Coding Tips: Debug Output –To inspect variables, you will need to break the execution, which may prevent a bug from manifesting. Common in UI and input device related bugs Printing messages is often useful to determine the order of the occurrence of specific 'events' Use DebugView from Sysinternals: –No need to attach debugger to process –Application can execute 'normally' Debug vs. Trace

17. Coding Tips: Debug Output Debug Defined in DEBUG builds Compiled when DEBUG symbol is defined Trace Defined in RELEASE builds

18. Coding Tips: Debug Break Hard breakpoint Win32: DebugBreak().NET: Debugger.Break() Useful when a debugger cannot be attached during execution Causes the system to prompt for attaching debugger at the point of the break Processor interrupt: INT 3

19. Coding Tips: Debugger Attached? Can be used to make the program behave differently: –Debugger not attached Output debug string –Debugger is attached Cause a break Windows NT has code which uses this technique when handling heap corruption

20. Coding Tips: Compiler Directives.NET #if #elif #else #endif Conditional-compile can only check for whether a symbol is defined –#if DEBUG –#if !SILVERLIGHT

21. Coding Tips: Check Parameters Validating parameters appropriately reduces potential for bugs You may still want to check certain expressions that have been asserted Should I check for null? Yes Should I check the validity of all objects? Use common sense Can the.NET allocator (new) fail? Yes! Do Memory squeezing!

22. Coding Tips: Exceptions Easy to abuse Try/catch blocks –Should I wrap everything in a try/catch block? NO –Only protect code where exceptions are expected Should I put gigantic try/catch gloves over my entire code base? –Do not try to cover for poor programming with exception handlers –Bad code that crashes SHOULD be allowed crash –It is not only easier to find bugs this way, but exceptions reduces code performance Unwinding objects and stack is expensive

23. Coding Tips: Exceptions Exceptions should only be thrown when an unexpected or invalid (an exceptional) event occurs that prevents code from continuing normally Exception handling introduces overhead and lowers performance and should not be used to control normal program flow (in place of conditional processing) It can also be difficult to maintain code that abuses exception handling in this way Ultimately: use Common Sense

24. Coding Tips Demo Asserts Debug strings Debug breaks Debugger presence Compiler directives

25. Techniques

26. Visual Studio IDE Debugger Tool windows: –Call Stack –Breakpoints –Immediate Window –Output –Watch –Modules –Threads –Registers –Memory

27. Techniques: No Source Code Knowledge of basic Intel x86 assembly required Set breakpoints in system and other binaries (DLL) Find loaded modules PE (Portable Executable) export table (EAT) Relative Virtual Address (RVA) System rebasing of DLL's Inspection of parameters on stack Function return value Use memory window in VS debugger to view data

28. Techniques Multithreaded Bugs Generally occur due to: Poor synchronization of access to resources Tip: Avoid multithreading access to primary display device

29. Demo Step into Win32 binaries –Find Win32 DLL exported functions Step into.NET assemblies –Microsoft.NET assemblies –Other.NET assemblies

30. Tools & Utilities Visual Studio IDE Debugger PEBrowsePro (http://www.smidgeonsoft.prohosting.com/pebrowse-pro- file-viewer.html) –PE Structure –Disassembler DebugView (http://technet.microsoft.com/en- us/sysinternals/bb896653.aspx) –Capture system debug strings ProcessExplorer (http://technet.microsoft.com/en- us/sysinternals/bb896647.aspx) –Examine system processes Spy++ –Examine system application windows

31. Cases

32. The worst kinds of bugs Optimization bugs Compiler bugs

33. C# Compiler bug Can compile the following expression correctly… a ^= b ^= a ^= b; But fails to generate the correct code! … Since 2003!

34. Microsoft.NET Common Language Runtime – Work Station (mscorwks.dll) Bug in module loading Potential root cause: deadlock when process made to load DLL immediately after startup (during startup process) Thread does not signal (exit) if waited on infinitely If thread (handle) is closed, process crashes

35. Cases Description: Stopped working Problem signature: Problem Event Name: APPCRASH Application Name: MyApp.exe Application Version: 1.0.0.0 Application Timestamp: 49f5e887 Fault Module Name: mscorwks.dll 719EFF8A call dword ptr ds:[71EB3244h] 719EFF90 mov esi,eax > 719EFF92 mov eax,dword ptr [esi+0Ch]

36. Questions

37. Contact Thank you! Tim Chew E-Mail Business: tim@archsignal.comtim@archsignal.com Personal: tim@bugslayersrus.comtim@bugslayersrus.com Blog: http://ntstatus.blogspot.com/http://ntstatus.blogspot.com/ Slides: http://www.archsignal.com/downloads-prez.html