Kernel32.dll - GetTickCount

[david.fox]

I am trying to learn how to use the kernel32 dll. The issue I am having is that the *.vi works fine but the *.exe throw a crash report when calling kernel32. If anyone has any ideas, it would be great to hear from you.

I can't find much information on the access violation and why it is only applicable for the *.exe file and not the *.vi file.

[ZYOng]

Try Access Violation 0xC0000005 Crash When Launching LabVIEW Executable

[david.fox]

Same error as the first time...

[zou]

What is the 2nd dll call?

[david.fox]

The second call is user32.dll

[david.fox]

Here is a snippet for you all. Just a very simple Windows activity counter. 

[rolfk]

Change the Library path in the Call Library Node explicitly to kernel32.dll once and then save your VI!

It will revert to a full path but store only the library name. When you enter a full path, the Application Builder will take that as a hint that the DLL is application private and include it in the exe build (into the data subfolder). This is not only a violation of your Windows license if you distribute it, but it is also causing havoc since the kernel object management in your local copy does not match the one in the system directory.

As a quick fix right now just go into the data folder of your build app and delete the kernel32.dll in there. That will fix the crash (until you rebuild the executable if you don’t change the library name).

A DLL from the <system> folder, especially when it is a Windows one, should NEVER be included in your application build! 

[JimB.]

---

@david.fox wrote:

Here is a snippet for you all. Just a very simple Windows activity counter. 

---

What Rolf said...

But also just FYI, I'm pretty sure that LabVIEW's built-in "Tick Count (ms)" function is in fact just a call to GetTickCount(). There shouldn't be much reason to not just use that.

[david.fox]

Rolf,

The NI Tick Count is great and useful. But this application is to monitor keyboard/mouse idle time. If there is another way to do this, I would be more than happy to hear about it. As of now though, it appears the kernal and user32 is all that is able to count this for me.

[david.fox]

Correct. It does store it in the data folder and carries into the installation process too. Like you suggest, I would rather use the files located in the proper windows system folders on the target machine(s) rather than carrying them with the builds. But, to remark about that, this was the original setup and this setup was what made me start looking at the error. I have narrowed it down though. It is not the kernal that is causing the error. The error is coming from user32. I am a bit at a loss for how to get this working though. I am thinking that there may be another possibility to solve this problem. If it works, I'll post it to let you and any future reader know the solution.