Reading CPU Usage in 64 BIT labview using pdh.dll dosent work.

[AtulS]

hi all

trying to read total cpu usage using pdh.dll but in labview 64 bit it dosent work.

works fine in 32 bit labview.

[wiebe@CARYA]

You probably need to change some of those handles to pointer sized integers, instead of 32-bit integers.

[AtulS]

thanks for reply

---

wiebe@CARYA wrote:

You probably need to change some of those handles to pointer sized integers, instead of 32-bit integers.

---

tried that but didnt worked.

[wiebe@CARYA]

Can you use the error wires and return values to see where it fails?

[AtulS]

checked that also but it dosent throw any error 

but showing cpu usage value continues zero.

[wiebe@CARYA]

Is there data in the integers? E.g. before the cast? You might need to cast to a sgl, displaying a double as a single isn't the same.

[GerdW]

Hi AtulS,

in labview 64 bit it dosent work. works fine in 32 bit labview.

Do you call a 64bit-version of the DLL with LabVIEW64bit?

AFAIK LabVIEW32bit calls 32bit DLLs, and LabVIEW64bit wants to call 64bit-DLLs…

(I might be wrong, so RolfK might jump in…)

[wiebe@CARYA]

In my experience, that should be transparent for the user. A 64 bit application can call the old kernel32.dll and user32.dll, and Windows will handle that gracefully. Also, I don't think there is a user64.dll and kernel64.dll (for example).

[billko]

---

wiebe@CARYA wrote:

In my experience, that should be transparent for the user. A 64 bit application can call the old kernel32.dll and user32.dll, and Windows will handle that gracefully. Also, I don't think there is a user64.dll and kernel64.dll (for example).

---

Depends on how it's called.  If you just call it using the dll name, you should be fine.  If you specified a path, then you're not.

[rolfk]

---

wiebe@CARYA wrote:

In my experience, that should be transparent for the user. A 64 bit application can call the old kernel32.dll and user32.dll, and Windows will handle that gracefully. Also, I don't think there is a user64.dll and kernel64.dll (for example).

---

No there isn't! As long as you only specifiy the DLL name without any path you are definitely safe as Windows will automatically defer to either the SysWOW64 (when called from 32-Bit LabVIEW) or System32 (when called from 64-Bit LabVIEW) directory to look for the respective DLL Even if you happen to specifically include the whole path Windows will automatically redirect to the correct directory based on the bitness of the calling process, unless you called the Windows API to disable redirection.

However with fully included path, the LabVIEW application builder will consider the DLL as a private dependency of the application and then copy the DLL into the application directory to reference it there. This is ALWAYS bad for system DLLs as you do not want system DLLs to be copied into the application folder. The problem here is that LabVIEW has no secure way to detect if a DLL is a system DLL or just a DLL that a user copied himself into the system directory, so using the path to determine if it is a system DLL is not safe and using a blacklist is never complete as the number of system DLLs in the system folder can change depending on various software components that may or may not be installed in your Windows version.