Sunday, April 22, 2007

Find application with debug set to true using WinDbg

Actually I just found out about this about always set the debug configuration to false several months ago.
At that time we were having memory problems with our servers, asp.net worker process (aspnet_wp.exe) recycles very frequently (several times / day). Because our servers have a lots of applications, probably around 100+ applications (asp legacy + asp.net), and from our team, we only manage 2 applications at the servers (and very little information about who's the owner of the other applications), we decided to ask for M... (you know who) Support Team (MST) for help.
So we collected several dump files and sent them to the MST. The first advice we received from them was to set all the debug switch to false in the web.config for all applications, and they sent the list to us. Actually at that time, I was thinking, hhhmmm... is this possible? how can this relate to the memory problem? but in the end we followed the suggestion and we modified several hundreds of web.config files in the servers :P

For more information about this debug=true setting will cause, you can find in the Scott Guthrie's Blog : http://weblogs.asp.net/scottgu/archive/2006/04/11/Don_1920_t-run-production-ASP.NET-Applications-with-debug_3D001D20_true_1D20_-enabled.aspx

When i received the list of the applications which have debug set to true, i was kind of interested how they can get this information from the dump files, whether there's a command line for this, or they already have a script to run with the dump files. So i browsed and browsed the internet about this, and gradually i know a little bit about how to get process the dump files. But very unfortunate, i was not able to find out how to get the information about debug=true at that time, until several days ago where we got another server memory problem, so i have a chance a play around with the windbg again hehehe :P

So the steps are quite easy :
1. Load the dump files with windbg
2. Load the sos.dll (.load clr10\sos.dll)
3. Execute !FindDebugTrue
Hopla, it will list all the applications with debug set to true, quite simple rite :P
you can find more help information with !help command

Note : For a memory leak problem, there's a useful tool named Debug Diagnostic Tool from Microsoft, you can find more information in here : http://blogs.msdn.com/debugdiag/

Addition at 20071010 : You can find very good information regarding to the .Net memory debugging in Tess's Blog site (http://blogs.msdn.com/tess/default.aspx)

Sunday, April 15, 2007

.Net Reflector by Lutz Roeder

Recently, I was assigned to implement and test a tool in our company.
I was given only the application output (aspx, dll, no source code), and turned out the output has also been pre-compiled, so that means we were not even able to look at the aspx (all compiled to assemblies by .net).
The purpose of the pre-compilation is mainly for performance, but it is quite useful also when u don't want the client to modify anything to the application, even to the aspx content :P
So at that time, i only have the application output and the database file (luckly they didn't encrypt the stored procedures :P)
Of course, when doing the setup and deployment to our environment, i found a lot of things which are not being covered in the document, such as "what will happen if i click on this button", etc. They were all like in a black box, which i am as a software programmer, always want to know what is the exact process flow detail, so i will be able to answer with confident if there's any question to the application.
This is the time where the Reflector becomes very handy :P
So with the great help of the reflector, i was able to see the logic of the application and find the root cause when i was stuck with the deployment.
I remembered one time several months ago, when i have a small modification which i have to make to a tool, so i was given the source code at that time. But when i finished the modification and deployed to the production, the tool was not working anymore, whereas i was quite sure that the small modification will not cause any failure to the system. So at that time, i did a dummy debug to the application, i put console.writeline every step in the code, until i found that at this certain portion of code / function, the error always happened. So i downloaded the original dll which i have backup earlier (remember, always backup!!) and then i opened the dll with reflector, searched for that part of code / function. And there i found that the code was different compared to the source code which was passed to me :( can you imagine how frustated i will be, if i didn't use this tool? So i sent the explanation to my project manager and he's ok with that since i also showed him the comparison proof that i was given not the latest source code of the tool :) so thanks so much again to Lutz Roeder's Reflector :)

You can find the tool with other very useful tool in Lutz Roeder's site : http://www.aisto.com/roeder/dotnet/

So i always have these several tools when doing the programming, such as :
1. EditPlus : very handy for editing text, regex plus syntax templates for c#, javascript, sql, etc
2. Araxis Merge : compare files and folders, very very useful especially you have several environments (development, testing / staging, production)
3. .Net Reflector : as mentioned above.
4. SnagIt : Image capture tool, very fast and handy when doing screen captures for documentation, etc

For more very useful tools when doing the programming, there are several good articles such as :
James Avery : http://msdn.microsoft.com/msdnmag/issues/04/07/MustHaveTools/
Scott Hanselman : http://www.hanselman.com/blog/MyGrokTalkTenToolsInTenMinutes.aspx