Your program uses Call Library Nodes that call into the kernel32.dll. And somehow one or more of those Call Library Nodes have been changed to contain a full path to the kernel32.dll. LabVIEW assumes that a full library path in the Call Library Node means that a DLL is private to your application and tries to copy it into the data folder of the application when building the application. It also updates the path in the VI to reference to this DLL instead of the one that comes with Windows. Since this DLL is likely build on Windows 7 it will be highly incomplete to run on Windows 10 and cause all kind of trouble. But it is loaded by the application anyways.
You need to go into the VIs of your application and find each occurrence of a Call Library Node that defines a full path to the kernel32.dll and change it to only contain the dll name itself without any path information. It may still seem to revert to the full path when you reopen the Call Library Node configuration dialog but as long as you don't edit that path in any way LabVIEW will remember tot only use the filename itself, which will always reference to the DLL version for the current operating system.
And with a DLL file name only library path, the application builder will NOT include the kernel32.dll from your build system in the application build and then your executable will load correctly on other Windows systems than the one you build your executable on.
In fact for many Windows DLLs you will see very strange effects or crashes even if you run it on the same system, if an application tries to load a second copy of a system DLL into memory.