PInvokeStackImbalance and GetWindowModuleFileName
btysg...@gmail.com
I'm not quite sure what's going on, but, here goes: I have a project
in VB.NET 2005 going. I make a call to an unmanaged function. I'm
using the declaration below:
Private Declare Function GetWindowModuleFileName Lib "user32.dll"
Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef
pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
Now, elsewhere, I have a call that looks like this:
Dim Str As String
Dim StrLen As Integer
StrLen = 300
Str = Space(StrLen)
StrLen = GetWindowModuleFileName(iHwnd, Str, StrLen)
...where iHwnd is passed in as a parameter. I do know that in each
case iHwnd is a valid handle.
Here's the weird part: I get a PInvokeStackImbalance Exception
complaining about a probable mismatch in the function's signature.
The thing is, this code is only called when I hit a certain key. Now,
if, say, Notepad or the DevEnv has the focus and I hit the key, all is
well and my code works fine. However, when a couple of apps have the
focus (e.g. Windows Explorer) and I hit the key, I get that
PInvokeStackImbalance.
Can anyone help? If more info is needed, just let me know.
Thanks in advance!
Mattias Sjögren
>Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef
>pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
pszFileName should be passed ByVal. The hwnd parameter should be of
type IntPtr (but it only makes a real difference if you run on Win64).
Mattias
--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
Ben Voigt [C++ MVP]
"Mattias Sjögren" <mattias.don...@mvps.org> wrote in message
news:%23r9RZJx...@TK2MSFTNGP04.phx.gbl...
> >Private Declare Function GetWindowModuleFileName Lib "user32.dll"
>>Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef
>>pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
>
>
> pszFileName should be passed ByVal. The hwnd parameter should be of
> type IntPtr (but it only makes a real difference if you run on Win64).
Also the character set needs to be specified.
Jeroen Mostert
> I'm not quite sure what's going on, but, here goes: I have a project
> in VB.NET 2005 going. I make a call to an unmanaged function. I'm
> using the declaration below:
>
microsoft.public.dotnet.framework.interop, which specializes in these
questions. You can also use microsoft.public.dotnet.languages.vb for
VB.NET-specific questions. This group is for questions about the Common
Language Framework in general.
> Private Declare Function GetWindowModuleFileName Lib "user32.dll"
> Alias "GetWindowModuleFileNameA" (ByVal hwnd As Integer, ByRef
> pszFileName As String, ByVal cchFileNameMax As Integer) As Integer
>
Personally I prefer to use DllImportAttribute for all .NET languages, as it
allows you to be more precise than the native VB.NET syntax and works the
same across languages. The only drawback is the uninuitive empty function
body which you'll need to supply.
The correct declaration for this function would be:
<DllImport("user32.dll", EntryPoint := "GetWindowModuleFileNameA", CharSet
:= CharSet.Ansi, ExactSpelling := True)> _
Private Shared Function GetWindowModuleFileName(ByVal hwnd As IntPtr, ByVal
pszFileName As StringBuilder, ByVal cchFileNameMax As Integer) As Integer
' Leave empty.
End Function
You'll notice that we're passing a StringBuilder for the output string. This
is necessary because ByRef on P/Invoke parameters doesn't work like you
expect: rather than passing a "mutable" version of your object, it will pass
a pointer to the object. So if you pass a string, it will pass a pointer to
the string, which is wrong, because a string will already be marshaled as a
pointer to characters. The confusing result is that the unmanaged side ends
up with a pointer to a pointer, which is not what the function is expecting.
Luckily, the marshaller knows how to deal with this if we pass a
StringBuilder instead.
> Now, elsewhere, I have a call that looks like this:
>
The correct call is now something like this:
Dim FileNameBuilder As New StringBuilder(300)
Dim FileName As String
GetWindowModuleFileName(iHwnd, FileNameBuilder, FileNameBuilder.Capacity)
FileName = FileNameBuilder.ToString()
Please make sure to also read http://support.microsoft.com/?id=228469,
because the usefulness of this function is severely limited on platforms
other than Windows 95/98/ME.
--
J.
Jeroen Mostert
> This group is for questions about the Common Language Framework in general.
>
getting confused with, here.
--
J.
btysg...@gmail.com
Will do in the future.
As for the issue, the funny thing is my memory was jogged when it was
mentioned that outside of Win95/98/ME, the function was of limited
use. I'd already came across the article that was linked, in fact.
And then it dawned on me: One of my co-workers had uncommented that
section of code and I, after having not seen the code for a couple
months, just took it at face value. The fix was already in place
using the modern .NET equivalent functions (Processes, ProcessInfo,
etc.). Thanks again for your time and help!
Jeroen Mostert
> As for the issue, the funny thing is my memory was jogged when it was
> mentioned that outside of Win95/98/ME, the function was of limited
> use. I'd already came across the article that was linked, in fact.
> And then it dawned on me: One of my co-workers had uncommented that
> section of code and I, after having not seen the code for a couple
> months, just took it at face value.
Behold the dangers of leaving in commented-out code. Although I've had a
hard time with in the past myself, I've since become quite confident about
deleting code that's no longer used, instead of keeping it around "in case
anyone ever needs it". No matter how much time it took to develop, if it's
no longer contributing to the solution now, it's just a maintenance burden.
> The fix was already in place using the modern .NET equivalent functions
> (Processes, ProcessInfo, etc.). Thanks again for your time and help!
No problem, I got a chance to brush up on my VB syntax. Haven't used it in a
while, since my fellow programmers are C# only, and they make me march to
the beat of their drums. Apparently, they're just too *smart* to read VB.NET
code. >:-)
--
J.
Before C#, before Java, before C++, before C, there was BASIC