How to add that missing logging code to your application after it's in the wild

Logging Woes

Logging is one of those aspects of coding that has always bothered me. It's partly because I hate taking the time to write it, and partly because it can really clutter up otherwise clear code. But mostly it's because anytime I've looked through a log file, trying to figure out why the whozit widget is throwing a null reference exception in the whatzit routine, I end up spending what seems like an eternity sifting through gazillions of mind numbing lines of log files, most of which have no bearing on the issue at hand. And, when I do narrow my hunt down to the appropriate part of the file, I find another surprise. The function I really need info about either seems to be missing all together, or the piece of info that I need isn't included in the logging for that function. Now, what do I do? Well, first, I curse the programmer who wrote this routine… until I realize it was me. Great! Now what? If the bug in question is part of some "live" code, it's not really feasible to quickly code in the logging code that I need, rebuild, and reinstall (or at least not very smart). Depending on the scenario, I may be able to attach a debugger, but that's not always realistic either. I can't really add a break point that stops all code execution in a high traffic web site. So, what now?

A Solution

Logger is an application designed to solve this very issue. Install, select the application you would like to log, select the functions you'd like to log, and start logging. Logger will now generate your missing log info for you. No recompile needed. I can now find the bug (duh, what was I thinking when I wrote that code anyway?), fix it, and still make it home before the kids drive my wife crazy.

How it Works

Logger uses a technique known as "IL Rewriting" to dynamically insert logging code into applications at run time. IL rewriting uses the .NET Profiling API to grab code just before it's JITed. It then alters the IL to include the needed logging code before sending it back on its merry way to the .NET runtime. This technique has the advantage of having a very small performance footprint while at the same time not ever actually altering your binary files.

For a more technical discussion on how this works, see my previous article (from a very rough draft of this application) at Really Easy Logging using IL Rewriting and the .NET Profiling API. Also, check out software.herbrandson.com to watch for updates.

You must Sign In to use this message board.


Per page

Can not log vb.net windows program.
charliewhit

8:47 15 Apr '08

I started up your logger, entered Windows file type and the exec path and name. Press the start. The logger started the program I ran the program but the only thing in the window or the log file is <Data>. Do you know what I might be doing wrong?
Sign In·View Thread·PermaLink

Re: Can not log vb.net windows program.
Herbrandson

14:14 15 Apr '08

Can you provide me with some more information about your application/environment? What version of .net was the application written? What OS are you using?
Sign In·View Thread·PermaLink

Re: Can not log vb.net windows program.
charliewhit

4:52 16 Apr '08

I'm using .net 2.0, windows xp, and vs2005.
Sign In·View Thread·PermaLink

Re: Can not log vb.net windows program.
Herbrandson

5:42 21 Apr '08

Hmmm. That's really strange. Does it work for any other application on your computer? Has the application you're running it against been complied using NGen? Is there any chance you could send me a small sample applications?
Sign In·View Thread·PermaLink

Re: Can not log vb.net windows program.
charliewhit

5:48 23 Apr '08

No, it does not work for other applications on my computer. My applications have not been compiled using NGen. My appliction is very large 13mb deployment, with 30 forms hundreds of controls and over 60,000 lines of vb.net code. I also built your test application and then tried it in the logger but it also runs the application but nothing shows in the window. Anyway thanks for the help in trying to figure it out.

Error
Bill Warner

3:57 14 Apr '08

I get a compile error: Error 1 fatal error C1192: #using failed on 'c:\program files\nunit 2.4\bin\nunit.framework.dll' c:\Users\bcwarner\Desktop\Logger\Logger.Profiler.UnitTests\Stdafx.cpp 1 I don't have NUnit installed and I don't really want to either.
Sign In·View Thread·PermaLink

Re: Error
Herbrandson

7:39 14 Apr '08

if you don't have nunit, you'll need to either remove the unit testing projects from the solution, or else set the soutions properties->Configuration Properties so that it never attempts to build any of the unit testing projects.
Sign In·View Thread·PermaLink

Scary...
supercat9

14:30 10 Apr '08

I wonder how many applications handle sensitive information in a fashion that could easily be compromised by this sort of program. To be sure, it's not the logger that's scary, but rather the design of .NET that would make such attacks comparatively easy.

I would think that most code that's released to the wild should have some measure of obfuscation or other techniques applied that would make this sort of logging much more difficult. Is that not the case?

"...and still make it home before the kids drive my wife crazy."
Ashaman

7:35 10 Apr '08

LOL. I'm sold!
Sign In·View Thread·PermaLink

Excellent
merlin981

6:52 2 Apr '08

Great idea! Definitely will be helpful for future debugging. Do you have an example of how to use this for a website? 5 from me ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Rhabot - World of Warcraft Bot Uber RPGE - Free Private World of Warcraft Server Make long URLs short with NeatURL.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sign In·View Thread·PermaLink

Re: Excellent
Herbrandson

7:28 2 Apr '08

I'm really glad you like it. I hope it ends up being helpful for you. Debugging web apps is fairly simple. Go to File->Application Type and select "Web". Then start the profiler (File->Start Profiling). At that point you will be profiling all local web applications. Currently, debugging of web apps is only supported for local web applications (i.e. no remote debugging).
Sign In·View Thread·PermaLink

Great stuff here
sefstrat

13:23 1 Apr '08

I guess people have voted this down due to the lack of explanation in the article, but if you download the bits you will find some quite lovely stuff. I have been doing similar techniques with AOP (PostSharp) but this technique is even less invasive, and better for certain scenarios I think. Thanks Herbrandson =)
Sign In·View Thread·PermaLink

Both download links contain same deliverable.
c-sharp

16:06 31 Mar '08

The msi package is contained in the SRC link as a compressed file. Was this intentional? I expected a link labeled with source in the title would contain sources. The sources from the earlier article are dated January 2007. I'm interested in seeing your May 2007 sources and seeing the improvements. Thanks!
Sign In·View Thread·PermaLink

Re: Both download links contain same deliverable.
Herbrandson

6:26 1 Apr '08

Thanks for that It should be fixed now. I hope it's helpful to you. I really enjoyed working on it.
Sign In·View Thread·PermaLink

Lose the extra baggage
rfmobile

5:23 7 May '07

Two points: 1. You've got unwanted baggage in your source ZIP file. It shouldn't be 9 megs. There's a folder full of temporary files in \Logger\Logger.Profiler\Debug. 2. You may want to explain to readers why the article - which covers .NET applications - also shows up under C++. I gave it a 5 but some folks don't agree.
Sign In·View Thread·PermaLink

Re: Lose the extra baggage
Herbrandson

6:58 7 May '07

Thank you so much for the feedback.
Sign In·View Thread·PermaLink