LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ReadProcessMemory WinAPI - Hard time finding LV CLFN settings

Hello fellow LV users,

 

I'm currently trying to get some data from a process.

Everything works fine until I use the ReadProcessMemory function (Kernel32.dll)

 

I have been reading all around, trying to understand.

 

The fact is:

- I am able to quickly code this in LabWINDOWS/CVI (and read the correct number of bytes)

- I am unable to reproduce the same thing using LV, the function return value is always 0 (error) and 0 bytes read

 

P.S. the LV CLFN calling ReadProcessMemory doesn't return any LV error, neither does the GetLastError WinAPI function ("Last operation completed sucessfully)

 

Anyone has already been trying to use this function in LV ? (I'm pretty sure I'm doing something wrong with the parameters in red:

 

BOOL WINAPI ReadProcessMemory(
  __in   HANDLE hProcess,
 __in   LPCVOID lpBaseAddress, 
 __out  LPVOID lpBuffer,
  __in   SIZE_T nSize,
  __out  SIZE_T *lpNumberOfBytesRead
);

 

Any clue about my mistake ?

 

Thanks in advance

Mathieu


0 Kudos
Message 1 of 13
(3,744 Views)

How do you have the Call Library Node configured?  It would help to provide your LabVIEW code.  The two LPCVOID should be pointer-sized integers.  Be careful, though - even though they're technically pointers, to LabVIEW they're just integers, so pass them by value.  Otherwise you're passing the address of those pointers, instead of passing the memory addresses.

0 Kudos
Message 2 of 13
(3,736 Views)

Hi Nathand,

 

Thanks for taking interest in my topic

I have been trying some many different settings before posting, that I din't even know which one to post

 

Here here the prototype I'm using, let's given your last recommendations

 

hProcess = u32 by value

lpBaseAddress = Signed pointer-sized Integer by value (I would use i64 by value)

lpBuffer is in the screenshot (I would use u32, array date pointer allocating minimum size to nSize)

nSize = u32 by value

lpNumberOfBytesRead = u32 pointer to value

 

ReadProcessMemory3.jpg

 

The code may be the problem rather than the configuration of the CLFN, since it still doesn't work with these settings

Return value = 0, no bytes read.

 

ReadProcessMemory2.jpg

 

For now, I'll go on reading on the topic, since there is really something that I don't understand here

 

Regards,


0 Kudos
Message 3 of 13
(3,731 Views)

Sorry, my last post was slightly misleading, now that I see how you're using it.  The lpBaseAddress is correctly a pointer-sized integer by value.  The lpBuffer parameter should be an array of some definite type, as you correctly noted (specifying it as an array of pointer-sized ints could be confusing).  Sorry for my error.  You need to preallocate the array for lpBuffer, for example using Initialize Array.  Right now you're passing an empty array.  Other than that it looks OK to me on a quick check.  The calling convention should, of course, be WinAPI.  You might try setting the debug level to maximum.  Also make sure that the process handle input is valid.

0 Kudos
Message 4 of 13
(3,724 Views)

Edit: we replied at the same time more or less. I'll take time to read you. This post may be obsolete 🙂

 

If I'm right, I was wrong (:O) understanding your recommendations

I think the following code is closer to what should work. But It still doesn't

 

ReadProcessMemory4.jpg

 

Regards,


0 Kudos
Message 5 of 13
(3,722 Views)

The code below works fine for me, and I think the Call Library Function Node is configured similarly to yours.  However, I've set up the process handle as a signed value, since GetCurrentProcess returns -1.  Maybe the process handle is invalid?  How are you obtaining it?  You don't need that pointer to data function, use the array output directly.

ReadProcessMemory.png

Message 6 of 13
(3,706 Views)

@Mathieu Steiner wrote:

Hi Nathand,

 

Thanks for taking interest in my topic

I have been trying some many different settings before posting, that I din't even know which one to post

 

Here here the prototype I'm using, let's given your last recommendations

 

hProcess = u32 by value

lpBaseAddress = Signed pointer-sized Integer by value (I would use i64 by value)

lpBuffer is in the screenshot (I would use u32, array date pointer allocating minimum size to nSize)

nSize = u32 by value

lpNumberOfBytesRead = u32 pointer to value

 

ReadProcessMemory3.jpg

 

The code may be the problem rather than the configuration of the CLFN, since it still doesn't work with these settings

Return value = 0, no bytes read.

 

ReadProcessMemory2.jpg

 

For now, I'll go on reading on the topic, since there is really something that I don't understand here

 

Regards,


This one is mostly right except that you should preallocate the array with Initialize Array, and as nathand already mentioned do not use pointer sized elements for that array, but an explicit integer size. If you want to get 32 bit integers as indicated by your multiplication by 4 use simply an uInt32 or int32 as array element.

 

Our later solution with configuring the output buffer as pointer is absolutely wrong. That does not create a buffer for the function to write into.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 13
(3,699 Views)

@nathand wrote:

The code below works fine for me, and I think the Call Library Function Node is configured similarly to yours.  However, I've set up the process handle as a signed value, since GetCurrentProcess returns -1.  Maybe the process handle is invalid?  How are you obtaining it?  You don't need that pointer to data function, use the array output directly.

ReadProcessMemory.png


This is in principle right. The signed or unsigned is not as important as long as it is configured consistently. But it would better be a pointer sized integer too, since Windows uses internally pointers for all HANDLEs.

 

Using signed might be easier to check for invalid handles, since you can use then -1 as you indicated, but Windows traditionally defined invalid handles with 0xFFFFFFFF which corresponds to -1 for a 32 bit integer. Now with 64 bit support they changed it to (HANDLE)-1 in order to avoid having to define different values for 32 and 64 bit handles.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 13
(3,698 Views)

Rolfk, Nathand,

 

Thanks a lot

Here is the last thing I've tried (i need to change hProcess to i32...)

 

ReadProcessMemory5.jpg

 

It still doesn't work, so that the problem may not be the code, but some windows rights (gonna investigate on this)

For information, I get the handle by getting a handle to a window first. This handle was correct. I'm opening the processmemory with read/write acess (will try read only, since I don't need to write anything)

 

Nathand, I've been trying the code you provided, and the return value for GetCurrentProcess is -1 (i'll try to get the last error to see why) (edit: or is it normal?)

Number of bytes read still is zero.

 

Thanks a lot for your help guys

I'll post my solution when I find something 🙂

Regards,


0 Kudos
Message 9 of 13
(3,688 Views)

Alright.

There we go. I changed the rights to read, when opening the process memory and the handle to match the HANDLE type

 

I finally get something from the read function. Still working on this, but seems to be solved 😄

I'll post some more information when i'll have it work fine

 

Thanks a lot


0 Kudos
Message 10 of 13
(3,683 Views)