Howdy,

I'm writing a program that records user actions such as keypreses, mouse position, mouse clicks and then plays it back. I've got the mouse to fully work, but something is wrong with the keypress recording.

I've set a low-level key hook to capture any key presses outside of the form. Now when I implement this hook in a test project, it works fine. However, when I implement it in this project, it fails and throws this exception as soon as I hit a key:

A callback was made on a garbage collected delegate of type
 'AutoMagic!Utilities.globalKeyboardHook+keyboardHookProc::Invoke'. This may cause 
application crashes, corruption and data loss. When passing delegates to unmanaged 
code, they must be kept alive by the managed application until it is guaranteed 
that they will never be called.

What? This hook works fine in other small, test, applications I wrote! Maybe some file stream or something is interfering?

Help

Example? Sorry, still confused

If you don't keep the delegate around, it will be garbage collected, since you're dealing with unmanaged code.

With garbage collection, things get deallocated when there are no references to them. .NET can't see into unmanaged code, so it doesn't know that unmanaged code is still referencing the delegate, so it destroys it. The solution is to make a reference to it, yourself, for as long as the delegate is in use by the unmanaged code, so it doesn't get destroyed.

I get the feeling none of us got through to you.

I'll take one more shot...

In unmanaged code, you are responsible for explicitly allocating and deallocating objects. So, in C style, you might see:

OBJ *ptr = (OBJ *)malloc(sizeof(OBJ));
// use ptr for stuff
free(ptr);

This pattern appears prominently in Allegro, it being a pure-C library. For example, you must explicitly call create_bitmap to get hold of a valid BITMAP * in the first place, and later call release_bitmap to make sure that the memory is returned to the system.

In managed code, there is garbage collection. That means that you don't explicitly allocate or deallocate memory. I'm not up on .NET semantics because I don't use it, but the point is that you explicitly instantiate objects so as to set their working parameters (which will look a lot like create_bitmap) but subsequently you don't need to worry about deallocating the memory (ie, there is nothing equivalent to release_bitmap). The .NET runtime deals with that for you — it uses a bunch of techniques that you don't need to care about to determine when your program is in such a state that it can never access a particular object again. At some point after that, it will deallocate the object.

Any attempt to access a deallocated object has an undefined result (at best, you'll read the old values because the memory hasn't been reused, at worst your program will crash or be forcibly terminated by the OS). You should never attempt to access a deallocated object.

The various techniques that .NET uses for garbage collection can be applied only within managed code. Once you pass a pointer to something in managed code to some unmanaged code, it has no way to figure out when the unmanaged code is finished with the object. All it can do is to continue to apply the rules for the managed area.

That means that any object that originates in the managed code will be deallocated when the managed code no longer retains a pointer to it.

If the unmanaged code tries to access the object after it has been deallocated, the result will be undefined.

You are creating an object in managed code, passing it to unmanaged code, then putting yourself in a position whereby it may be automatically deallocated.

If you keep a pointer to that object in your managed code — even if you don't use it — then the managed runtime will spot that you want to keep the object in memory and will not deallocate it, so everything will operate correctly.

It's a tiny bit messy, but it's an unavoidable problem in the transition from unmanaged to managed code. The only way to avoid having to worry about things like this is to use managed code exclusively.

@Harte:

Aha! Much easier to understand when you compare it with Allegro examples! Thanx you.