Debugging .NET applications using Visual Studio and Debugging Tools for Windows
•Télécharger en tant que PPT, PDF•
1 j'aime•2,133 vues
Debugging is an important part of the software development process that helps developers write more reliable code. There are several tools available for debugging .NET applications, including Visual Studio and Debugging Tools for Windows. Some basic debugging tasks involve setting breakpoints, stepping through code, examining variables and call stacks, and understanding memory usage and threads. Postmortem debugging techniques like dump file analysis can help debug problems that occur in production environments where live debugging is not possible.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Debugging .NET applications using Visual Studio and Debugging Tools for Windows
Similaire à Debugging .NET applications using Visual Studio and Debugging Tools for Windows (20)
Plus de Bala Subra
Plus de Bala Subra (20)
Debugging .NET applications using Visual Studio and Debugging Tools for Windows
- 1. .NET Debugging Techniques Bala Subra
- 15. VS Debugger Architecture VSDebug Package SDM CPDE (Managed) NatDbgDE (Native) Your Engine Here Your EE Here http://msdn.microsoft.com/en-us/library/bb161718.aspx
- 20. Symbols: Reference Source Support
- 21. Symbols: Visual Studio Options
- 32. Demos
- 43. Walkthrough for managed heap commands
- 49. Windows Memory Architecture Application Virtual Memory Manager Heap Manager Default Process Heap C Runtime Heap Other Heaps
- 50. Heap Block Structure Current Size Previous Size Seg Index Flags Unused Tag Index Pre-allocation Metadata Post-allocation Metadata User accessible part Pre-allocation Metadata Suffix Bytes Fill Area (debug) Heap Extra Post-allocation Metadata User accessible part User accessible part
- 54. Windows Error Reporting (WER) Architecture Error Sent Dr. Watson Process Crash Crash data over HTTPS Fault response over HTTPS Windows Error Reporting Service ISV Query Fault Data
- 56. Walkthroughs with ADPlus & Postmortem debugging
Notes de l'éditeur
- Code reviews and Tracing are the old techniques to find out issues with the code. Unit Testing is the current mantra. But, the good old native debuggers are the way to resolve multi-process, multi-machine server applications. We will chat about using SOS, MDA, Windows Performance Monitors, CLR Profilers and NTSD with zero footprint & no config changes to production environment. The Visual Studio Debugger provides a slew of features that make the task of debugging both easier and more efficient. Learn about time-saving tips and tricks for all versions of the Visual Studio Debugger, including the new debugger features in Visual Studio 2010. Hear about the new mixed-mode debugging feature, the breakpoints window enhancements, the new WPF visualizes, and a number of other features. Also learn about thread debugging enhancements, new features for making stepping into properties easier, and more. Join us as we crack open the toolbox and walk through some of the debugger's best practices. Focus on powerful native debugging tools including WinDBG, NTSD, and CDB. introduce key concepts needed to successfully use .NET’s native debuggers. Next, turn to more sophisticated debugging techniques, using real-world examples that demonstrate many common C# programming errors. For developers who want a deeper understanding of how .NET works, to gain the necessary tools and use them to debug and solve real world problems that cannot be fixed with regular debuggers.
- A defect that costs $1 to fix on the programmer’s desktop costs $100 to fix once it is incorporated into a complete program and many thousands of dollars if it is identified only after the software has been deployed in the field. (Building a Better Bug Trap – The Economist June 2003) Static Analysis can reduce defects by up to a factor of six! (Capers Jones, Software Productivity Group)
- Compile-time analysis of the source program like code inspection, but performed by a tool Looks for violations of well-defined constraints procedure contracts Examples of bugs to be found by Static Analysis IoCompleteRequest(p) requires p to be non-NULL: p = NULL ; … ; IoCompleteRequest(p); Completing the same task twice when NOT needed: IoCompleteRequest (Irp); … IoCompleteRequest (Irp);
- Static Analysis does 2 Things: Finds a defect - without testing Reveals the path - without debugging Path Coverage One test case covers only one path in the driver The path remains unrevealed if no defect found 100 test cases cover < 100 paths? More test cases -> more duplication How many paths remain untested? How long would it take to test all of them? When are you done? Longer than you can afford! Time to market? 100% Coverage In minutes or hours, not weeks or months Employing Computer, not a Test Engineer Targeting a large set of potential violations
- 1: Introduction to .NET Debugging. Explains the differences between Unmanaged (native) and managed (.NET) debugging, and explore the tools required for successful debugging. 2: CLR Fundamentals. Explores the physical layout of a managed assembly, the native CLR structural hierarchy, managed objects, and the role that JIT compilation plays in managed execution. 3: .NET Memory Management. Examines .NET memory management including the Garbage Collector (GC) and Finalizers. 4: Troubleshooting Hangs. Defines, parses, and troubleshoots “hang” scenarios in WinForms and ASP.NET applications. 5: Troubleshooting Exceptions. Dives into the different types of exceptions, including those that go unhandled in WinForms and ASP.NET applications. 6: Additional Debugging Tools. Reviews additional tools and debugging scenarios.
- Dbgrsv.exe, kdsrv.exe, dbengprx.exe Debugger protocol remoting tools Discussed later as part of debugger remoting Security Audit Debugging
- Nothing magic; Understand the code and its underlying illusions
- Inspire of code auditors, reviews, FxCop... Impossible Business side of things
- For example: Compiler will not catch an un-initialized pointer but you WILL get a run-time error if you try to use it! Some simple programming techniques * To improve diagnosability of your code * To help support folks get more out of the crash dumps * To enable them determine root cause of an issue from a single crash dump * So they don’t have to ask the customer to reproduce the problem again to get them yet another crash dump Debugging should be data centric not code centric * Especially TRUE for a crash dump * No execution and no execution control * All you have is snapshot of data structures to examine
- Kdbgctrl.exe Tool to configure the kernel’s debugging options Run it on the target machine Change behavior of DbgPrint, user mode int 3, DbgPrint buffer size, etc.
- http://blogs.msdn.com/jacdavis/archive/2008/02/20/new-debug-engine-sample.aspx he Visual Studio Debugger is split up architecturally into a few pieces: 1) The debugger UI: the windows and commands the user actually interacts with. A good example of this is the watch window or the little red circle that appears in the text editor as a breakpoint. 2) The SDM (session debug manager): “ A debug engine multiplexer” Admittedly, that’s a confusing explanation. Essentially, the SDM’s job to combine all of the events and commands for the various debug engines into one unified stream for the UI. The debugger UI only displays one ”view” of what is being debugged at a time. Even if the user is debugging multiple processes or threads, they are only looking at one of them. 3) Debug Engines – the components that perform the actual debugging of a debuggee. For instance, a native debug engine would be responsible for debugging native win32 applications. A script debug engine would be responsible for debugging jscript or vbscript. A CLR debug engine would be responsible for debugging .Net applications running on the CLR. A hypothetical Perl engine could be responsible for debugging Perl… and on and on Visual Studio Debug Engines implement and interact with a set of interfaces called AD7 which stands for Active Debugging 7. AD7 is publically documented here: http://msdn2.microsoft.com/en-us/library/bb147088.aspx
- symproxy: a symbol server request proxy Similar to a web server proxy Allows local caching to reduce load on primary server Putting a proxy on a bridge server allows symsrv requests to cross network boundaries agestore: a new tool to manage local caches Simple aging and cleanup of locally-stored files
- Use Right click on Module: “Symbol Load Information” to find out where we looked
- 16 Megs in today's world of .NET framework Production machines can't hv Visual Studio; not updated with latest patches Operations team is diff from dev primarily used for managed code debugging Diff between them WinDBG is not console based; GUI; step through etc NTSD & CDB are console based Security team; Windows HEAT team etc hv written plugins; etc capabilities Ability to write debugging extensions for our programs/projects/products
- 64 or which architecture? SDK is also available for developing our own extensions Debugger Extensions Dump or analyze complex data structures !process, !devnode, !poolval Leverages the type information from the PDB file Simplify routine tasks !analyze Automate repetitive steps Regularly check state of certain objects Fully control the state of the target Can write a mini-debugger using the extension APIs When Should You Write One? Any task that is repetitive can be sped up by developing an extension Allows other people (testers) to help with basic debugging Can help identify common problems quickly To dump internal data structures in a custom readable format Avoid writing extensions when: Code is still fluctuating a lot Extension must match the code being debugged
- Analysis Step 1 Use bugcheck or exception parameters to extract basic information Each condition is processed by a separate routine that understands the meaning of each parameter If specific follow-up or faulting code is found, report results Save trap frame, context recording, faulting thread, etc. Analysis Step TWO Use information in step one to get faulting stack Scan the stack for special functions such as Trap0E or UnhandledExceptionFilter to find alternate stack Analyze frames on the final stack to determine most likely culprit Different weights are assigned to routines Internal kernel routines have lowest weight Device drivers have highest weight Fine grain control provided by triage.ini Highest weight frame found on the stack is treated as the culprit Analysis Step Three If stack does not yield an interesting frame, analyze raw stack data Iterate on all stack values using the same weight algorithm The ‘dps’ command will show that output This finds code that corrupts the stack Analysis Step Four Check for presence of memory or pool corrupting drivers Check for corrupted code streams Bad RAM Check for other possible problems, such as invalid call sequences Possible CPU problem Analysis Step Five Generate final bucket ID and follow-up based on all gathered information Determine which fields need to be embedded in the bucket ID !analyze assigns ownership of failure
- Use Task manager; Get Process ID (TList) Start the app; instead of attaching to already existing Example of Windows NT Heat dependent process; additional information is filled in the blocks. Not Release debugging; So, Debug version is ran
- show diff between -p (more dlls loaded) and starting manually
- http://blogs.msdn.com/jacdavis/archive/2006/08/25/using-sos-in-visual-studio.aspx http://http/www.microsoft.com/whdc/devtools/debugging/default.mspx http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/default.aspx How do you go about using SOS in VS? Well first, you have to have the native debugging engine enabled. This is because SOS examines the CLR data structures from the debugger process so it must have access to the native address space. To do this from a console application project or winforms project, right mouse click on the project in solution explorer, choose properties, switch to the Debug tab, and make sure &quot;Enable Unmanaged Code Debugging&quot; is selected. With that done, close the property page add a breakpoint somewhere in your project, and hit F5. Once you've hit your breakpoint, the real fun begins. 1) Open the Immediate window (Debug->Windows->Immediate) 2) Type &quot;.load C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\sos.dll&quot; and hit enter (you may need to change the path to point to a different location on your machine). The immediate window should respond by saying &quot;extension C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\sos.dll loaded&quot; 3) Type &quot;!help&quot; sos should dump its help contents to the immediate window. It is now ready to use.
- Symbols are extremely important when debugging native code While managed code are not so much important Source code lines are not present Proprietary information Run tool to strip all Private symbol Publish public symbol files For own symbol files instead of Microsoft refresh the symbol files
- 03Simple.exe demo for Symbols start with ntsd instead of attaching ntsd 03simple.exe .sysmfix .sympath+ c:\\ .reload
- Collect all binary files into a Single Location Essential for library vendors Use them from a share (Private symbols) Publish the symbols on a HTTP server (public) Publish the symbols on a Secure HTTP server (Private) Works with other Tools (Process Monitor, profiler) SourceServer is an alternate stream into Private Symbol PDBs Contains information to retrieve the source file from the Source revision control system
- CLR manages thread differently than Windows Native debuggers don't hv much idea abt Managed Code SO CLR understanding debuggers Threads getting deadlocked kind of scenarios
- Demo ntsd 03simple.exe g ctrl + C .sysmfix .reload .loadby sos mscorwks !help !help Threads
- Multi-threading is easy but tricky Hash code of the objects Lock info how many bytes long? 4 or 8 Deadlock issues 200 Threads waiting Instead of going one by one on each of the 200 Execute and get everything for each thread running
- Run the app - start from cmd 06deadblock.exe TList ntsd -p processID .symfix .reload .loadby sos mscorwks ~*e!ClrStack ~0S (ZEROTH thread) !Dumpstack ~3s !DumpStack Use Syncblock to find out more info !SyncBlk Who is holding locks? Actual object which is holding? Address of the object !do !do on the object open the source code SOSex has the DumpObject command
- No memory leaks Just new No need to delete in destructor Statistical summary - how many instances Type etc Specify address of the object Size, type etc 2 things Does not hv any references for it ?? Is it eligible for GC If not, who has references for it? (Native resources not getting freed up) Instead of GCRoot - Visual graph Whole lot easier Link to video
- 03simple.exe .sysmfix - set symbols .reload g ctrl + C load sos dump heap Address of the object - size of the object --- 327 objects Last part - stats 135 instances system.string - how much does it occupy dumpheap -type system.string (filtered on type) Pick an address of size 80 !do on its address !GCRoot on its address No references So it will be cleaned up on next GC Useful - why the reference is held? Who holds it etc
- Live process is stopped; resumed; break into debugging We controlled the execution Services running in the cloud (credit card transactions) 1000s of requests coming each second Service will be down costs millions of $$ lost Always try to get Full memory dump Otherwise becomes difficult to execute all cmds
- Automatic way vs .dump command Monitor with conditions for symptoms, problems - ADPLUS Win Error Reporting - Service based solutions version1 is getting used Diff flavors of windows Take the binaries of the product When the crash happens, anywhere Something bad happens at customer site Do you like to report this problem? Windows error reporting will create new entry Forward it to you/Download all the crash data Produce the fix Close the loop with customer Send it up to MS Register the response? - sorry for the inconvenience Take action on your issues Free of cost 3000+ companies signed up Client issues resolved as conditional maintenance
- SOS debugger extensions loads small piece of native code Asks CLR to give info to debug When live debugging versions are same CLR is present on the system Diff machines when postmortem Hot fixes, service packs, dll hell etc - pain Public symbol server published in Microsoft Contact customer to give the correct version Load it in ur system debugger will launch with -z
- 08simple.exe Null exception Enable ADPLUS adplus.vbs -crash -pn 08simpleexec.exe (start) pn for process name Crash mode Find crash dumps in location click ok start app Adplus - performance degradation - slow debuggers folder crash mode date Text file Dump files generated Shut down - we are not interested second chance exception ntsd -z path to the file .symfix .reload loadby sos mscorwks !Threads Which generated !pe
- http://msdn.microsoft.com/en-us/library/bb145915.aspx