We Keep Coding

Certain applications stopping all attempts at getting keystrokes

So for work they have me writing a simple program for tracking employee efficiency within their workflow (things like using keyboard shortcuts, window locations, how often they need to look stuff up). Currently we want to track the 'F5' key (brings up next work item), 'Alt+Tab' (changes windows), 'Ctrl+V' (paste), but may be expanded as they find there are more shortcuts or things they want to track.
Note We are on windows 7, and using c# to write the tracking program.
In order to do this I wrote a low-level hooking library to capture the chosen keystrokes, send off the message down the hook chain and then add a note to a db that the key was used. The hooking library works great in All web browsers and most normal programs (except we don't actually care about browsers so we ignore everything done in them).
The issue is that the application that they use for managing their work (the program we actually care about tracking) some how stops our hooks from hooking and I do not know how. The application in question is TA2000 Desktop.
I know that with the way hooks work if an application fails to call callnexthook() within the LowLevelHooksTimeout period that the system kills the hook. So figuring maybe TA2000 was just taking to long or something I bumped up the timeout to 30 seconds (yes I know this is significantly more time than a hook should even need) but this had no effect.
The next thing I tried was implementing a tracking system based on the Raw Input API. And once again the tracking tracks on browsers, Microsoft office, notepad, and all the other programs I opened except it still is unable to track key press in TA2000. This really surprised me because according to MSDN
An application does not have to detect or open the input device.
An application gets the data directly from the device, and processes the data for its needs
An application can distinguish the source of the input even if it is from the same type of device. For example, two mouse devices.
So if I am getting the data directly from the device how is TA2000 preventing me from also getting the key press?
The last thing I could think of trying was using dll injection on TA2000 to inject a hook. However this method seems risky because It is something neither I nor any other developer here has any experience with and the application we want to track is operation critical so messing it up can not happen and injecting code into its memory space seems like a good way to mess things up.
If someone could explain how TA2000 could be stopping me from tracking keystrokes and how to beat it or point me in a good direction I would be very appreciative.
p.s. This felt questionable as an appropriate question for the SO format but it also feels specific enough to be a viable question. So sorry if this is not a good question but I am at my wits end with this.

This financial software package is secured to prevent snooping. Running the key logging software as Administrator appears to fix this specific problem. The security was identified initially using Sysinternals' Process Explorer, which is a great starting point for unexpected problems like this.

Tracing Windows API calls over all processes

I am trying to write an application that will make statics over the usage of certain functions and DLLs of Windows API over all the running processes (as well as ones that are created after my application has started).
After searching the internet I have found several tools that may help - such as WinAPIOverride, EasyHook and ProcMon, which use different kind of hooks. Unfortunately, it seems for me that they are not able to make exactly what I need: WinAPIOverride, EasyHook can hook only certain processes that one should choose, and ProcMon doesn't have an interface that I can use to trace calls of API that I need.
I also wonder if this kind of hooking could interface with a Python code, or at least C# environment.
I would like to hear some suggestions for how this could be done.

This article may not be the holy grail for what you're trying to do but certainly will get you further in your quest:
http://www.codeproject.com/Articles/2082/API-hooking-revealed
I'm not 100% sure that is the article I was thinking of for tapping into ProcMon.. After further research I'm pretty sure it was EasyHook I was thinking about: http://www.codeproject.com/Articles/27637/EasyHook-The-reinvention-of-Windows-API-hooking
Also ETW might be another avenue to investigate: http://www.codeproject.com/Articles/570690/Application-Analysis-with-Event-Tracing-for-Window

Why would you override wndproc

I have been looking around and haven't really seen much information on why someone would override wndproc to handle messages.
So I wondering:
Why do it?
When to do it?
Whats its general purpose in C#?
I have tried using it when seeing a serial COM plugged and unplugged from the computer, but I felt like I managed better reliance on methods I have created myself.
Other messages I see are for key-presses, cursor settings, and other various actions. This being said most of these things already have built in methods in c# libraries. So again I am back to my three main questions. Any information, opinions, examples, etc would be awesome.

WndProc() is very, very core to the way a Windows window works. It is a managed wrapper method around the window procedure, a function that used to be written in C in the olden days. It is the way you customize the behavior of a window, making it respond differently to notifications generated by the operating system or other programs.
You don't normally have a need to override it, the WndProc() method in the base class handles most of the basic notifications. Turning them into friendly .NET events, like Click etc. But that isn't complete, either because the notification is too obscure or necessarily so because it cannot know anything about the messages used by a custom window. In which case you can fall back on overriding WndProc() to intercept the message. Best example I can think of is creating a borderless window to draw a custom window frame and still giving the window normal behavior. Most easily done by intercepting messages like WM_NCHITTEST, not wrapped by .NET.
Truly grokking WndProc() requires reading Petzold's seminal book "Programming Windows". Perhaps not that easy to grasp anymore today, it does assume a basic understanding of the C language. Which was the language targeted by the winapi 30 years ago, object oriented languages were not widely used or available back then. That also otherwise explains why writing code inside WndProc() is fairly painful, there is very little abstraction and you can't really ignore pointers.
Microsoft did make an effort to retire it, starting with Windows 8 and the WinRT api. Not exactly a slamdunk success, maybe Windows 10 will give it some traction. The foundational technology that makes WinRT work under the hood is COM, a big step up from C because it can support an object model. Albeit it well hidden in the friendly language projections, COM programming is something most programmers will try to avoid :)

I have found that it is useful for processing keypress events for a UserControl.
The keypress, keyDown, or KeyUp events are quite finicky at responding from a UserControl (even with KeyPreview set to true and all that). I found that if I override WndProc() I have much more reliability of the Control processing the command.

Controlling WPF in native interop

I'm writing an application in native code and wish to use WPF for a user-interface library. Now, I've got the interoperation down relatively easily, but ultimately, I'm trying to write a native app, with WPF as a library, not a WPF app with a few native extensions. That said, I'm looking for an interoperation solution with certain qualities that I just can't seem to find in any examples.
Firstly, I definitely want to write my own main loop. I might perform arbitrary actions in native code and I want the ability to poll, for example, in each iteration. My application is definitely not a "sleep until you click something" application.
Secondly, I want the ability to control WPF. I want to say when WPF processes input. I want to say when it renders. I want it to make me a sammich, when I say so. This is one of the bigger problems that I have. Surely these methods must exist inside WPF, they're just not exposed anywhere that I can find them.
I've been looking into CLR hosting, but it doesn't seem to have a kind of, "Go until finished" thing that I'm looking for. Even if I cracked open a critical section or something, even from managed code there's no way to make WPF do what you want.

If I understand your question correctly, it sounds like you want to write your own main loop/message pump for WPF. I remember reading about this in a message thread a while back. It's not a full answer, but I wonder if it might point you in the right direction.
Subject: Game loops in WPF?
wondering how easy it would be to write a custom "game loop" within the WPF framework. By game loop, I mean pumping my own events on a custom Dispatcher so I can control the framerate of my app.
Answer:
You can write your own message pump. Just don't call Dispatcher.Run. You need to pump messages, and you need to call ComponentDispatcher.RaiseThreadMessage as appropriate. Use reflector to see what Dispatcher.PushFrame does.
Of course, this still may not give you what you want for a "game loop"...
Source: http://blogs.msdn.com/b/jaimer/archive/2009/06/29/wpf-discussions-090626.aspx

I think you want to look at HwndSource. It hosts a WPF GUI as a win32 control. Its all a bit tricky though and you're probably better off writing a plain WPF .net GUI app and using it to drive your native code using some form of interop. MS really didn't think of this kind of migration approach (reusing your existing code and slapping a new GUI on top) preferring to make us all rewrite all our code.
There are plenty of examples around the web. Good luck.
PS.
of course you could try the current 'gold standard' in native GUIs - Qt.

How to be notified a program execution and termination in c#?

is there a way to be notified when a program is executed or terminated by a user in c#? I am talking about all the programs that a user can execute, not just a certain program. I would like to be notified whenever a user execute .exe files.
I can't even think of a keyword to google.
any suggestions would be appreciated!

The closest thing I know of would be to use Hooks.
You can use WH_SHELL Hooks to receive notification any time a new, non-owned, top level window is created or destroyed by the system. This isn't the same as a process, but it's pretty close in many cases, and potentially more useful in others (since it'd show a new word document window opening after one was already opened, even though they're using a shared process).
You might be able to combine that with EnumProcess to check to see if the process list has changed. This would work for tracking windows applications (but not services or console-based applications running in an existing console).

In Microsoft .NET Framework 3.5, you can get a list of Processes and register for the Process.Exited event. I suppose someone could implement a polling system in which they continually looked for new Processes, but that doesn't really notify you when something launches.
-- EDIT --
You might find this article useful. If you're willing to write a kernel mode driver, you can control every process start and finish.
Now, if you really want to get wild, you can hook into Microsoft Detours. Here is an interesting article about that.