Closed AlanCordner closed 9 months ago
Hi! Thanks for posting this issue!
That's weird, I've never seen this exception (didn't even know it existed). I will try to reproduce and fix it in the coming days/weeks.
In the meantime, could you please test the previous version - 5.1.1? I've changed some stuff related to copying the native DLLs for .NET Framework and might have broken something.
Yes, I did encounter this problem,the same.
After reverting to NuGet package v5.1.1, setting my project back to Platform target x86, and still needing to manually copy the uiohook.dll file to the output directory, I am still seeing a PInvokeStackImbalanced exception after invoking Run() or RunAsync().
To eliminate my application as being the source of the problem, I created a completely separate application that only tries to implement the SharpHook library and it also gets the PInvokeStackImbalanced exception. Solution attached. TestSharpHookLibrary-x86.zip
I've managed to fix the issue with PInvokeStackImbalance
. Once I fix the issue with copying uiohook.dll
to the output folder, I'll release a new version of SharpHook with these fixes.
SWEET! Maybe we'll get this in time to implement it for our release!
Hi @AlanCordner! Regarding project configurations and copying to the output folder - I think the project that you've shared has been misconfigured somehow. I've created an empty console project for .NET Framework 4.8.1, added SharpHook 5.2.2 and the uiohook.dll
file was copied to the output folder successfully for both x86 and x64 (and it caused PInvokeStackImbalance
for x86).
I've noticed that in your project file there were no property groups like this:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x64'">
even though these configurations could be selected from Visual Studio. Only AnyCPU
was defined in the project file. Maybe this is what caused the issue with file copying? I've added x86 and x64 to an empty project and they were added to the project file as expected.
Though I have to say that I'm not used to the old project format - I'm used to SDK-style projects and the new .NET. So, I may not know all the intricacies of working with old project files and may have missed something. If you have time, you can review the targets file for .NET Framework projects that's included in the package.
Also, a sidenote regarding AnyCPU - you shouldn't use this platform if you're using SharpHook. AnyCPU will make your executable work for both x64 and x86, but SharpHook requires uiohook.dll
which has the same bitness as the executable, and we can't have 2 uiohook DLLs in the output folder. It's fine to use AnyCPU for local testing, but distributable builds of your apps should be explicitly targeted for x64 or x86.
If you manage to create a project in which the uiohook.dll
file is copied to the output folder successfully then I'll release a new version with the fix for PInvokeStackImbalance
. If not, then I'll probably release it anyway and will try to poke around with the copying issue in the next release.
OK I will give it a try. The project I uploaded was simply a generic project created by Visual Studio 2022. I had only changed the Target Platform to x86 without altering the Configurations.
Looks like it does copy the uiohook.dll file to the output directory! Great! TestSharpHook2-x86.zip
Awesome, then I'll release a new version shortly.
I've just released version 5.2.3 which fixes this problem, so the issue can be closed.
After adding this NuGet package (v5.2.2) to my application and using the example in the Global Hooks section of the ReadMe file, I end up getting a 'PInvokeStackImbalance' exception after calling hook.RunAsync(). I am implementing this in a .NET Framework v4.8 C# DLL project with Platform Target set to x86. Regardless of the exception, the hooks work, but eventually my application crashes.
This is the entire exception text: Managed Debugging Assistant 'PInvokeStackImbalance' : 'A call to PInvoke function 'SharpHook!SharpHook.Native.UioHook::SetDispatchProc' has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature.'
A little more detail: