Browse by Tags
All Tags »
Tools (
RSS)
I had to analyze a memory leak the other day and all I was provided by the customer was a couple of dump files from two points in the application’s lifetime—one dump immediately after initialization, and another dump after the memory leak has accumulated. This is an ideal scenario: now “all it takes” is to compare the two dumps and see which objects are “growing” in memory. That’s, of course, if the leak is actually in managed objects—which isn’t always the case (and VMMap is your friend here )....
Yesterday I delivered a 3-hour session on production debugging at the Castra Center in Haifa. The room was set in the middle of a beautiful art gallery, and the projector was playing my slides on a wall surrounded by paintings. Amidst this cozy atmosphere I was talking about some nasty bugs and how to discover them in a production environment. Source: Ezy.co.il Among the topics covered: Using IntelliTrace in production —we saw an undocumented way to launch IntelliTrace from the command line , capture...
In our C++ Debugging course , there are several scenarios which require WinDbg and cannot be completed in Visual Studio. They all rely on advanced extension commands available in WinDbg. Some examples: Tracing opened and closed handles with the !htrace command Viewing native heap information with the !heap command Loading and executing code in the debuggee process with the SDbgExt extension commands !loaddll , !remotecall Inspecting handles to synchronization objects with the !handle command The...
A dream is coming true. A dream where all the debugging you’ll ever do on your developer box is going to be in a single tool – Visual Studio. In a later post, I will discuss device driver development in Visual Studio 11, which is another dream come true. For now, let’s take a look at how Visual Studio can open kernel crash dumps and perform crash analysis with all the comfy tool windows and UI that we know and love. To perform kernel crash analysis in Visual Studio 11, you will need to install the...
If you’re looking for a very simple profiler that will give you a general idea how CPU utilization is distributed in your system, look no further than the latest version of Process Monitor . Under Tools | Profiling Events, you can enable stack trace collection every second or every 100ms for all running processes. The profiling events have an execution stack, exactly like any other event in Process Monitor, and you can gain a quick impression where CPU time is spent and which call stacks are responsible...
We have already seen VMMap as a tool for inspecting memory utilization and the layout of a process’ virtual address space. The latest VMMap version (rush to download!) ships with a memory allocation profiler for VirtualAlloc() and HeapAlloc() calls. Additionally, the tool can display the allocating call stack for every heap block. Sounds interesting? Here’s how to use it. You launch VMMap, and instead of inspecting an existing process, you tell it to launch and trace another process. (It uses Microsoft...
Suppose you want a more detailed drill-down into your application's GC heap usage. For example, you want to see if there's fragmentation going on, or if there are lots of large objects, or if the XMLDocument objects you allocated a while ago are finally gone. This is something you can do with the CLR Profiler , another free Microsoft tool that supports memory allocation profiling as well as visualizing the managed heap at the individual object level. Unfortunately, running the application...
Synopsis: CLR Stack Explorer obtains reliable call stacks of managed processes, supports any combination of 32-bit/64-bit and CLR2/CLR4. UPDATE [2011/7/20]: If you downloaded CLR Stack Explorer from the above link and are using a recent Windows version, you need to Unblock all the .exe files (right-click, Properties, Unblock) for the tool to run correctly. I have just updated the download location with a self-extracting executable which should solve this problem. I’m happy to announce that CLR Stack...
How can you map the memory usage of your .NET application? We'll start with VMMap , a free Sysinternals tool that visualizes your process' virtual address space. Below is VMMap's output for an example process: The type statistics give you a detailed overview of how memory usage is distributed – there are 240MB of DLLs, 50MB of managed heaps (of which only 10MB are committed), etc. In the bottom details view you can see each individual address range on the heap, including its type, size...
I hope y’all are using Sysinternals Process Explorer on a daily basis as your Task Manager replacement. It’s a really awesome tool with lots of functionality; among my favorites are: Seeing all the handles and DLLs opened by the process in the bottom pane Monitoring important .NET performance counters through the .NET Performance tab Viewing a list of the process’ threads and their respective call stacks This last feature, however, has a minor drawback: it doesn’t display managed call stacks properly...
A year and a half ago I touched on the subject of debugging process startup , such as the startup of Windows Services, using the GFlags utility (the ImageFileExecutionOptions registry key). The general idea is to rely on the Windows loader to launch a debugger instead of the debugged process, and trace your way through the process startup code. Unfortunately, this relies on the debugged process to run in the same session as you—otherwise, you won’t be able to actually see the debugger. Starting from...
This is where we are through the series: Calling a function Configuring breakpoints Setting multiple breakpoints at once Memory access breakpoints Memory access breakpoints, revisited Conditional breakpoints [this post] Tracing execution Execution control Displaying data, including STL collections Runtime application checking Miscellaneous commands Today’s post is about configuring conditional breakpoints. Finally, this is one area where the Windows tools have feature parity with DBX, at least as...
This is where we are through the series: Calling a function Configuring breakpoints Setting multiple breakpoints at once Memory access breakpoints (NEW) Memory access breakpoints, revisited [this post] Conditional breakpoints Tracing execution Execution control Displaying data, including STL collections Runtime application checking Miscellaneous commands Today’s post revisits the concept of memory access breakpoints. Before I started this series, I wrote a post showing a proof of concept technique...
This is where we are through the series: Calling a function Configuring breakpoints Setting multiple breakpoints at once [this post] Memory access breakpoints Conditional breakpoints Tracing execution Execution control Displaying data, including STL collections Runtime application checking Miscellaneous commands Today’s post is about configuring multiple breakpoints at once in a convenient fashion. If you’re used to setting your breakpoints one at a time, you may find it very convenient to reason...
I’ve recently had an enlightening experience teaching a C++ Debugging course to a group of developers who are transitioning from a Solaris environment to Windows and Visual Studio. This hasn’t been an easy transition for them, and the course wasn’t easy to teach—specifically, because one of the most discussed topics was feature parity between DBX (the debugger of choice for C++ applications on Solaris) and Visual Studio. Fortunately, the course focuses on WinDbg, which has alternatives to several...
More Posts
Next page »