Question

I’m trying to send a key to a window with PostMessage. But after my program sends the key, I get an error in the debugging window.

The error that comes is this one: PInvoke stack imbalance detected.

I think I’m calling the DLL wrong:

[DllImport("user32.dll")]
public static extern bool PostMessage(IntPtr hWnd, uint Msg, int wParam, Int64 lParam);

Answer 1

The error that comes is this one: PInvoke stack imbalance detected.

Just a bit of background behind what you see, Ria’s answer will solve your problem. This is not actually an error, it is a warning that’s produced by an MDA. A Managed Debugging Assistant, it is extra code that’s added to the CLR, the framework and the debugger to keep an eye on unintended runtime problems and activated when you run with a debugger. You can have a look at what MDAs are available, use Debug + Exceptions and expand the “Managed Debugging Assistants” node to see them. A lot of them are disabled by default because they tend to be noisy or tend to generate false warnings or already generate an exception later. Do note that the pInvokeStackImbalance MDA isn’t actually listed there, it is special because it can’t be turned off.

The complete list of MDAs is documented here. The description of pInvokeStackImbalance contains a decent description of the cause of the problem it detects:

The managed signature of the platform invoke call might not match the unmanaged signature of the method being called. This mismatch can be caused by the managed signature not declaring the correct number of parameters or not specifying the appropriate size for the parameters. The MDA can also activate because the calling convention, possibly specified by the DllImportAttribute attribute, does not match the unmanaged calling convention.

I highlighted the true reason in your case, your lParam argument has the wrong type. The wParam type is wrong too but happens to have the right size by accident. Those kind of accidents tend to byte when your code runs on a 64-bit operating system.

Although this is only a warning, and your code appears to be running just fine when you ignore it and continue running, a stack imbalance is a very serious kind of runtime problem. The failure mode is unpredictable, it might run just fine in the Debug build but bomb your program with an inscrutable exception in the Release build. The specific problem here is that you push too much data on the stack when you call the method and Windows doesn’t pop enough off the stack. Which can bomb your program with this site’s name when you call it often enough. The problem tends to be hidden because returning from a C# method re-balances the stack. All bets are off when in Release mode the jitter optimizer inlines the method. Which it only does when you don’t have a debugger attached, the worst kind of bug to try to diagnose.

Finding the right pinvoke declaration is not particularly easy. There is more than one way to declare them and you’ll often find intentional “lies” about a declaration to make a function easier to pinvoke. The pinvoke.net site is a fairly decent source, albeit that it tends to over-specify declarations. Like in Ria’s example, the [return:] attribute is unnecessary since that is already the default marshaling for a bool. And HandleRef doesn’t make much sense when you don’t own the window handle. But it will work just fine. Another fairly decent source is the Pinvoke Interop Assistant, a tool you can find here. It produces auto-generated declarations, they are not pretty.

Last but not least, you can’t use PostMessage to reliably poke keystrokes into the window of another process. You’ll run into trouble when you need the keyboard state of the process to be accurate, particularly the Shift, Alt and Ctrl keys. And dead keys like Alt+Gr present on keyboards with a different layout, particularly for languages that have a lot of diacritics or a large alphabet. To poke typing keys you should favor WM_CHAR instead.