This blog’s main aim is to discuss .NET application issues resulted by not following a code practice. One of the best ways to understand the theory is to learn it in the practical way. So I will attempt to simulate the issue on a demo app, debug the issue and discuss the solution.
Let’s get
familiarize with the tool Windbg that helps to troubleshoot issues.
Windbg
Windbg is a
tool for analyzing the user dumps (created while application crash /hang) or
kernel dumps. To give complete description about its features and usages that could make
the post very long. Alternatively, I choose a path to explain from the
developer point of view. (i.e) The readers can attach their application with
Windbg and troubleshoot the issues. At
the same time, all the commands I use to troubleshoot the live application can
be used while doing an offline dump analysis.
- First and foremost thing is to download the Windbg. Use this link where
you would see a section “standalone debugging tools for windows (Windbg). Separate links for windows 8.1 and Vista, xp.
Download from this link with respect to your
OS.
- While installation, select “Debugging tools for windows”
1. After installation , you can see Windbg at following locations (figure below)
a) 32 bit - C:\Program Files (x86)\Windows
Kits\8.1\Debuggers\x86
b) 64 bit - C:\Program Files
(x86)\Windows Kits\8.1\Debuggers\x64
Since we have two (32 and 64) bit versions of Windbg which one should I use to debug my application is a question that can rise. In user-mode (application) debugging matching the bitness of the application is an easily remembering option to choose the debugger. i.e. if the application you wish to debug is 32 bit ,use x86 version of Windbg or if Application is 64 bit use 64 bit version of debugger.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff539099%28v=vs.85%29.aspx
In the demo application, I use a x86 debugger to debug a 32 bit application.
3. Run a debugger from the folder (as shown above) or you can create short cut menu to desktop if using frequently.
4. Open the File menu, select “Symbol file path”. You would see a dialog box like below right.
5. For the first time user who installs Windbg, this dialog box would be empty. We have to fill the windows symbol path.
This is an important step in configuring the Windbg for debugging. We require Windows public debugging symbols to efficiently debug a application. Microsoft has provided a symbol server that has all necessary public debug files and its link is at
Applying this link to the symbol path folder would
work but loading the symbols from server
Make debugging slow. So we would also need a local folder that has
these symbols. It helps to debug application offline and also faster debugging.
For example, I have set
the debug file path as below (keeping both local path and online symbol server
link). The red line indicate local folder contain the Microsoft public symbols.
SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
OK. Then the next
question would be that how do we fill the public symbol files to our local
folder?
The answer is that once
we set the local path, Windbg downloads the symbols from server to local folder
in the first operation of attaching the application or dump loading.
Let’s see the steps how
we accomplish this.,
a. Create
a local folder in c or d drive
b. Replace
the red lines given above with your local folder path and then copy the entire
line and paste in the dialog box.
Always keep
your local folder first then the online symbol server path. Then the debugger
will take pdb files from the local folder first and if not available take from
online.
If your
application has a pdb file and you would like to place in debugging path then
link your app pdb files like black lines below.
C:\MyProject \Myapp.pdb;SRV*c:\localsymbols*http://msdl.microsoft.com/download/symbols
For more details visit
this link about symbol file and setting the path.
6. Now let’s see how to attach the process to Windbg for live debugging. For that I am running the demo application. ( Reader can run any of his application)
7. Open the file menu “attach the process” . Then from the dialog box select the process name
8. For the first time , this operation may take some time because public pdb files are downloading from Microsoft symbol server to your local symbol path. Next time when you do attach process operation of any process, attaching to debugger will be faster.
9. Windbg is still not ready to debug a .NET application.
By default, Windbg is a debugger for unmanaged applications. To promote
Windbg eligible for debugging .NET applications, user has to load an important
library.
After attaching the .NET process or
user loaded a .NET application dump file to Windbg, this is the first command
to execute in the Windbg command line.
(If the application dump or attaching process is compiled with .NET 4.0
or later versions)
Use,
.loadby
sos clr
(If the application is compiled with prior to .NET 4.0 versions [Ex:
.NET 2.x])
Use,
.loadby sos mscorwks
10. I typed .loadby sos clr command in the Windbg Command line and apply Enter. (I am using an application
compiled with .NET 4.5) (figure below)
11. By now we are ready to debug a .NET application.
For live debugging (changing the control
between Debugger and application)
In this
blog, when we discuss a scenario and troubleshoot the same with Windbg, we use
live debugging with the application. But the commands we use to troubleshoot
will be very relevant in postmortem dump analysis also. So users can try them
when they get dump files.
But
currently I am discussing a feature which is relevant only to live debugging.
When you
attach a running process (discussed above), or open executable with the debugger,
the debugger gets control of the application immediately. This means all
threads in the application become suspended state. If it is GUI, user cannot
act on it. So when user executes any
command on the Windbg the result will show the state of the application just
before it became suspended.
To give an
example.
Let’s say application has a button to create
10 objects. User applies this button once. Then user decides to attach the
process with Windbg and he accomplishes by the steps we discuss earlier.
Now, the
process attached so debugger get the control over the application. User executes a command to fetch the number
of objects he created. He will get 10. That is the state of the application
before it is suspended.
The application state denotes the current status
of the application (like value of process variables, heap memory content,
number of threads and their stack positions) of that moment of time. If an
application dump is taken, the dump will consist of the current state of
application at the time of collecting the dump.
Giving
control back the application
As we have
discussed with the previous example, user executed as many commands to check
the state of application, then he decides to run application for some more
time. Since the debugger has the control of the application, it is a suspended
state now. We want to give control back
to the application.
User can do
it by
Type ‘g’ in Windbg command
prompt and enter (figure below)
Or use Debug menu ==> Go sub menu apply or use f5 key
We can see
“Debuggee is running...” in the prompt after this.
Now
Application has full control, debugger is like suspended you cannot type
commands in debugger.
User can do
anything on the process just like normal using.
For the example, let’s consider he again applied same button to create
10 more objects. He now wants to get the debugger get the control again so that
he can see how many objects he created.
How to
get control back from application to debugger again
Remember
last time when debugger gets the control, the user was attaching the process or
open the process with debugger. Neither is possible here because the process is
already attached.
We can do
this by,
Go to debug menu ==> apply Break sub menu (below figure)
Or apply Ctrl +Break in keyboard.
Now the
application is again suspended. Windbg got control back of the application. So
you can type debug commands on the prompt to get results.
The below figure gives a snapshot of control transfer .
Control transfer
between debugger and application
