32-bit executable does not run in Windows Server 2008

[wai.chan]

Hi,

Sorry if this question has been asked already. I am having trouble finding a solution in the NI knowledge base and here in the forums.

I just created a simple UI standalone application in Labwindows/CVI with UI. It runs perfectly in XP when it was developed. When I ported this over to the Windows Server 2000 target and tried to run it, it is stuck in a Windows console and will not spawn main(). I tried both rebuilding it on the 64-bit machine as well as just running the exe as is, yielding the same results. I also tried running corflags against the exe on both the 32-bit dev machine and the 64-bit target but both output says "The specified file does no thave a valid managed header", which seems to be true for all CVI exe files.

Through some troubleshooting, I was able to narrow it down to a call to a function in a dll (that apparently has already been working all along). If I comment out the two calls, main() would start and life is good again. I tried visually looking through the code in the project producing the dll and things are fine.

Can someone provide me with some insight into how to proceed on this? Was it a bad build? Did I not configure the build environment correctly (I already tried changing the stack/heap usage)? Could this be caused by a bug in the software that the compiler didn't catch? What typically causes a freeze in the console that spawns main()?

Please help! Thanks in advance!

EDIT: BTW, I'm running LabWindows/CVI 2009 on both machines.

[Wolfgang]

According to the CVI OS support roadmap CVI 2009 does neither support Windows Server 2003 nor Windows Server 2008.

You might consider upgrading to a more recent version of CVI.

[wai.chan]

Ha! So, am I hearing that the fact that everything has been working as dll's on Server 2008 is by pure dumb luck? Wow!

It's not something that our project leads are happy to hear.

Thanks! Wai

BTW, if that means anything at all, I have it narrowed down to calls to a C library (also in dll). If I comment these calls out, things work again.

[Ian.W]

One other possibility is having sufficient rights, especially if you are invoking it via some other app, rather than manually as a logged in user. If you are not logged in and instead invoke it via a web site action, I believe you will have problems reading the registry, accessing a desktop, writing to disk, etc.

Sorry I can't be more definitive, but perhaps it will help.

Please post your conclusion, if you find it.

--Ian