From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

application crash report (user32.dll)

Solved!
Go to solution

crash report.png

 

I have an actor based application. When i use "user32.dll - keybd_event" function, application gives the exception above. I used "keybd_event" function from the example that was downloaded the link below.

 

https://decibel.ni.com/content/docs/DOC-9001

 

I have attached the crash report for further information. Am I doing something wrong with "user32.dll" call or this is a bug?

0 Kudos
Message 1 of 5
(5,438 Views)
Solution
Accepted by topic author Zafer.Depe

Seems i solved the problem. I have made application of the original example and saw it also threw this exception. I was thinking about having a copy of "user32.dll" at data directory should cause a system error. After deleting the copy "user32.dll", application ran properly. But how I should prevent "application builder" to create a copy of "user32.dll" to data directory. I cannot see any settings about this inside build specifications.

Message 2 of 5
(5,427 Views)

specify path.png

 

Step by step I solved the problem. I have checked "Specify path on diagram" and manually specified the path. This prevented additional "user32.dll" copies. If anyone meets "dll call" exceptions like that maybe this topic should be useful. By the way I am developing "OSK.exe" type virtual keyboard for LV applications. I will share the code after development and maybe people helps to improve it.

Message 3 of 5
(5,411 Views)

Hi Zafer.Depe, 

 

Thanks for following up with your solution!  It's posts like this that make the NI discussion forums such a great resource, and I'm sure someone will find your post useful.

 

Regards,

0 Kudos
Message 4 of 5
(5,382 Views)

I duplicated this bug, but using user32.dll/FindWindowA.  Your approached fixed it for my case, too.  Thanks!  (More info below, if anyone is curious)

 

I didn't catch the bug till I worked on final deployment because I usually either ran from development mode, or copied just the .exe to another folder.  I think it worked at one time, though.

 

The original Windows\System32\user32.dll:  986kB, 11/10/2016 10:32AM

What I found in my data folder:  814kB, 11/10/2016 10:19AM

The wrong one, in Windows\SysWOW64\user32.dll:  814kB, 11/10/2016 10:19AM

 

It sure looks like LabView included the wrong user32.dll.  I found user32.dll in my dependencies list, but when I right-click/Explore..., it shows me the system32 copy.

 

I suspect something loaded the SysWOW64\user32.dll at some point, and after that, LabVIEW (32-bit) copied the wrong one over.

 

However, to make things especially confusing, I tried copying the System32\user32.dll into the data folder (without the fix above).  It didn't work.  I get "Missing external function user32.dll:FindWindowA:C in VI myvi.vi" (I did set calling convention to 'stdcall', not 'C', so I don't understand the :C).  I don't understand that one, but I guess I don't need to understand it since the fix above works (and better since it won't conflict with future Windows Updates).

 

Turns out, I didn't need the full .dll path.  This worked:

Shorter Version

___________________
CLD, CPI; User since rev 8.6.
0 Kudos
Message 5 of 5
(4,998 Views)