First of all. What is memory dump? Memory dump can be simply explained as "photo" taken of all memory consumed by our process at some point of time. Looking at this photo, we can everybody pictured in it, and blame somebody for taking too much space or jumping into the foreground scene :)
How to create memory dump?
There are some tools available, that allow you to gather memory dump being based on some rules, for example - value of some performance counters on the system.
Just in case if you do not know what "performance counter" means: there is a huge number of simple counters in your system. As soon as some event occurs, related counter is increased. For example, each time a request made to your Application Pool, counter "ASP.NET Apps / Requests Total" is increased. Tool named "perfmon" or Performance Monitor will allow you to look through all counters on the system.
But I haven't used such memory-gathering tools yet, so I make dumps simply by selecting w3wp process in Task Manager (taskmgr, Ctrl+Shift+Esc), clicking right mouse button on it and choosing Create Dump File command.
After that you have your w3wp.dmp file somewhere on the system, Task Manager will tell you where. Usually it should be right in C:\Users\username\AppData\Local\Temp folder.
Start playing with windbg magic. Next what we are going to do is open WinDBG program. (Read How to install Windbg post if you haven't installed it yet.) Take your w3wp.dmp file and simply drag&drop it to windbg window. Windbg will ask you if you want to save information for the workspace - ignore this notification for now.
Now your Windbg window looks like this:
In lower part of the window you may write commands. Which commands do you need from the beginning? This all is pretty scaring thing from the first glance, but appeared to be so easy and helpful.
When I started using windbg, I used to write all needed commands to separate file, named it "WinDBG bible.txt" and just run a bunch of commands each time when investigating new dump. Note: you may put several commands in one time to the command window. Here are the contents of my WinDBG bible:
****first bible chapter****
!sym noisy
.symfix c:\symbols
.loadby sos mscorwks (or clr)
.load sosex
.reload -f
!sym quiet
!sym noisy
.symfix c:\symbols
.loadby sos mscorwks (or clr)
.load sosex
.reload -f
!sym quiet
You may also store these commands as your own bible :) and it will grow gradually as soon as you learn some new things.
If you've got any errors running commands above, read Issues on opening dumps post.
If you are in a hurry, you may simply jump to next chapter. But if you have some leisure time, let's go through all commands and find out what each of them means.
!sym noisy - this command allows you to see all operations performed with symbols by windbg.
"Symbol" is a short name for Debug symbols, Symbolic information etc. This information allows our debugger to understand, which piece of our program code produces given piece of machine code. Symbols for concrete projects are stored in .pdb files - good acquaintance, huh?
.symfix c:\symbols - this command will tell debugger to use "c:\symbols" folder when looking for debug symbols. You may not have this folder from the beginning, but it will be created as soon as you start loading symbols. We'll be loading symbols couple of paragraphs later :)
.loadby sos mscorwks (or clr)
.load sosex
Commands "load" and "loadby" are used to add some modules, also called extensions, to your current debugging space. Module is a file containing commands for our windbg. There are plenty of them, including some custom modules. You may also write your own modules and load them in absolutely same manner.
Difference between load and loadby is simple: when "load" just loads a module, "loadby" loads first module from the same folder where second module (already loaded) is located.
If dump was created of process that used .NET 4.0 version, you should use .loadby sos clr
If dump was created of process that used .NET 2.0 version, you should use .loadby sos mscorwks
Couple of words about modules above: sos is a useful dll for debugging, and it is provided with .NET. Sosex is another useful extension that may be downloaded here: sosex 32 bit, sosex 64 bit. About issues that you may run into when loading dlls, you may read in my later post.
.reload -f
New thing. Command with parameter, yeeey! Command "reload" will show your debugger that it can load symbols if it needs them from current symbol place. Remember our c:\symbols? This is one of places to look for symbols. Second one by default is online Microsoft symbol storage.
But what is our parameter for? -f (or /f) tells debugger to load symbols right away. Here is a place where symbols will be downloaded from online storage and put to c:\symbols for future usage. If you run this command for the first time, it will take some time to finish. Keep patience! next times it will be much faster, when your symbols cache is filled with already downloaded symbols.
!sym quiet
Gasp. We are at the end of our first bible chapter. "sym quiet", on the contrary to "sym noisy", disables symbols information, that we do not need for future work.
Credits for images:
No comments:
Post a Comment