LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to use kernel32.dll ReadProcessMemory() on LabVIEW ?

Hi to all!

 

Anyone allready sucess to use kernel32.dll ReadProcessMemory() with LabVIEW?

Of course I try to transpose https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-readprocessmemory

on LV but system crash.

I think process ID and data@ are correct but it crash

 

How to implement kernel32.dll ReadProcessMemory() on LabVIEW?

 

Thanks

 

 

0 Kudos
Message 1 of 6
(960 Views)

Try running your code as administrator. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 2 of 6
(941 Views)

Hi Jay, already done but it didn't solve problem

0 Kudos
Message 3 of 6
(905 Views)

What makes you think you could pass a NULL pointer as target to write information into?

 

And a picture is NEVER enough to show what you have done with a Call Library Node. The most important information is shown in the Node configuration, which your picture doesn’t show, and no a screen shot of that configuration dialog is not enough, it has tabs and the parameters are in a list control selection.

 

Depending on how you configured that parameter it may not be the problem as long as you never try to read more than 4 bytes but it is unlikely you configured the pointer parameter that way and it crashes for a reason, so my conclusion is that this is very likely your problem.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 6
(893 Views)

Hi thanks for your help!

I found mistake, i used C call... good solution is stdcall(WINAPI) of course.

So I success to use ReadProcessMemory() on LabVIEW

**

uint32_t OpenProcess(int32_t dwDesiredAccess, int32_t bInheritHandle, int32_t dwProcessId);

int32_t ReadProcessMemory(uint32_t hProcess, intptr_t lpBaseAddress, intptr_t *lpBuffer, uint32_t nSize, int32_t *lpNumberofBytesRead);

 

AFLAMENT_0-1658066321190.png

 

0 Kudos
Message 5 of 6
(877 Views)

It's still wrong, even if it works for this specific call. You pass in an intptr_t by reference for the buffer. This means LabVIEW will pass the reference (the pointer to) a variable that is 32-bit in 32-bit LabVIEW and ... gasp, yes indeed, 64-bit in 64-bit LabVIEW. So as long as you are sure to never require the function to read more than 4 bytes into that buffer, you will be indeed fine with this configuration.

 

More correct would be however to make this parameter an Array of Uint8, pass it as C Array Pointer in the Call Library Node, create a byte array (Initialize Array) that has the number of elements you want to read and connect it to this parameter and then use the same number you used to initialize the size of the array to pass to the nSize parameter of that function. Bonus points for using the returned value in lpNumberofBytesRead to resize the array after the call to what the function actually has filled in (it may abort before the requested amount of bytes have been read since the remainder might be beyond a valid allocated page for the process in question).

 

Also, OpenProcess() returns a HANDLE, which in Windows is defined as opaque pointer sized variable. So you should configure it in the LabVIEW Call Library Node accordingly as Pointer-sized (signed or unsigned) Integer. The same applies of course for the handle value in ReadProcessMemory().

 

Equally are the nSize and lpNumberofBytesRead also defined as SIZE_T which is a signed pointer sized integer type too.

 

You may say I don't care, I'm only using this in 32-bit LabVIEW, but there will be a time in a very foreseeable future where 32-bit LabVIEW won't be available anymore, so better prepare now for it and save you some hassle in a few years from now.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 6
(873 Views)