User32.dll Causing Error on Application Exit

[Marc_A]

I have an application built into an exe with LabVIEW 8.2. It uses 1 simple call to user32.dll to determine if caps lock is on. When I build the application, it copies user32.dll to the 'data' subdirectory of my application. Everything works fine, however when I exit the program it throws a Windows error, "... has encountered a problem and needs to close..."

Now the fun part. If I remove user32.dll from this directory, everything works fine. I guess it just goes out and finds the original user32.dll in the system directory and there are no errors when I exit. Replacing the file in \data causes the error again.

The simplest thing would be to remove the call in my program as it isn't absolutely necessary (it just shows a warning when entering a password if caps lock is on), but there seems to be something weird going on because it only throws the error when using the dll it copied.

Is there any way to stop the application builder from copying dlls? I couldn't find anything.

Is there a way to force LabVIEW to release and cleanup any dlls it is using? If I could do this when the user exits, maybe whatever is causing this won't get left behind.

[rolfk]

---

@marc A wrote:

I have an application built into an exe with LabVIEW 8.2. It uses 1 simple call to user32.dll to determine if caps lock is on. When I build the application, it copies user32.dll to the 'data' subdirectory of my application. Everything works fine, however when I exit the program it throws a Windows error, "... has encountered a problem and needs to close..."

Now the fun part. If I remove user32.dll from this directory, everything works fine. I guess it just goes out and finds the original user32.dll in the system directory and there are no errors when I exit. Replacing the file in \data causes the error again.

The simplest thing would be to remove the call in my program as it isn't absolutely necessary (it just shows a warning when entering a password if caps lock is on), but there seems to be something weird going on because it only throws the error when using the dll it copied.

Is there any way to stop the application builder from copying dlls? I couldn't find anything.

Is there a way to force LabVIEW to release and cleanup any dlls it is using? If I could do this when the user exits, maybe whatever is causing this won't get left behind.

---

You should not copy system DLLs to other systems. That is a recipy for troubles. Make sure to reference user32.dll form inside the Windows System directory in your Call Library Node. LabVIEW will then see this as system library and not include it in the build. Any Windows system will have user32.dll in the system directory so there is really absolutely no need to distribute that with your app, (and actually it is legally not even correct).

Rolf Kalbermatter

[Marc_A]

That's exactly my problem. The call library node calls C:\WINDOWS\system32\user32.dll but when I build the application, it gets copied to the data directory by the app builder, I don't do it manually. I don't want it to be copied, because it obviously causes problems.

Is there a place to specify whether to copy DLLs to the built application, so I can tell it not to?

[rolfk]

---

@marc A wrote:

That's exactly my problem. The call library node calls C:\WINDOWS\system32\user32.dll but when I build the application, it gets copied to the data directory by the app builder, I don't do it manually. I don't want it to be copied, because it obviously causes problems.

Is there a place to specify whether to copy DLLs to the built application, so I can tell it not to?

---

No! For some reasons your system thinks that C:\WINDOWS\system32 isn't your Windows system directory. That would be a problem with the installation of Windows itself and I'm not sure how that could happen nor how to fix it. Did you do a Windows upgrade from an earlier version at some point?

This has always worked properly for me so I really can't help you much more here.

Rolf Kalbermatter

[Marc_A]

This is a regular installation of Windows XP SP2 on a new HP computer. I haven't upgraded anything or ever messed with Windows at all as this is my work computer.

Something new: kernel32.dll is also listed in my dependencies for the project which also resides in c:\windows\system32, but it doesn't get copied to the data directory. Only user32.dll is causing this problem.

I'll probably wind up taking this out of the project, but I wish I knew why LV copies this DLL, then has a problem with it.

Thanks for your help and any other information you might have, Rolf

[SimonH]

Marc,

Have you tried configuring the call library node to just call "user32.dll" instead of the full path "C:\WINDOWS\system32\user32.dll".

I performed a quick test and this seemed to work.

Regards,

Simon H
Applications Engineer
National Instruments
http://www.ni.com/support/

[Marc_A]

Beautiful, that did the trick. However I still see this as a problem with LabVIEW. Whether I specify the full path or not, it should see that the file is in system32 and not copy it.

Also, this still doesn't answer why the error showed up in the first place. It's the same file, just in a different location. Why would it have a problem with this?

Just food for thought for you, Simon, or any other NI engineers that see this.

Thanks for the help.

[TheDillo]

Actually the reason this is crashing is because the System32.dll may be reference other dll's.  Because of this, specifying the path specifically to the C:\WINDOWS\System32 directory will allow System32.dll to reference other .dll as it needs.

As Rolf mentioned, you should never copy system dll's to other computers.  Different versions of Windows (even different Service Packs) may have different system dll's.

Finally, as a best practice, if you're loading a system dll, I would select the checkbox "Specify path on diagram" of your Call Library Function Node (this is an option in 8.x).  This will load the dll into memory when it needs gets to Call Library Function Node in the program flow, instead of loading the dll when your application starts.

[Marc_A]

---

@TheDillo wrote:

Actually the reason this is crashing is because the System32.dll may be reference other dll's.  Because of this, specifying the path specifically to the C:\WINDOWS\System32 directory will allow System32.dll to reference other .dll as it needs.

---

Wait, so you're saying that specifying the full path is the right way to do it? This is what was causing the error for me. Also, as I said, I didn't copy the system dll, the application builder did it. This is what I was wondering about. Why would user32.dll get copied if I specify the full path, but it doesn't if I don't?

[TheDillo]

Let me clarify.  Specifying the path on the block diagram is the advised way when calling system dll's.  Specifying the path in the Call Library Function Node dialog is the advised way when calling dll's that you've written.  This second method will copy the dll to your local vi directory.  If you tried this with a system dll, it could break functionality if the dll depended on other system dll's (as is the case in this situation).

Marc, does this answer your question?