Is there a way to make a LabVIEW EXE built on Windows XP Work on Windows 7?

[Billy_Barty]

I have an application that I build (LabVIEW 8.6) on Windows XP that installs and works fine on other XP machines.  However, after installing it on a Windows 7 machine I get an error stating "The procedure entry point CsrNewThread could not be located in the dynamic link library ntdll.dll".  When I examine ntdll.dll (in C:\Windows\System32) with a dependency walker on XP I see the CsrNewThread function listed, but his function is missing in the same named DLL on Windows 7.  So I guess that somewhere along the Windows evolutionary line that function was removed from ntdll.dll.  My first instinct was to try overwirting ntdll.dll on the Windows 7 machine with the one copied from my Windows XP machine.  However, our system administrator has not given me the permission to overwrite this file on the Windows 7 machine.  I could ask him to give me this permission, but I am not sure this is the best way to go anyway because other Windows 7 programs may use ntdll.dll.  I did try copying the WIndows XP version of ntdll.dll to the local folder on the Windows 7 machine containing my LabVIEW app, but this did not fix the problem.  And when I look at my app in the dependency walker, I see that it is still looking at the ntdll.dll file in the WIndows\System32 folder and not at the one in my local folder.  So, is there a way to make a LabVIEW EXE built on Windows XP Work on Windows 7?  Or will I have to do one build for Windows XP and another for Windows 7?  Again, I am using LabVIEW 8.6.

Thanks

[nyc_(is_out_of_here)]

maybe http://windows.microsoft.com/en-us/windows-vista/make-older-programs-run-in-this-version-of-windows ?

[crossrulz · Accepted solution]

Also keep in mind that LabVIEW 8.6 is not officially supported in Windows 7.  You might want to consider upgrading to at least LV2009.

[dkfire]

Do you know why you in the first place are using the dll ??

[Billy_Barty]

No.  It is just one of many Windows DLL's my LabVIEW app hooks into.  It is called by kernel32.dll for instance, and I cannot do without kernel32.dll.

Thanks

[rolfk]

First: NEVER replace Windows system DLLs with DLLs from another system, and definitely not ntdll.dll and kernel32.dll. Even if it is the same Windows version, you may be in deep sh*t, trying to do that, as they might be sifferent versions and totally mess up your machine becuase of incompatibilities with other system DLLs in your installed Windows.

And NTdll.dll is not supposed to be called by an application directly as it's interface is officially not documented in the SDK (but sometimes a bit in the DDK). And I'm pretty sure LabVIEW does not make use of the ntdll.dll directly but goes for all things through the official Win32 API in kernel32.dll and friends. So the logical question is, do you have other DLLs that you are using in this LabVIEW application through the Call Library Node?

[Billy_Barty]

You are correct, ntdll.dll is not called directly.  It is called by kernel32.dll, user32.dll, version.dll, and others (see attached screenshot of my app dragged into the dependency walker - this is on XP, so you can see the CsrNewThread function within ntdll.dll; that function does not show up when I drag the app into the dependency walker on Windows 7).  What I would like to be able to do is have the XP versions of the DLL's in the local folder containing my LabVIEW app and make my LabVIEW app call into those DLL's rather than the ones in windows\system32.  I don't see a way to make my LabVIEW app do this however.  Even with the DLL's in the local folder, I get the same error as when they are not in the local folder and furthermore when I drag my app into a dependency walker it shows the app still calling into the DLL's in windows\system32.  Is there a way to make LabVIEW call into the DLL's in the local folder rather than windows\system32?  Also, I looked for where the value of "SystemFolder" is set in LabVIEW but could not find it.  I was thinking I could make a new folder on the Windows 7 machine (windows_XP_SP3\system32) and copy all the DLL's from my XP machine's windows\system32 folder into windows_XP_SP3\system32 on the Windows 7 machine and then set SystemFolder in LabVIEW to windows_XP_SP3\system32.

Thanks

[Billy_Barty]

Thanks nyc, but that did not work.

[rolfk]

Unfortunately you do not show where your kernel32.dll, user32.dll and possibly other DLLs are loaded from. You surely have a messed up system somehow. If those system DLLs are installed by the same Windows installation they simply can't have such mismatches. This only can happen if you have somehow copied one of the ***32.dll files from your XP or other system to your W7 system. the XP DLL expects ntdll.dll to have these exports but W7 doesn't so it has to clash.

If you are sure to not have copied any Windows system DLL from somewhere else to your W7 system, the only other possibility I can think of is that you have a compromised system, where some virus or troyan has installed or altered a system file without being designed to work on W7.

[Billy_Barty]

To restate - I think the issue is that the DLL's (a few, many, all? - I don't know) in windows\system32 have changed between WIndows XP SP3 and Windows 7.  The one DLL I have identified so far as being different and with which I am having an issue (there may be more, but so far this is the only one) is ntdll.dll.  In XP SP3, the DLL contains and exposes a function called CsrNewThread whereas in Windows 7 this function is missing in the DLL (or it is not exposed).  I do not call the CsrNewThread function or any other function in ntdll.dll explicitly.  Rather, the CsrNewThread function (in ntdll.dll) is called by other windows DLL's which my LabVIEW app hooks into (either explicitly through a LabVIEW clf node or implicitly somehow by LabVIEW when the EXE is built).  Focusing on ntdll.dll, when I examine ntdll.dll (in C:\Windows\System32) with a dependency walker on XP I see the CsrNewThread function listed (see attachment to my previous post), but I do not see this function in the same-named DLL dragged into the dependency walker on Windows 7.