It's actually being included in the support files folder with the other dll's necessary for the executable. It is not required for my executable, however, and when I put the executable on a computer outside of the development environment, the executable breaks when it runs. If I delete the kernel32.dll from the support folder, the executable runs fine on the stand alone computer. The frustrating thing about this is that this is new behavior for making this particular executable. My development computer started adding the kernel32.dll to my executables that contain a certain sub vi a couple of months ago. The offending sub vi has no library function calls to the dll that I can find or knowingly added. If I use a different development computer with the exact same source code and project file, the kernel32 dll is NOT included in the support folder. It is only my particular development computer. I looked at all the posts that contain a reference to the executables with kernel32.dll, like the one in the Knowledgebase "My Stand-Alone Executable Cannot Find My DLL, Even Though I Have Specified the Path for the DLL" and tried to add the system32 folder to the vi search path, but that did not do anything. I looked through all of the Options pages but did not find anything that seemed relevant. Did I miss some setting that I inadvertantly modified to start getting this behavior?
Please let me know what I can look for to try and fix this problem. It is not an acceptable solution to have users go into the support folder and delete this file after the program is installed on their computer. It is also not reasonable for me to use a different computer each time I want to create an executable, and I really don't want to reinstall all of the many parts and modules of LV on my computer.
Thanks,
Craig
