Retrofitting auditing / logging to an application not laid out for it is the same as writing the tests for a program / module after the code has been written - it's tedious if it works at all.

My best tip is that you either rewrite your application such that every input widget allows a "tee filter" to log all the input to a logging facility, which will allow fine grained auditing, or that you use a hardware capture device to connect between the keyboard and the main computer unit (or a specialized device driver that does "tee" the keyboard input to a logging facility).

If you have the luxury of being able to redesign your application, about the only things you need to change are your input widgets in such a way that they support logging and your data entry facilities ("dialogs", "windows") as well, as you will only want to log committed transactions (the user pressed the "OK" button instead of the "Cancel" button or the "Dismiss" button). Of course, this will make your application also much more testable, as you will invariably not only add a "logging" filter but also an "input filter" which will allow you to replay past transactions - which is what testing is all about.

Those ideas were not made up by me but I stole them from http://www.extremeprogramming.org - look into the "regression test" section(s). Even though XP looks and sounds like just another buzzword (have a look at the ads in the Dr. Dobb's Journal), it has some ideas that just make sense - maybe you can adapt some of them.